簡単な質問: Tomcat のデフォルトの読み取り専用 JNDI 実装をどのように置き換えるのですか?
JNDI データソース (接続プーリング) を使用してさまざまな DBMS に接続する Web アプリに取り組んでいます。スケーラビリティのために、このアプリを Amazon Elastic Beanstalk にデプロイできる必要があります。Amazon Elastic Beanstalk は現在、JNDI データソースの操作をサポートしていませんが、Amazon が推奨するように (接続プールなしで) JDBC ドライバーを介してデータベースに直接アクセスすることは、パフォーマンスとアーキテクチャの観点から魅力的ではありません。ただし、JNDI データソースを使用する変更された Tomcat でカスタム AMI を作成することは可能です。私のアプリのもう 1 つの要件は、データソースがオンザフライで作成可能であり、データソース定義が一元化された場所に保存されているため、Elastic Beanstalk クラスターに参加しているすべてのマシンからアクセスできることです。
データソース定義を S3 に保存し、データソース インスタンス (接続プール) をメモリにキャッシュするカスタムの読み取り/書き込み JNDI 実装を作成しました。Tomcat のデフォルトの読み取り専用 JNDI 実装を置き換えるには、Tomcat を次のキーで起動する必要があります-Dcatalina.useNaming=false -Djava.naming.factory.initial=com.company.product.AwsContextFactory -Djava.naming.factory.url.pkgs=com.company.product.awsjndi。これは私com.company.product.AwsContextFactoryのコンテキスト ファクトリcom.company.product.awsjndiの名前で、 は を含むパッケージの名前ですAwsContextFactory。ただし、これを機能させるAwsContextFactory.getInitialContextには、既存java.naming.factory.url.pkgsの参照を環境から明示的に削除し、次のようにパッケージへの参照を追加する必要があります。
public Context getInitialContext(Hashtable environment) throws NamingException {
environment.remove("java.naming.factory.url.pkgs");
environment.put("java.naming.factory.url.pkgs", "com.company.product.awsjndi");
AwsContext context = new AwsContext((Hashtable) environment, null);
return context;
}
これが行われない場合、Tomcat のデフォルトの読み取り専用 JNDI が優先され、私の AwsContextFactory は使用されません。私が理解している限り、これはハックであり、実行する必要はありません。JVM-Djava.naming.factory.url.pkgs=com.company.product.awsjndiを指定するだけで十分です。それはTomcatのバグですか、それとも何か間違っていますか?
アドバイスをありがとう。
P.