AbstractConversationContext#getConversationIdGenerator() is inherently racy in the case where the generator has not been created yet. If multiple threads happen to enter it at the same time, they might create multiple generators, which in turn leads to duplicate conversation IDs.

This is essentially the same issue as WELD-1418, but the fix for that issue only fixed HttpConversationContextImpl. BoundConversationContextImpl still has a problem because nothing will call sessionCreated() for it. Even if something did, I don't think that would fix the problem since that just copies the generator from the request to the session and the request may not have a generator yet either. There's also the headache that sessionCreated() is a public method but is not part of the BoundConversationContext interface, so the calling code would have to cast to an implementation class.

Workaround: call generateConversationId() at some early point when there can't be multiple threads competing with each other:

boundConvCtx.associate(fakeRequest);
try {
	boundConvCtx.generateConversationId();
} finally {
	boundConvCtx.dissociate(fakeRequest);
}