0

JBoss4ASインスタンスにデプロイされた既存のエンタープライズアプリケーション用のアドオンWebアプリケーションに取り組んでいます。簡単にするために、Netbeansで提供されているGlassfishアプリケーションサーバーを使用しています。プロトタイプでは、使用するすべてのライブラリを、デプロイするwarファイルにパックします。また、Hibernateといくつかの非常に基本的なライブラリもパックします。ただし、将来的には、サーバーが提供するライブラリや、JNDIデータベース接続ルックアップ、セッションおよびエンティティBeanなどの機能も使用したいと考えています。

私の質問：

  1. JbossでGlassfish用にパックされたwarファイルに単純なWebアプリケーションをデプロイする側面はありますか？これは、問題を解決するのが難しい場合がありますか？
  2. EJBインターフェースは、両方の実装で同様の方法でアクセスされますか？つまり、Glassfishサーバーでこれを行うためのコードを開発したときに、JbossでセッションBeanにアクセスできますか？
  3. JNDIクエリは両方の実装で同様に実行されますか？
  4. 他の側面？

私は単純なサーブレットの開発しか経験していないと言わざるを得ません。私はJavaEEとEJBについていくつかの理論的なことを知っており、これについてさらに深く知りたいと思います。私は実装固有の詳細について何も知らないので、これがこの質問に焦点を当てているものです。

4

1 に答える 1

2

アプリケーションが比較的単純で、コアJava EE標準に固執している場合、理論的には大きな問題は発生しないはずです。JNDIの命名には違いがあるため、EJBへのアクセスに問題が発生する可能性があります。

そうは言っても、JBoss4はかなり古いものです。これはJ2EE1.4に準拠しており、EJB2.1仕様を実装しています。新しいJBossおよびGlassFishサーバーはJavaEE6に準拠しており、EJB3.1仕様を実装しています。EJB3の方がはるかに使いやすいですが、3.x EJBを2.xコンテナーにデプロイすることはできません（逆の方法も可能です）。したがって、EJB2コンテナで可能なことに注意を払う必要があります。たとえば、EJBをローカルで（つまり、同じサーバーにデプロイされた別のEJBから）使用する場合は、EJB2でローカルインターフェイスを定義して実装する必要があります。EJB3では、EJBクラスに。で注釈を付けるだけで十分@LocalBeanです。また、EJB2に必要なすべての外部記述子を使い始めないでください。

一般的な経験則では、開発と本番の両方に同じASの同じバージョンを使用します。たとえば、アプリケーションサーバーAバージョンBには表示されないアプリケーションサーバーYバージョンZの特定の機能にバグがある可能性があります。したがって、アプリケーションはAで動作しますが、Yにデプロイすると、クラッシュします。そして、あなたはそれをデバッグするのに苦労するでしょう。同じ（同じバージョンの）ASを使用すると、開発中にバグを発見する可能性が高くなります。

私はかつて、かなり複雑なアプリケーションをGlassFishv2からGlassFishv3に転送する必要がありましたが、そのプロセスは単純なものではありませんでした。

したがって、JBoss 4をターゲットとして使用する必要がある場合は、JBoss4ですべての開発を行います。これにより後で多くのトラブルを回避できます。最新のJBoss7をターゲットとして使用できる場合は、最新のGlassFish 3.xでアプリケーションを開発でき、おそらく機能しますが、これを行う正当な理由はありません。

于 2013-02-09T23:04:53.717 に答える