On Tue, Aug 23, 2011 at 9:13 PM, Igor Vaynberg <[email protected]> wrote: > 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. ivaynberg writes books, he don't read books! > > -igor > >> >> Emond >> >
-- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
