6

SpringSource Tool Suite (「STS」) で構築された Spring フレームワーク ベースの Java Web アプリケーションと、Apache Tomcat のローカル コピーがあります。また、Tomcat を実行する内部運用サーバーもあります。

開発マシンでアプリケーションを実行し、Web アプリケーションで特定のアクションを実行すると、すべてが正しく機能します。ただし、(maven によって生成された war ファイルを介して) サーバー上の Tomcat に Web アプリケーションをデプロイし、前述の特定のアクションを繰り返すと、予期しない動作が発生します。サーバーのTomcatログファイルを確認したところ、これが見つかりました...

2011-11-16 19:36:45,090 [http-8280-Processor1] ERROR [attachments]  invoke - Servlet.service() for servlet attachments threw exception java.lang.NoSuchMethodError: net.wmfs.coalesce.aa.dao.MediaDao.updateAlfrescoNodeRef(Ljava/lang/Long;Ljava/lang/String;)V
at net.wmfs.coalesce.aa.service.impl.MediaServiceImpl.doFileUpload(MediaServiceImpl.java:102)
at net.wmfs.coalesce.aa.servlet.MediaServlet.doFileUpload(MediaServlet.java:83)
at net.wmfs.coalesce.aa.servlet.MediaServlet.doPost(MediaServlet.java:55)

現在、updateAlfrescoNodeRef メソッドは MediaDao クラスに確実に存在します。そうしないと、私のコードは STS でコンパイルされません...

package net.wmfs.coalesce.aa.dao;

public class MediaDao extends JdbcDaoSupport {

    public void updateAlfrescoNodeRef(final Long recordId, final String nodeRef) {
        // java code
    }
}

ご覧のとおり、メソッド シグネチャは正しいです。

maven が war ファイルを作成したときに問題があったのではないかと疑ったので、war ファイルの内容を抽出しました。WEB-INF/lib フォルダーで、MediaDao クラスを保持する jar ファイルを見つけ、その内容を抽出しました。それから私は...

cat ./MediaDao.class

さて、クラスファイルはバイナリファイルなので、ほとんどgobledegookを見ました。ただし、updateAlfrescoNodeRef メソッドへの参照と、そのメソッド内の String の内容を明確に確認できました。したがって、これはメソッドが確実に存在することを意味します。

Spring フレームワーク XML ファイルの Bean 構成は間違いなく正しいです。そうしないと、開発マシンで実行したときにコードが実行されません。

グーグルはサーバー上のライブラリの競合を示唆しましたが、参照されているすべてのクラス (MediaServlet、MediaServiceImpl、MediaDao) はメイン プロジェクト (WEB-INF フォルダーがあるプロジェクト) にあります。サーバー上に依存関係の複数のコピーがあると考えられますが、メイン プロジェクト jar のコピーは 1 つだけです。

なぜこれが起こっているのか、誰にもアイデアがありますか?

4

3 に答える 3

11

これで問題は解決しました。皆様のご協力に感謝いたします。

メインプロジェクトにはMediaDao、まったく同じパッケージパスに別のクラスを持つ依存関係があったことがわかりました。誰かが基本的にクラスをその依存関係にコピーしました（多くのプロジェクトがメインプロジェクトを依存関係として指定せずにそれを使用できるように、ライブラリリソースとして）。ただし、その誰かがメインプロジェクトのクラスを削除していませんでした。

そのため、メインプロジェクトのクラスを変更し（updateAlfrescoNodeRefメソッドを追加し）、自分のマシンのSTSでアプリケーションを実行すると、Tomcatはライブラリプロジェクトではなくメインプロジェクトのクラスのバージョンを使用しました。閉まっている。ただし、アプリケーションがサーバーにデプロイされたときは、代わりにライブラリ内のクラスのバージョンが使用されたように見えます（もちろん、ライブラリ内にメソッドがありませんでしupdateAlfrescoNodeRefた）。

同様の状況に遭遇した場合の専門家のヒント：STSで、CTRL + SHIFT + Tを押して[タイプを開く]ダイアログを開き、問題のあるクラスの名前を入力して、そのクラスを持つプロジェクトのリストを表示します。名前。

于 2011-11-18T12:25:44.210 に答える
0

Tomcat 6 以降を使用している場合は、競合するクラスと jar について ~tomcat/lib を調べてください。Tomcat 5 では、~tomcat/common/classes、~tomcat/common/lib、~tomcat/shared/classes、~tomcat/shared/lib を調べます。

于 2011-11-17T15:40:02.393 に答える