問題タブ [jca]

現在、JCAアウトバウンドアダプター（LocalTransactionをサポート）を開発しましたが、接続管理に問題があります。サーバー（WebLogic 12c）がManagedConnectionsをプールに戻さないことを除いて、私のアダプターはうまく機能します。JavaDocによると、サーバーManagedConnection.cleanup()は接続を再初期化してプールに戻すために呼び出す必要がありますが、そうではありません。

EJBからアダプタを使用すると、サーバーは新しいManagedConnectionを作成し、新しいトランザクションを開始してコミットしますが、ManagedConnection.cleanup()メソッドを呼び出さず、プールに戻しません。

以下に私のテストBeanを示します。

10回の呼び出しの後、次のようになります。

初期コンテキストを取得しましたjavax.ejb.EJBException：EJB例外：; ネストされた例外は次のとおりです。java.lang.RuntimeException：javax.resource.spi.ApplicationServerInternalException：pool = "eis / myJCA"、weblogic.common.resourcepool.ResourceLimitExceptionの接続を取得できません：の数に（0）の最大制限を構成しましたプールeis/myJCAのリソースに到達するまで待機できるスレッド

REQUIRES_NEWお気づきのとおり、呼び出し（属性）ごとに新しいトランザクションを使用します。サーバーは最初に新しいManagedConnectionインスタンスを10回作成し、次に接続プールが最大容量に達します。

ログのトレースから、の単一の呼び出しはManagedConnection.cleanup()発生せず、プール内のすべての接続がビジーであることが明らかです。JCA仕様を読み、アダプターがコールバック関数を使用してライフサイクルイベントをリスナーに送信できることを発見しましたが、これらのイベントリスナーのコールバックを使用しようとすると、新しい例外で終了しました。

javax.ejb.EJBException：BEA1-001471C1E76DE5A4E067; ネストされた例外は次のとおりです。weblogic.transaction.nonxa.NonXAException：java.lang.IllegalStateException：[Connector：199175]このManagedConnectionは、トランザクション動作のためにコンテナによって管理され、コンテナによってJTAトランザクションに登録されています。アプリケーション/アダプタは、ローカルトランザクションのbegin / commit /rollbackAPIを呼び出さないでください。アダプターからのイベントLOCAL_TRANSACTION_COMMITTEDを拒否します。javax.ejb.EJBException：EJB例外：; ネストされた例外は次のとおりです。java.lang.IllegalStateException：[Connector：199175]このManagedConnectionは、トランザクション動作のためにコンテナーによって管理され、コンテナーによってJTAトランザクションに参加しています。アプリケーション/アダプタは、ローカルトランザクションのbegin / commit /rollbackAPIを呼び出さないでください。アダプターからのイベントLOCAL_TRANSACTION_ROLLEDBACKを拒否します。

WebLogicはイベントを待機しないと思います（間違ったイベントを送信した可能性がありますか？）。

だから、私は何が間違っているのですか？サーバーに接続をプールに戻すにはどうすればよいですか？

UPD：接続イベントがサーバーにとって非常に重要であることを発見しました。サーバーは、リスナーに送信されたイベント情報に基づいて接続を管理し、リスナーはManagedConnectionに登録します。これで、アダプタでイベントをサポートしましたが、WebLogicは接続をプールに戻したくありません。現在、ログに次のイベントが表示されます。

1. LOCAL_TRANSACTION_STARTED
2. CONNECTION_CLOSED
3. LOCAL_TRANSACTION_COMMITTED

私には問題ないように見えます（CONNECTION_CLOSEDイベントは、アプリケーションが接続を閉じたことを意味します。このイベントを送信するcloseメソッドを追加しました）。コミットが成功し、例外は表示されません。イベントを正しい順序で送信したようです（以前のWebLogicは例外をスローしましたが、現在はそれを停止しています）が、サーバーはまだ接続をプールに戻しません。

私は混乱しています。

キーストアエイリアスのJavaセキュリティの問題に直面しています。

私の問題は、ブラウザからキーストアエイリアスを取得していることですが、リストを取得すると、2つの.pfx証明書が同じ会社のものであるため、同じエイリアスを持つことがありますが、1つはサインイン用で、もう1つは暗号化用です。これは、一意に区別しようとすると失敗することを意味します。これは、keystore.aliasesメソッドが両方のエイリアスに対して同じものを返すため、どちらを返すかがわからないためです。

私はIBMツールを使用しています。Websphere ESB（WESB）とCICSトランザクションゲートウェイ（CTG）があります。基本的な設定は次のとおりです。

SOAPサービスにはCICSからのデータが必要です。SOAPサービスはサービスバス（WESB）に接続してデータとプロトコルの変換を処理し、次にWESBがCTGを呼び出し、CTGがCICSを呼び出し、応答がその逆に（同期的に）処理されます。WESBは、リソース・アダプターおよびJCAコネクター（またはWESBで呼び出されるCICSアダプター）を使用してCTGを呼び出します。これで、すべての部品が配置され、機能しています。

私の質問はセキュリティについてです。WESBを使用している場合でも、答えはおそらくWebsphere Application Server（WAS）の場合と同じです。Resource Adaperは、JAAS-J2C認証データを使用して保護されます。J2C認証データ入力を使用してセキュリティを構成したので、基本的には実行中のアプリケーションに参照があり、実行時にアプリケーションはサーバーからセキュリティ属性を検索します。したがって、基本的に、私は常に同じセキュリティー参照を使用してCICSアダプターにアクセスしています。

私の問題は、将来、より動的な方法でリソースにアクセスする必要があることです。セキュリティをアプリケーションに組み込むことはできなくなりましたが、代わりにパラメータとして指定されています。

一部のWESBまたはWASの第一人者が私を助けてくれますか？これをWESB / WASで正確に行うにはどうすればよいですか？

私は Weblogic で Java EE 開発を行っています。私の EJB の 1 つは、ファイルからのデータを処理する必要があります。EJBから直接ファイルシステムにアクセスすることは推奨されていないので、JCAアダプタが必要になると思います。

JCAアダプターの作成例はいくつかありますが、自分で実装する必要があるのでしょうか。適切に実装された JCA アダプターがいくつかある場合、いくつかの構成を行うことでそれを利用できると思いますか?

Oracle® Fusion Middleware は、「テクノロジ アダプタ」と呼ばれるいくつかの JCA アダプタを提供しているようです。一部の構成だけで使用できますか? または、JCA 仕様に従って独自のアダプターを開発する必要がありますか?

Oracle®FusionMiddlewareのファイルアダプタを使用して、推奨される方法でファイルシステムにアクセスしたいと思います。アダプターのドキュメントはhttp://docs.oracle.com/cd/E15523_01/integration.1111/e10231/intro.htmから見つけることができます。このドキュメントでは、アダプタがOracle®FusionMiddlewareの一部であるとのみ言及していますが、どの特定の製品にアダプタが含まれているのかについては言及していません。Weblogic ServerとJDeveloperをダウンロードしてインストールしましたが、アダプタが含まれていないようです。

誰かが私にいくつかの提案をすることができますか？よろしくお願いします。

I am trying to bind my message driven bean with Oracle JCA file adapter (which is included in the SOA suite) on Weblogic 10.3.5. So that my MDB can get notified when there is any .txt file is moved to specific directory.

After launching a Weblogic domain with SOA features supported, the file adapter is automatically deployed. On Weblogic console I can see the file adapter is deployed as a "Resource Adapter", health is "OK", state is "Active", as shown below:

Also I run the tests of the file adapter, and they all passed:

So I think the file adapter is correctly deployed and should be functional.

Then my message driven bean code looks like this:

Here are the content of my ejb-jar.xml file:

And my weblogic-ejb-jar.xml file:

While deploying the EAR project, I got this message:

I have no idea why Weblogic complain this, since the "eis/FileAdapter" JNDI name is mentioned in the official user guide of the adapter. Also I can see it in Weblogic's JNDI tree:

What's more, when I run the code below in my testing web service:

It prints out "eis/FileAdapter => oracle.tip.adapter.file.FileConnectionFactory@ff51dc", which means the JNDI name is correct!

So my question is, why Weblogic could not find resource adapter with a "correct" JNDI name for binding? Could someone give me some ideas on how to solve it?

SQL-DB、非 SQL-DB、プレーン ファイル ストレージなどのさまざまな永続化テクノロジを、Java EE アプリケーションに柔軟に統合する方法を考えています。ここにいくつかの指示を書きます。コメントをいただければ幸いです。

統合層では、DAO パターンを使用して、データ アクセス用のコードをローカライズします。これは、SQL-DB のエンティティ クラスでは非常に簡単です。ただし、この DAO に加えて、非 SQL-DB 用の DAO とプレーン ファイル用の DAO も利用できます。DAO はステートレス セッション Bean であり、トランザクション機能、場所の透過性、および同時実行性を保証します。それにもかかわらず、同時実行性と場所の透過性は、非 SQL-DB とプレーン ファイル ストレージのデータ層に実装する必要があるようです。

DAO の設計パターンが全体のメカニズムを実装するのに最適かどうか疑問に思っています。私がよく知らない JCA パターンにも遭遇し、それに関するドキュメントがたくさんあります。これらのアイデアをコメントしていただければ幸いです。あなたはすでに同様の仕事をしていましたか？ここまでお読みいただきありがとうございます。

ローカル トランザクションをサポートする JCA アダプタを作成しようとしています。最後のエージェント最適化を使用して、コネクタを XADataSource と同じトランザクションに入れたいと考えています。

仕様によると、コミット中にエラーを示すためにLocalTransactions.commitスローする必要があり、XA トランザクションをロールバックする必要があります。LocalTransactionExceptionただし、これは起こりません。server.log にいくつかのスタック トレースが表示されるだけで、トランザクションは準備済みの状態のままです (そこでハングします)。呼び出しをデバッグし、glassfish は最後のエージェントの最適化を実際に実行しますが、ConnectorXAResource.commit(それを呼び出すと)、LocalTransactionExceptionロールバックに至らない例外に変換されます。

これを解決するための提案はありますか?

neo4j-connectorをコンパイルしてデプロイしようとしています。

neo4j-connector-impl (Neo4jManagedConnectionおよびNeo4jResourceAdapter) の 2 つのクラスには、次の注釈があります。

これは正常にコンパイルされますが、glassfish 3.1.1 にデプロイしようとすると、一連のエラーが発生します。

[boolean] is not an allowed property value typeat org.glassfish.apf.AnnotationInfo@118944a java.lang.IllegalStateException: [boolean] is not an allowed property value typeat org.glassfish.apf.AnnotationInfo@118944a at com.sun.enterprise .deployment.archivist.Archivist.readAnnotations(Archivist.java:490) at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432) at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors (Archivist.java:408) com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383) com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246) com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255) at com.sun.enterprise.deployment.org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.load(DolProvider. java:181) org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93) com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828) com.sun .enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770) com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368) com.sun.enterprise.v3.server.ApplicationLifecycle .deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382) com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) com.sun. enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1064) com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) com.sun.enterprise.v3.admin.CommandRunnerImpl $ExecutionContext.execute(CommandRunnerImpl.java:1244) com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232) com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter) .java:459) の com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209) の com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java: 238) com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828) com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725) com.sun.grizzly.http.ProcessorTask com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) の .process(ProcessorTask.java:1019) com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) の com.sun. grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) で com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) で com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask) .java:59) com.sun.grizzly.ContextTask.run(ContextTask.java:71) で com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) で com.sun.grizzly. util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:680) 原因: [boolean] is not an allowed property value typeat org.glassfish.apf.AnnotationInfo@ org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367) の 118944a org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375) org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289) org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:271) at org.glassfish .apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:199) at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134) at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist) .java:606) at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445) ... 39 詳細 原因: java.lang.IllegalArgumentException: [boolean] is not an allowed property value type com.sun.enterprise.deployment.EnvironmentProperty で。checkType(EnvironmentProperty.java:178) at com.sun.enterprise.deployment.EnvironmentProperty.setType(EnvironmentProperty.java:239) at com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.getConfigProperty(PropertyHandler.javaConfig: 221) com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.handleConfigPropertyAnnotation(ConfigPropertyHandler.java:142) で com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.processAnnotation(PropertyHandler.java: 91) at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344) ... 46 もっと見る239) com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.getConfigProperty(ConfigPropertyHandler.java:221) で com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.handleConfigPropertyAnnotation(ConfigPropertyHandler.java: 142) com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.processAnnotation(ConfigPropertyHandler.java:91) で org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344) で ... 46もっと239) com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.getConfigProperty(ConfigPropertyHandler.java:221) で com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.handleConfigPropertyAnnotation(ConfigPropertyHandler.java: 142) com.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.processAnnotation(ConfigPropertyHandler.java:91) で org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344) で ... 46もっとcom.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.processAnnotation(ConfigPropertyHandler.java:91) の handleConfigPropertyAnnotation(ConfigPropertyHandler.java:142) 344) ... 46 続きcom.sun.enterprise.connectors.deployment.annotation.handlers.ConfigPropertyHandler.processAnnotation(ConfigPropertyHandler.java:91) の handleConfigPropertyAnnotation(ConfigPropertyHandler.java:142) 344) ... 46 続き

私はそれを回避する方法を考え出すことができます (たとえば、setXa(String)メソッドを追加する) が、これは正しくないと感じます: このコードは 1 年以上前にコミットされてから変更されていないのに、どうしてうまくいかないのでしょうか? ここで何がうまくいかないのでしょうか？