問題タブ [seam-conversation]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
365 参照

java - ExternalContext.redirect() の後、一時的な会話が終了しない

Seam と JSF を使用するプロジェクトに取り組んでいます。なんらかの理由で (聞かないでください。わかりません)、私の前の人々は、FacesContext.getExternalContext().redirect() を介してユーザーを応答ページにリダイレクトすることにしました。私が見ている問題は、一部のページが自分自身にリダイレクトされたときに会話を解放しないことです (conversationId は URL で常に同じです)。誰かが同様の問題を抱えていましたか?ありがとう

0 投票する
1 に答える
272 参照

java - 一時会話終了疑惑

私は最近 Seam を使用していますが、一時的な会話にはまだ混乱しています。

私たちのプロジェクトではExternalContext.redirect()、ユーザーを応答ページにリダイレクトするために使用しています。私が読んだところによると、Seam の会話は、応答のレンダリング フェーズが呼び出されると終了します。

しかし、別の場所で次のように読みました: Seam は JSF のポストバックとリダイレクトを介して会話コンテキスト (一時的な会話コンテキストを含む) を透過的に伝搬します

したがって、同じページにリダイレクトすると、commandLinks のアクション URL には常に同じ conversationId が追加されます。ページにあるように、一時的な会話を終了しようとしました <f:param name="conversationPropagation" value="none"/>が、リダイレクトされたページがレンダリングされると、会話コンテキストはすでに fred になり、使用している Bean は応答で使用できなくなります。

だから私が知りたいのは、リダイレクトで会話を終了し、応答のレンダリングまでコンテキストを維持する方法があるかどうかということですか?

そうでない場合、一時的な会話はいつ終了しますか? 会話のコンテキストはリダイレクトとポストバックを介して伝播されるため、終了することはありません。

0 投票する
3 に答える
8826 参照

seam - 会話への同時呼び出し

Seam を使用していますが、「Concurrent call to conversation」エラーが発生します。これは何を意味するのでしょうか?

処理に 5 分かかるボタンがあります。このエラーは 2 分以内に発生します。同時要求タイムアウトを 10 分に設定しても機能しないようです。最初のリクエストが完了するまで他のすべてのリクエストをブロックする方法はありますか?

0 投票する
3 に答える
2677 参照

java - 長時間の会話はありません - IllegalArgumentException: Stack must not be null

WebLogic 10.3.2 (11g)、Seam 2.2.0.GA で 2 ページしかない非常に単純なアプリケーションがあります。それぞれにコマンド ボタンがあり、他のボタンへのリダイレクト後ポストを行います。アドレスバーに表示されている現在のページの URL が表示されるため、これはうまく機能します。

しかし、私は長時間の会話を定義していませんが、ランダムな数のクリックの後、そして - 私が思うに - ランダムな秒数 (~10 秒 - 60 秒) の後、私はこの記事の最後に素敵な例外を受け取ります.

ここで、リダイレクト時に一時的な会話がどのように機能するかを理解していれば、次のことが起こります。

  1. アプリケーションを初めて見たとき、URL はhttp://localhost:7001/myapp です。
  2. pageA.xhtml のボタンをクリックすると、「pageB.xhtml?cid=26」になります。Seam は最初のリクエストの一時的な対話をリダイレクトの renderResponse フェーズまで持続するように拡張するため、これは正常です。そのため、拡張された一時会話の cid (会話 ID) を使用して、伝達されたパラメーターを見つけます。

  3. pageB.xhtml のボタンをクリックすると、pageA.xhtml?cid=26 になります。

同じ cid が新しい拡張一時会話に与えられました。これは、前回のリダイレクト後ポストの最後で会話が終了したため正常であり、26 番は cid として自由に使用できるわけではありません。

これはすべて正しいですか?はいの場合、なぜこのようなことが起こるのでしょうか: アプリケーションのホーム アドレス (pageA を表示) を再入力して再度クリックすると、26 とは異なる番号である pageB.xhtml?cid=29 になります。しかし、26 は終了しています。前の RenderResponse フェーズの後、URL を再入力します。29 の代わりに使用されないのはなぜですか?

それで、補足するために、2つの質問:

  1. 長時間の会話を開始していないにもかかわらず、例外が発生するのはなぜですか?
  2. シドで正確に何が起こりますか?何を基準に変わるの?

乾杯、

アップデート:

追加情報: ページ A では、次のように h:commandButtons を使用します。

そしてページBで

ナビゲーション pageA.page.xml:

pageBの場合も非常に似ています。

会話のタイムアウトについては、1h に設定しています。ここで読んだように、バックグラウンドでの会話のみを目的としているため、無関係であることに注意してください。スタックトレースは次のとおりです。

0 投票する
1 に答える
2691 参照

java - Redirect 使用時に Seam 会話が突然終了する

会話が突然終了するとエラーが発生するため、プロジェクトで問題を再現するテスト ページをいくつか作成しました。ナビゲーションは、pageA.xhtml と pageB.xhtml の間で行われます。何か間違った使い方をしている場合は教えてください。

私の設定: Seam 2.2.0.GA WebLogic 10.3.2 (11g) Richfaces 3.3.2 JSF 1.2

注: 注釈を使用して会話を開始/終了する場合も同じことが起こります

=======

ページA

=======

ページB

==========

例外:

これは、ランダムな数のリダイレクトの後に発生します。

javax.faces.FacesException:

{pagebAction.redirectA()}: java.lang.IllegalStateException: いいえ

com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118) でアクティブな会話コンテキスト javax.faces.component.UICommand.broadcast(UICommand.java:387) で org.ajax4jsf.component.AjaxViewRoot.processEvents( AjaxViewRoot.java:324) org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:299) org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:256) org.ajax4jsf.component.AjaxViewRoot.processApplication (AjaxViewRoot.java:469) com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82) com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) com.sun. faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) javax.faces.webapp.FacesServlet で。weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) の service(FacesServlet.java:265) weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) weblogic.servlet.internal の.ServletStubImpl.execute(ServletStubImpl.java:292) の weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) の weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) の org.ajax4jsf。 weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) の webapp.BaseFilter.doFilter(BaseFilter.java:530) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) のorg.jboss の org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) で。org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) の seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter( SeamFilter.java:69) org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) org.jboss org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) の .seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java) :178) org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) で org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388) org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) で org.jboss.seam.servlet.SeamFilter$FilterChainImpl で org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) の .doFilter(SeamFilter.java:69) org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) のweblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) の org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java: 27) weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction の weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) で。run(WebAppServletContext.java:3592) で weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) で weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) で weblogic.servlet.internal .WebAppServletContext.securedExecute(WebAppServletContext.java:2202) の weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) の weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) の weblogic.work。 weblogic.work.ExecuteThread.run(ExecuteThread.java:173) での ExecuteThread.execute(ExecuteThread.java:201) 原因: javax.faces.el.E​​valuationException: java.lang.IllegalStateException: No conversation context active at javax.faces .component.MethodBindingMethodExpressionAdapter.com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) での invoke(MethodBindingMethodExpressionAdapter.java:102) ... 45 以上 原因: java.lang.IllegalStateException: org.jboss でアクティブな会話コンテキストがありません。 org.jboss.seam.Component.getValueToInject(Component.java:2325) の seam.ScopeType.getContext(ScopeType.java:133) org.jboss の seam.Component.injectAttributes(Component.java:1736) org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) で .seam.Component.inject(Component.java:1554) org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61) ) org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:65) で org.org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext. java:68) org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) で org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185) で org.jboss.seam.intercept .JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103) at eu.emea.pim.prs.web.seamsandbox.PagebAction_$$_javassist_seam_8.redirectA(PagebAction_$$_javassist_seam_8.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(ネイティブメソッド) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) で sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) で java.lang.reflect.Method.invoke(Method.java:597) で org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil) .java:335) org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:280) org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59) org.jboss.el. org.jboss.el.parser.AstValue.invoke(AstValue.java:96) の parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65) com の org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) .sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68) javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) ... 46 件以上

0 投票する
1 に答える
188 参照

java - 各ページ リクエストの後、conversationId が増加し続けるのは正常ですか?

こんにちは、私は Seam アプリケーションを構築していますが、質問があります。

delete メソッドと select メソッドを備えたステートレス セッション Bean (デフォルトの seam スコープ) を取得しました。データモデルを含むページがロードされ、各行を選択および削除するためのリンクが取得されます (両方のリンクは Bean のアクションメソッドを参照します)。

delete メソッドは、選択した行をリストから削除し、null を返します (ページをリロードします)。select メソッドは、選択した行を編集できる新しいページをロードします。

データモデル内のリンクがクリックされてアクションが起動されるたびに、conversationId が増加します。会話すらしていないので、これは正常な動作ですか?これが通常の動作ではない場合、これを防ぐためのベスト プラクティスは何ですか?

0 投票する
4 に答える
5407 参照

seam - 会話例外への同時アクセスを回避するための、concurrent-request-timeout パラメーターまたはオプションの実用的な値

Seam リファレンス ガイドには、次の段落があります。

components.xml で、同時リクエストのタイムアウト (ミリ秒単位) の適切なデフォルトを設定できます。

ただし、500 ミリ秒では、対処しなければならないほとんどのケース、特に会話アクセスの厳しい制限の継ぎ目では十分ではないことがわかりました。

私たちのアプリケーションでは、ページ スコープの ajax リクエスト (さまざまなユーザー アクションによってトリガーされる)、いくつかのグローバル スコープのポーリング通知ロジック (ヘッダーの一部であるため、すべてのページに含まれます)、およびアクションを呼び出したり他のページに移動したりする通常のリンクの組み合わせがあります。ページ。

したがって、サイトに大きな負荷がかかっていなくても、会話例外への恐ろしい同時アクセスが頻繁に発生します。

オプションをかなり調査した後、推奨される解決策のいずれも問題を完全に解決できないようだったため (グローバルなすべての ajax リクエストのキューは、ポーリング呼び出しの 1 つが進行中のときに、ユーザーがリンクをクリックすることを決定する危険にさらされたままになります)。また、間違ったタイミングでリンクをクリックしたという理由だけでエラー ページが表示されるのではなく、ユーザーに 1 ~ 2 秒待ってもらいたいと考えています。

そして、ここで質問があります: 何か明らかに欠けているものはありますか? seam でこの問題 (ユーザー主導の対話と混合された ajax リクエスト) をどのように解決しますか? ajax リクエストの進行中にページ上のすべてのリンクを無効にする (あるブログ ページで提案されているように) ことは、実際には実行可能なオプションではありません。

他の提案はありますか?

ティア、アンドレイ

0 投票する
2 に答える
404 参照

seam - Seamはクライアントブラウザで会話状態をどのように保存しますか?

Seamのドキュメントによると、会話状態(リンクの最後の行を参照)は、サーブレットセッションではなくクライアントブラウザに保存されるように構成できます。誰か教えてもらえますか:

  1. この構成はどのように設定されていますか?
  2. Seamは実際にどのようにして会話状態をブラウザに内部的に保存しますか?
0 投票する
1 に答える
1198 参照

seam-conversation - Seam の EJBQL での制限の使用

私は Seam に非常に慣れていないので、この以下のコードを明確にする必要があります。どのように機能するか、このコードでの RESTRICTIONS の使用法を知る必要があります .......

0 投票する
1 に答える
1748 参照

ajax - Seamでセッションと会話を存続させる

Seamでのセッションと会話の処理方法に問題があります。ほとんどの場合、最初の画面に入力を開始し、バックグラウンドでいくつかのアクションが実行され、ユーザーがコンピューターを離れて作業を行った後、戻って作業に注釈を付ける、かなり長いフォームがあります。

問題は、ほとんどの場合、セッションがタイムアウトしたり、会話がタイムアウトしたりすることです。2つ目はワークフローを分割することで簡単に修正できますが、1つ目はより重要です。ユーザーは再度ログインし、右側の画面に移動してから、注釈を入力する必要があるためです。

バックグラウンドでセッションの更新をトリガーするAjaxのスニペットを作成する簡単な方法はありますか?これにより、セッションを無期限に存続させることができます。

また、会話を存続させる簡単な方法はありますか?