On Tue, Aug 23, 2011 at 8:04 AM, Emond Papegaaij <[email protected]> wrote: > On Tuesday 23 August 2011 16:17:43 Igor Vaynberg wrote: >> On Tue, Aug 23, 2011 at 1:16 AM, Emond Papegaaij >> >> <[email protected]> wrote: >> > On Tuesday 23 August 2011 09:04:00 Igor Vaynberg wrote: >> >> On Mon, Aug 22, 2011 at 11:44 PM, Emond Papegaaij >> >> >> >> <[email protected]> wrote: >> >> > For example, objects managed by weld are not detached at the end >> >> > of a request. >> >> >> >> erm? what is supposed to happen when? >> >> >> >> -igor >> > >> > That's something I'm not entirely sure of. The current implementation >> > makes it cumbersome to work with models inside scoped objects (requests >> > can share the same objects instances, causing multi-threading issues). >> > I'm aware of the fact that is inherent to the way the scopes work, but >> > it would be nice to have wicket-weld provide a way to cope with this. >> > Putting it in 1.5 leaves no time to (try to) develop an api to deal with >> > this. >> >> not entirely sure what you mean. requestsope and conversation scopes >> are threadsafe. session and application scopes are not, but that is >> something you have to be aware of and deal with just like with any >> other IOC framework... > > Are you sure that conversation scopes are threadsafe? The same conversation > can be shared across multiple requests. When some of these requests happen > simultaneously, I expect the conversation scoped objects to be accessed in a > multithreaded way. > I do not yet know how to cope with this, but it is something I will be > investigating in the next couple of days. Perhaps, wicket-weld (or cdi) needs > its own representation for the conversation scope, just as it has its own > applicatoin, session and request objects.
from the spec """The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.BusyConversationException...""" >> > Igor: >> > Did you move your code for wicket-weld to another place, or did you >> > delete it? We are really interested in this code, and are currently >> > adding it to our project. For now I've resurrected it at >> > github.com/papegaaij/wicket-weld. It would be nice if it is placed >> > somewhere more central, where it could be developed further to be >> > included in Wicket at some later time. >> >> i will be moving it into 42lines github repo today. i was going to >> move it to wicketstuff but that is not possible because weld artifacts >> are not in central yet. > > Great. Could you post the location on this list when you placed it there, so I > can clone it? For now, we at Topicus will be maintaining or own clone, to > allow us to follow our own release management, but it would be great if we can > sync it with an 'upstream' repo. will do.... > > I'm still quite new to CDI and Weld. Do you know any good resources (books?) > on this? I've found the Weld documentation very useful, but it's more of a > reference guide, rather than a book. i didnt use a book, so dont know of any good ones out there. sorry. -igor > > Emond >
