Thanks for the reply.
The cid is passed correctly via page forwards, we are trying to avoid
ever having it appear in the browser address bar because if a user
bookmarks it, it will crash on the following session due to an invalid
The case I'm trying to solve here is how to stop a user refreshing the
page creating multiple new conversations which causes the package of
work to reload multiple times. Each package has a unique ID so the
mapper of conversation ID to this package ID seems a natural one for us.
For example, the URL already has a page.xhtml?packageId=123 on it which
allows us to (hopefully) bring them back to their current running
conversation if we can successfully reactivate it.
On 13/08/2018 5:22 pm, Matej Novotny wrote:
a conversation is identified by its ID and if it is already active, you should be adding
the 'cid' parameter with proper value to your requests.
This of course requires the conversation to be long-running which I assume you have.
Is this what you meant?
----- Original Message -----
> From: "James ." <cube_00(a)hotmail.com>
> To: weld-dev(a)lists.jboss.org
> Sent: Sunday, August 12, 2018 8:53:05 AM
> Subject: [weld-dev] Reattach to conversation
> I want to join an existing conversation scope.
> I start the conversation with:
> I got close with using the following which seems to work:
> @Inject @Http CoversationContext context;
> However I'm seeing a warning in the log which suggests I'm not getting it
> WARN: WELD-000335: Conversation context is already active, most likely it was
> not cleaned up properly during previous request processing:
> HttpServletRequestImpl [ POST /path/to/url ]
> I'm also happy if there is an alternative way to just drop the conversation
> and recreate (so long as I can continue using the same custom conversation
> ID) I'm trying to avoid the user reloading the page multiple times filling
> up memory with duplicates of the same package data.
> I also considered using a @SessionScoped bean but I thought if I can set the
> package ID to be the conversation ID then I can avoid the need to manage a
> @SessionScoped bean.
> weld-dev mailing list