can not be cast to javax.servlet.Filterなどの問題の解決方法
質問1:can not be cast to javax.servlet.Filter
テストから開発に移行した同僚がコードを初めて更新し、ローカルでwebプロジェクトを起動するときに、次のエラーを報告しました.
Exception starting filter encodingFilterjava.lang.ClassCastException:com.gaochao.platform.web.context.filter.ContextFilter2 can not be cast to javax.servlet.Filter
このエラーにより、tomcat/libのjarパッケージとwebappsディレクトリのアプリケーションのWEB-INF/libディレクトリの下に同じパッケージがあると思われ、バージョン上の競合があり、解決策は依存にラベルを付けることです
この考えに沿って、ラベルの使い方を探しました.以下のようにします.
*compile、デフォルト値、すべてのフェーズに適用され、プロジェクトとともにパブリッシュされます.
*providedは、compileと同様に、JDK、コンテナ、または使用者がこの依存性を提供することを望んでいる.例えばservlet.jar.
*runtimeは、JDBCドライバなどの実行時にのみ使用され、実行およびテストフェーズに適用されます.
*testは、テスト時にのみ使用され、テストコードのコンパイルおよび実行に使用されます.プロジェクトとともにパブリッシュされません.
*システムは、providedのように、依存jarを含む明示的な提供が必要であり、MavenはRepositoryでそれを検索しません.
しかし、私たちのコードにはこのラベルがあることを確認し、構成にも間違いがなく、確かにprovidedです.既に作成したwarパケットで問い合わせると、経路oa-deploytargetoa-deploy-0.0.1-SNAPSHOTWEB-INFlibでもservletのjarパケットがないことが確認され、JDK、コンテナ、または使用者がこの依存の解釈を提供することが期待されています.問題はまだこの場所にあるのではなく、さらに他の解決策があるのではないかということがわかります.さらに資料を調べたところ、http://jira.codehaus.org/MOJO-1076という番号のバグがあります.バグの説明は私たちのエラーとほぼ一致しています.もう一人のユーザーが提供した解決策もdependencyに属性を加えています.バグを報告したユーザーは最後に以下のように注釈を付けます.
My issue was introduced by gwt-user.jar that contains javax.servlet package.
Setting it as provided solved the issue.
私の問題はgwt-userを導入することです.JArは、パッケージにservletが含まれており、パッケージ(パッケージにservletに依存している可能性もある)のscopeをprovidedに変更するとokになります.現在、私たちのプロジェクトには数百数十個のパッケージが導入されています.servletが含まれているかどうかは、大きなプロジェクトになります.また、この同僚以外の同僚のtomcat起動は問題ありません.だから以上の説明は類似の問題を解決する一つの考え方にすぎないが、私たちの問題が発生した原因ではない.
さらに資料を検索すると、異なる依存にバージョンの競合を含むservletの問題を解決するための先輩が提供したソリューションもあります.この記述では、tomcat 6-maven-pluginとpaoding-roseの2つのプロジェクトのmaven依存性に起因し、この2つの依存性はservlet-apiパッケージに依存し、2つのパッケージのscopeは実行時に使用可能に設定されており、tomcat 6-maven-pluginはruntimeであり、paoding-roseはcompileスキームに提供される方法は要素を使用して実現される.
次のようになります.
以上は3つのインターネットを通じて検索する方案で、問題を解決していません;またjdk、tomcat、mavenをアンインストールして再ロードするなどします.最終的にjettyを使用してプロジェクトを開始できることがわかりました.最後のソリューションは、マシンの再インストール、環境の再配置です.
質問2:MYSQLのISNULL、IFNULL、NULLIF
ワークフロー履歴タスクをクエリーする場合、履歴タスクの承認者が格納するユーザーテーブルのユーザーcodeは、left joinユーザーテーブルが対応するユーザー名を必要とします.次のようになります.
つまりjbpm 4_taskのassigneeは空でjbpm 4_participationの参加タイプがCandidateの場合、すべての参加者が共同で参加し、いずれも候補承認者となり、1人の承認が終了すると、そのタスクが処理されます.assigneeが空のため、通常のタスクのようにクエリーを直接関連付けることはできません.ISNULL関数を使用すると、次のようになります.
この文を実行すると、mysqlはISNULL関数をサポートしていないことがわかります.sqlに似たような機能や似たような書き方を持つ関数には、IFNULLおよびNULLIFがあります.リンクが指す文章には以上の3つの関数の詳細が紹介されていますが、ここでは概要だけです.
expr 1がNULLでない場合、IFNULL()はexpr 1を返し、そうでない場合はexpr 2を返します.IFNULL()は、使用するコンテキスト環境に応じて、数値または文字列の値を返します.
expr 1=expr 2が成立する場合、戻り値はNULLであり、そうでない場合、戻り値はexpr 1である.
以上紹介したように、NULLIFがなぜこのように命名されたのか不思議で、パラメータnullの有無に関係ないようです.MYSQLではIFNULLの代わりにIFNULLを使用して、次のように変更できます.
修正してテストしたら、私たちが望んでいる結果に達することができます.
質問3:MySQL txtフォーマットフィールドの最適化について
新しい作業では、すべてのプロセス定義のlistがクエリーされ、新しいプロセスフォームがオンラインになるにつれて、すべてのプロセスリストを開く動作がますます時間がかかります.クエリー文で使用されるselect*fromの文字は、プロセス定義のすべてのプロパティにtext形式のjpdlXmlプロパティが含まれています.このプロパティには、プロセスのxml定義のテキストが格納されています.このクエリはプロセスのid、分類、名前をリストするだけなので、他のプロパティは必要ありません.jpdlXmlをselectプロパティリストから削除します.これもsql最適化の基礎的な常識であり、不要なフィールドはselectに書かないでください.jpdlXmlを削除すると、時間がかかるという問題は明らかに改善されませんでした.引き続き下を読むと、すべてのプロセス定義リストをクエリーした後、リストをフィルタリングし、以前のブログでは責任チェーンモデルに基づいて論理を最適化していた別の場所があります.フィルタリングロジックには、プロセスが新しくパブリッシュされたか、フォームが新しく保存された後にプロセス/フォームのフィールドが更新され、そのフィールドに基づいて新しい作業でプロセスが表示されるかどうかを決定する項目があります.ここでコードでは、すべてのプロセス定義リストを巡回し、プロセスに対応するformを取得します.このformをクエリーするときにも使用されるselect*ですが、formの定義テーブルにはhtmlとtemplateの2つのフィールドがあります.この2つの必須でないフィールドを削除すると、時間のかかる問題が大幅に改善され、ユーザーは待つことなくすべてのプロセスのリストを見ることができます.
この問題のヒントは、クエリーの動作をできるだけ*しないことです.
質問4:tools.jar not found
問題2を解決するために、私も私のノートパソコン(すでに1つのデスクトップとディスプレイだけがクラウドサーバーに接続されているVDIボックスがあり、会議が頻繁に開かれているため、新しく申請したノートパソコンは、リモートでデスクトップに接続するために使用され、開発環境がインストールされていない)で、新しいコードを引き出し、jdk、tomcatなど、開発環境に従って新しい環境を構成し、導入時に以下のエラーを報告します.
Fatal error compiling: tools.jar not found: C:\Program Files\Java\jre6\..\lib\tools.jar.
ネット上で一般的にこの問題の定義はeclipseのjre構成jdkのjreであり、正しい構成はjdkであるべきである.検索したところ、構成が間違っていないことがわかりました.最後に環境変数の構成を見て、Win+Rはcmdを開いて、java-versionを入力して、バージョン情報を出力していないで、環境変数の構成が間違っていることを発見します.
修復が完了した後、再びdeployはこの問題を発見しなかった.
テストから開発に移行した同僚がコードを初めて更新し、ローカルでwebプロジェクトを起動するときに、次のエラーを報告しました.
Exception starting filter encodingFilterjava.lang.ClassCastException:com.gaochao.platform.web.context.filter.ContextFilter2 can not be cast to javax.servlet.Filter
このエラーにより、tomcat/libのjarパッケージとwebappsディレクトリのアプリケーションのWEB-INF/libディレクトリの下に同じパッケージがあると思われ、バージョン上の競合があり、解決策は依存にラベルを付けることです
javax.servlet
servlet-api
${servlet-version}
provided
javax.servlet
jsp-api
${jsp-version}
provided
この考えに沿って、ラベルの使い方を探しました.以下のようにします.
*compile、デフォルト値、すべてのフェーズに適用され、プロジェクトとともにパブリッシュされます.
*providedは、compileと同様に、JDK、コンテナ、または使用者がこの依存性を提供することを望んでいる.例えばservlet.jar.
*runtimeは、JDBCドライバなどの実行時にのみ使用され、実行およびテストフェーズに適用されます.
*testは、テスト時にのみ使用され、テストコードのコンパイルおよび実行に使用されます.プロジェクトとともにパブリッシュされません.
*システムは、providedのように、依存jarを含む明示的な提供が必要であり、MavenはRepositoryでそれを検索しません.
しかし、私たちのコードにはこのラベルがあることを確認し、構成にも間違いがなく、確かにprovidedです.既に作成したwarパケットで問い合わせると、経路oa-deploytargetoa-deploy-0.0.1-SNAPSHOTWEB-INFlibでもservletのjarパケットがないことが確認され、JDK、コンテナ、または使用者がこの依存の解釈を提供することが期待されています.問題はまだこの場所にあるのではなく、さらに他の解決策があるのではないかということがわかります.さらに資料を調べたところ、http://jira.codehaus.org/MOJO-1076という番号のバグがあります.バグの説明は私たちのエラーとほぼ一致しています.もう一人のユーザーが提供した解決策もdependencyに属性を加えています.バグを報告したユーザーは最後に以下のように注釈を付けます.
My issue was introduced by gwt-user.jar that contains javax.servlet package.
Setting it as provided solved the issue.
私の問題はgwt-userを導入することです.JArは、パッケージにservletが含まれており、パッケージ(パッケージにservletに依存している可能性もある)のscopeをprovidedに変更するとokになります.現在、私たちのプロジェクトには数百数十個のパッケージが導入されています.servletが含まれているかどうかは、大きなプロジェクトになります.また、この同僚以外の同僚のtomcat起動は問題ありません.だから以上の説明は類似の問題を解決する一つの考え方にすぎないが、私たちの問題が発生した原因ではない.
さらに資料を検索すると、異なる依存にバージョンの競合を含むservletの問題を解決するための先輩が提供したソリューションもあります.この記述では、tomcat 6-maven-pluginとpaoding-roseの2つのプロジェクトのmaven依存性に起因し、この2つの依存性はservlet-apiパッケージに依存し、2つのパッケージのscopeは実行時に使用可能に設定されており、tomcat 6-maven-pluginはruntimeであり、paoding-roseはcompileスキームに提供される方法は要素を使用して実現される.
次のようになります.
net.paoding
paoding-rose
1.0-SNAPSHOT
javax.servlet
servlet-api
javax.servlet
servlet-api
2.3
provided
以上は3つのインターネットを通じて検索する方案で、問題を解決していません;またjdk、tomcat、mavenをアンインストールして再ロードするなどします.最終的にjettyを使用してプロジェクトを開始できることがわかりました.最後のソリューションは、マシンの再インストール、環境の再配置です.
質問2:MYSQLのISNULL、IFNULL、NULLIF
ワークフロー履歴タスクをクエリーする場合、履歴タスクの承認者が格納するユーザーテーブルのユーザーcodeは、left joinユーザーテーブルが対応するユーザー名を必要とします.次のようになります.
つまりjbpm 4_taskのassigneeは空でjbpm 4_participationの参加タイプがCandidateの場合、すべての参加者が共同で参加し、いずれも候補承認者となり、1人の承認が終了すると、そのタスクが処理されます.assigneeが空のため、通常のタスクのようにクエリーを直接関連付けることはできません.ISNULL関数を使用すると、次のようになります.
ISNULL(user.userName," ") as createUserCode
この文を実行すると、mysqlはISNULL関数をサポートしていないことがわかります.sqlに似たような機能や似たような書き方を持つ関数には、IFNULLおよびNULLIFがあります.リンクが指す文章には以上の3つの関数の詳細が紹介されていますが、ここでは概要だけです.
IFNULL(expr1,expr2)
expr 1がNULLでない場合、IFNULL()はexpr 1を返し、そうでない場合はexpr 2を返します.IFNULL()は、使用するコンテキスト環境に応じて、数値または文字列の値を返します.
NULLIF(expr1,expr2)
expr 1=expr 2が成立する場合、戻り値はNULLであり、そうでない場合、戻り値はexpr 1である.
以上紹介したように、NULLIFがなぜこのように命名されたのか不思議で、パラメータnullの有無に関係ないようです.MYSQLではIFNULLの代わりにIFNULLを使用して、次のように変更できます.
ISNULL(user.userName," ") as createUserCode
修正してテストしたら、私たちが望んでいる結果に達することができます.
質問3:MySQL txtフォーマットフィールドの最適化について
新しい作業では、すべてのプロセス定義のlistがクエリーされ、新しいプロセスフォームがオンラインになるにつれて、すべてのプロセスリストを開く動作がますます時間がかかります.クエリー文で使用されるselect*fromの文字は、プロセス定義のすべてのプロパティにtext形式のjpdlXmlプロパティが含まれています.このプロパティには、プロセスのxml定義のテキストが格納されています.このクエリはプロセスのid、分類、名前をリストするだけなので、他のプロパティは必要ありません.jpdlXmlをselectプロパティリストから削除します.これもsql最適化の基礎的な常識であり、不要なフィールドはselectに書かないでください.jpdlXmlを削除すると、時間がかかるという問題は明らかに改善されませんでした.引き続き下を読むと、すべてのプロセス定義リストをクエリーした後、リストをフィルタリングし、以前のブログでは責任チェーンモデルに基づいて論理を最適化していた別の場所があります.フィルタリングロジックには、プロセスが新しくパブリッシュされたか、フォームが新しく保存された後にプロセス/フォームのフィールドが更新され、そのフィールドに基づいて新しい作業でプロセスが表示されるかどうかを決定する項目があります.ここでコードでは、すべてのプロセス定義リストを巡回し、プロセスに対応するformを取得します.このformをクエリーするときにも使用されるselect*ですが、formの定義テーブルにはhtmlとtemplateの2つのフィールドがあります.この2つの必須でないフィールドを削除すると、時間のかかる問題が大幅に改善され、ユーザーは待つことなくすべてのプロセスのリストを見ることができます.
この問題のヒントは、クエリーの動作をできるだけ*しないことです.
質問4:tools.jar not found
問題2を解決するために、私も私のノートパソコン(すでに1つのデスクトップとディスプレイだけがクラウドサーバーに接続されているVDIボックスがあり、会議が頻繁に開かれているため、新しく申請したノートパソコンは、リモートでデスクトップに接続するために使用され、開発環境がインストールされていない)で、新しいコードを引き出し、jdk、tomcatなど、開発環境に従って新しい環境を構成し、導入時に以下のエラーを報告します.
Fatal error compiling: tools.jar not found: C:\Program Files\Java\jre6\..\lib\tools.jar.
ネット上で一般的にこの問題の定義はeclipseのjre構成jdkのjreであり、正しい構成はjdkであるべきである.検索したところ、構成が間違っていないことがわかりました.最後に環境変数の構成を見て、Win+Rはcmdを開いて、java-versionを入力して、バージョン情報を出力していないで、環境変数の構成が間違っていることを発見します.
修復が完了した後、再びdeployはこの問題を発見しなかった.