問題タブ [jndi]

MDBとWARを含むEARアプリケーションがあります。

このEARアプリケーションでは、他のEARアプリケーションから別のキューにメッセージを送信します。jms/anotherQueueと言います

メッセージの送信がWebコンテキストで行われる場合、それは機能します。私はweb.xmlでそのような設定をしています

ただし、メッセージ送信がEJB（ここではMDB）コンテキストで発生すると、JNDI名のルックアップに失敗します。

私のejb-jar.xml

openejb.jarは

geronimo-application.xmlでmyJmsResourceを定義します

myMDBはjms/anotherQueueが何であるかを理解できないようです!!! どうすれば修正できますか？

JavaSEアプリでJNDIを使用してデータソースを構成したいと思います。これを行うための最良の方法は何ですか？

これまでに、2つのプロジェクトに出くわしました。

1. Apacheネーミング。プロジェクトページには、データソースを構成するための特定の例がありますが、プロジェクトは非常に古く、アクティブではなくなっているようです。
2. JBossNS。を使用してローカルのみのJNDIを構成するのは簡単なようですLocalOnlyContextFactoryが、実際にデータソースを構成する方法に関するドキュメントは見つかりませんでした。

可能であれば、JTAトランザクションマネージャーを使用してデータソースを構成することもできます（JOTMを使用しますか？）。

これが私のJavaクラスです

このクラスを実行すると、例外が発生します。

他のすべてのエンタープライズ Bean クラスは、EJB 3.0 標準に従って記述されています。あなたの貴重な貢献が期待されています。

解決

例外は

これは、アプリケーション側で指定された JNDI 名がサーバー (Glassfish) の実際の JNDI 名と一致しなかったために発生するため、Glassish の JNDI ツリーを管理コンソール (ベンダー固有) で確認したところ、NewSessionRemoteインターフェイス (セッション Bean NewSessionBeanのビジネス インターフェイス) のJNDI は 、アプリケーション側で指定した名前とは異なります。それで、これがどのように起こったのか、突然何かが頭に浮かびました.ejb -jar.xmlには、タグを使用して同じNewSessionRemoteに割り当てられた別の名前のJNDI名があります。したがって、単純にそれを削除して、EJB モジュールを再デプロイします。それでおしまい。

オープンソースのLDAPプラグイン（code.google.com/p/nexus-ldap/）でNexusリポジトリマネージャー（nexus.sonatype.org）を使用していますが、間違ったプロトコルバージョンが使用されていることを示すエラーが表示されます（詳細は以下を参照）。 。プラグインが行うのは、JNDILDAPサービスプロバイダーを使用してLDAPサーバーに接続することだけです。nexus.logファイルのスタックトレースを見ると、JNDILDAP実装でのコンテキストの初期化中に例外が発生します。したがって、以下で説明する問題は、Nexusプラグインではなく、JNDIの誤用またはLDAP認証の誤解が原因であると推測されます。

これがどのようにエラーが発生するかについての推測やアイデアは大歓迎です！

問題を再現する手順は何ですか？

1. OpenLDAP 1.2.xサーバーを使用してLdapAuthenticatingRealmを使用するようにNexusを構成します。そのため、LDAPプロトコルのバージョン2です。
2. OpenLDAPサーバーからユーザーを一覧表示し、Nexus構成UIのロールにマッピングしてみてください-完全に機能します。
3. 次に、ロールに正常にマップされたLDAPユーザーを使用して、実行中のNexusインスタンスにログインするか認証を試みます。

期待される出力はどれくらいですか？代わりに何が見えますか？

ログインしようとすると、「ユーザー名、パスワードが正しくないか、Nexusユーザーインターフェイスを使用する権限がありません。再試行してください。」というエラーメッセージが表示されます。Nexusログファイルには、SunによるJNDI-LDAP実装（以下のログファイルから取得したスタックトレースを参照）がLDAPサーバーに対してユーザーを認証するために、指定された情報でコンテキストを初期化しようとしたときにスローされる例外が表示されます。Nexus UIを使用したユーザールックアップは、認証中に実行されるルックアップと同様に正常に機能します（以下のログファイルを参照）。

CommunicationExceptionに含まれるエラーメッセージ（ "[LDAP：エラーコード2-バージョンはサポートされていません]"）は、誤ったLDAPプロトコルバージョンの使用を示しています。OpenLDAPバージョン1.2.7-30はLDAPv2のみをサポートしているため（企業環境-サーバーバージョンはネゴシエートできません）、プロトコルバージョン2を明示的に使用しようとしました。これを行うには、ソースコードをチェックアウトし、「env.put（ "java.naming.ldap.version"、 "2"）;」という行を追加します。se.devoteam.nexus.ldap.NexusLdapContextFactory：52に。何も変わっていません。

テスト中に、Sunのソースコードを参照しているときに、javax.naming.ldap.InitialLdapContext.InitialLdapContext（）メソッドが最初に行うことは、LDAPプロトコルのバージョンを「3」（javax.naming.ldap.InitialLdapContext：131）に設定することであることに気付きました。 ）。Java6-documentationはプロパティ（java.sun [dot] com / javase / 6 / docs / technotes / guides / jndi / jndi-ldap-gl.html＃version）を説明していますが、JNDI-tutorialはこれをプロトコルバージョンの競合を解決する適切な方法（java.sun [dot] com / products / jndi / tutorial / ldap / misc / version.html）疑問に思う：JNDIを使用するときにLDAPプロトコルバージョン2を明示的に使用する方法はありますか？ LDAPサービスプロバイダーとして？

次に、かなり最新バージョンのOpenLDAPサーバー（openldap2-2.3）を、古いサーバーに委任するLDAPプロトコルバージョン3要求のプロキシとして使用してみました。同じ問題、同じ例外。

追加情報

環境：Tomcat6.0.16にデプロイされたNexusWebappバージョン：1.3.6 ldap-realmバージョン：0.4 JREバージョン：JDK 1.6.0_14-b08プラットフォーム：仮想環境LDAPディレクトリブランド：OpenLDAP1.2.7および2.2.3

nexus.logの関連部分：

.NET アプリの構成を環境中立にするためのベスト プラクティスについて考えてみたいと思います。

バックグラウンド。最初にいくつかの背景。私は .NET の世界ではなく、Java の世界から来ました。Java では、環境に依存しないパッケージを構築するためにできることがいくつかあります。それらは通常、何らかの方法で構成を抽象化することに基づいています。以下にいくつかの例を示します。

• JNDI を使用すると、アプリはエンタープライズ リソース (データベース、JavaMail セッション、JCR リポジトリなど) を名前で参照でき、その名前は環境 (dev、test、prod) に従って特定の構成にマップされます。
• もう 1 つの例は、プロパティ ファイルです。アプリの起動時に既知の場所にあるプロパティ ファイルからアプリが取得する一連のプロパティ (「encryption_key」、「smtp.server.url」、「admin.email」など) がある場合があります。プロパティ キーは、環境に応じて異なる値にマップされます。
• 一部のアプリ開発フレームワーク (Spring など) は、プロパティ ファイルをプルする方法を知っているため、プロパティをフレームワーク構成と統合できます。

私が Java で見たもう 1 つのアプローチはビルド時アプローチで、Ant (トークン置換) または Maven (ビルド プロファイル) を使用して環境固有のパッケージをビルドします。テストと本番用にまったく同じパッケージをデプロイすることを強く好むという理由だけで、このアプローチはあまり好きではありません。しかし、それは私が見たアプローチです。

望ましい解決策。.NET には、その環境から構成 (および拡張により、含まれているパッケージ) を分離するためのいくつかの同等の戦略があると想定しています。

理想的には、環境以外の構成をアプリに密接に関連付けて、環境のみを外部化できるソリューションが必要です。Java の例に戻ると、多くの場合、「構成」は実際には開発者が制御するものです。たとえば、ページ装飾用の Sitemesh サーブレット フィルター、依存性注入またはアプリ ワイヤリング、およびそのような MVC コントローラー メソッドのマッピングなどです。リクエストURIなどに。外部化されたくないもの。しかし、暗号化キー、DB 接続文字列、ログ レベルなどはそうです。

私は過去に J2EE コーディングを行っていた人で、新しい J2EE プロジェクトに取り組むために戻ってきました。2001 年以降、多くのことが変わったので、この非常に基本的な質問をする必要があります。

データベースクラスで次のような構文を使用しています。

これが新しい機能 (注釈) であることは理解していますが、どのように機能するのかよくわかりません。後で私のクラスで私はこの呼び出しを行います:

そして、毎回 NullPointerException をスローします。デバッガーでこれにステップインすると、結局のところ、dataSource は null です。

コードで自分で dataSource を初期化しないのは魔法のようで奇妙に思えます。私が間違っていることは何か分かりますか？

私の web.xml には、リソースを確立するための次のブロックが含まれています。

そして、META-INF の context.xml ファイルを使用して、これをコンテキストに追加しました。コンテキスト エントリは次のようになります。

Tomcat 6、MySQL 5、最新の MySQL ドライバー (古い v3 ではなく、最新の v5 ドライバー) を使用しています。

更新: 単純なクラスで使用しているため、これは機能しません。新しいプロジェクトを作成し、それにサーブレットを追加しました。サーブレットで DataSource が null でない。

これは私の前の質問へのフォローアップの質問です。

ServiceLocator クラスのテスト ケースを作成しようとしていますが、次のエラーが表示されます。

私のテストケース:

上記のコードは、getInstance()次のようなメソッドで失敗します。

ServiceLocatorフロントエンドからアプリケーションをテストしても問題がないため、これがうまく機能することはわかっています。このテスト ケースを書いている唯一の理由は、DAOをテストしたいからです。そして、私が DAO をテストするには、 ServiceLocator( JUnitから) 動作する必要があります。

エラーメッセージの意味がわかりません。誰かが私が試してうまくいくことを提案したいですか?

編集: ServiceLocator コンストラクター

Java コードを SQL Server データベースに接続するのに問題があります。InitialContextアプリサーバーから問題なく接続できます..しかし、今はアプリサーバーに接続して、いくつかのenvプロパティを使用してみたいと思います。したがって、スタンドアロンの Java クラスは、次を使用して SQL サーバーに接続します。InitialContext

プロジェクト ライブラリに mssqlserver.jar があります。他の瓶も必要ですか？

コードサンプルを探しましたが、何を入れればよいかわかりませんContext.INITIAL_CONTEXT_FACTORY

アプリサーバーには次のプロパティがあります。

JNDI名はどうしたのですか？Java 5の新しいアノテーション機能を使用してjavax.sql.DataSourceを取得しようとしています。これは機能しないので、質問したいと思います...

web.xmlにがあり、その中に要素があります。「jdbc/MyDB」と「MyDB」を切り替えています。どちらもクラスベースのデータソースを機能させません（常にnullです）が、taglibsを使用して作成した別の例では、これらのJNDI名の両方が機能します。