On Sat, 2006-09-30 at 19:58 +0200, Jörn Nettingsmeier wrote: > after some digging in the archives, i found traces of an apocryphal > thread, "[trunk] usecases: stateless services or objects ?". > unfortunately, neither nabble nor gmane had anything like it, and > searching for POJO yields only messages like "there was a thread about > usecases as POJOs recently".. :) > > can anyone give a pointer?
Hm, i couln't find the thread in the archives either, it seems to have vanished... (why does that happen?) Luckily I never deleted my local mails since then :) The thread happened around 13th april 2005 and had the subject: Re: [trunk] usecases: stateless services or objects ? (Was Re: svn commit: r161162 - lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java) I'm pasting the entire thread below (it's rather long): *************************************************************** [EMAIL PROTECTED] wrote: > Author: jwkaltz > Date: Wed Apr 13 00:31:55 2005 > New Revision: 161162 > > URL: http://svn.apache.org/viewcvs?view=rev&rev=161162 > Log: > [minor change] use already available publication instead of lookup We have to be careful here. The usecase is disposed and re-initialized between the views. The parameters are stored by the UsecaseProxy and handed back to the usecase after re-creation. All field values are lost. I don't know if this will cause problems within the Create usecase, I just wanted to state the problem. -- Andreas *************************************************************** Andreas Hartmann schrieb: > [EMAIL PROTECTED] wrote: > >> Author: jwkaltz >> Date: Wed Apr 13 00:31:55 2005 >> New Revision: 161162 >> >> URL: http://svn.apache.org/viewcvs?view=rev&rev=161162 >> Log: >> [minor change] use already available publication instead of lookup > > > We have to be careful here. The usecase is disposed and re-initialized > between the views. The parameters are stored by the UsecaseProxy and > handed back to the usecase after re-creation. All field values are lost. This is an important point - this means all use cases must be stateless, right ? I wonder if we can use some mechanism to enforce that. > > I don't know if this will cause problems within the Create usecase, I just > wanted to state the problem. In this particular case the change was to use the parent's reference to the publication, which already exists, instead of re-creating a publication reference. So shouldn't have anything to do with the issue above. *************************************************************** J. Wolfgang Kaltz wrote: > Andreas Hartmann schrieb: > >> [EMAIL PROTECTED] wrote: >> >>> Author: jwkaltz >>> Date: Wed Apr 13 00:31:55 2005 >>> New Revision: 161162 >>> >>> URL: http://svn.apache.org/viewcvs?view=rev&rev=161162 >>> Log: >>> [minor change] use already available publication instead of lookup >> >> >> >> We have to be careful here. The usecase is disposed and re-initialized >> between the views. The parameters are stored by the UsecaseProxy and >> handed back to the usecase after re-creation. All field values are lost. > > > This is an important point - this means all use cases must be stateless, > right ? Yes, I'm afraid this is true. I'm not pleased with the situation, but the only other solution is to avoid implementing usecases as services so they don't have to be released between the views. WDYT? > I wonder if we can use some mechanism to enforce that. That would certainly be helpful. The only thing that comes into my mind is reflection. >> I don't know if this will cause problems within the Create usecase, I >> just >> wanted to state the problem. > > > In this particular case the change was to use the parent's reference to > the publication, which already exists, Maybe this was a remnant from the days before stateless usecases ... We'll see if any problems occur :) -- Andreas *************************************************************** Andreas Hartmann schrieb: >> (...) >> This is an important point - this means all use cases must be >> stateless, right ? > > > Yes, I'm afraid this is true. I'm not pleased with the situation, but > the only other solution is to avoid implementing usecases as services > so they don't have to be released between the views. > > WDYT? So the question is what is gained from implementing usecases as services vs. "normal" Java objects. IIUC (please correct if wrong) having usecases as services delegates (some) responsibility for object lifecycle, configuration, logging initialization to Avalon. We retrieve usecase instances by going through the UsecaseResolver (which is a service). Its implementation currently relies on Avalon service selection; which is as it should be since the usecases are also services. The configuration of the usecases is specified in the cocoon.xconf The problem is the following: when the user requests a (multiple-step) use-case, a service instance for the use-case is created to handle the first step. But, since we don't know whether the user will properly complete the use-case (by pressing save or cancel), the service instance is released right away. For the next step of the usecase, a usecase instance is recreated via the UsecaseProxy, which resets all original parameters - but not field values, obviously. So this means the usecase implementations must be stateless. We do this so that no dead service instances lie around; which, especially accumulated over the lifetime of the servlet container, would hold system resources. If the usecase wasn't a service, but just a normal Java object retrieved in the flowscript, Cocoon would handle its state between the views, and the object reference would disappear at the end of the flow (so it can be removed by the garbage container sometime after that). So in this case, the usecases could hold state. BTW I wonder what Cocoon does if the continuation is never called. I would suppose the continuation stays active as long as the session exists, along with the objects involved. So that shouldn't be a problem, thx to session timeouts. If we decide that usecases should not be services: since access to usecase instances is handled via the UsecaseResolver, the UsecaseResolverImpl encapsulates how usecases are initialized, so it transparently handles stuff like usecase configuration & logging initialization, even if the usecases were not services. Of course this would require significant changes to the UsecaseResolverImpl implementation. Personally I'm not sure ATM what approach is best; though requiring usecases to be stateless does seem quite constraining (and risky), so that would favor not having usecases as services. Wolfgang *************************************************************** J. Wolfgang Kaltz wrote: > Andreas Hartmann schrieb: > >>> (...) >>> This is an important point - this means all use cases must be >>> stateless, right ? >> >> >> >> Yes, I'm afraid this is true. I'm not pleased with the situation, but >> the only other solution is to avoid implementing usecases as services >> so they don't have to be released between the views. >> >> WDYT? > > > So the question is what is gained from implementing usecases as services > vs. "normal" Java objects. [...] > BTW I wonder what Cocoon does if the continuation is never called. I > would suppose the continuation stays active as long as the session > exists, along with the objects involved. So that shouldn't be a problem, > thx to session timeouts. I assume this as well, but I'm not sure. > If we decide that usecases should not be services: > since access to usecase instances is handled via the UsecaseResolver, > the UsecaseResolverImpl encapsulates how usecases are initialized, so it > transparently handles stuff like usecase configuration & logging > initialization, even if the usecases were not services. Of course this > would require significant changes to the UsecaseResolverImpl > implementation. Yes, IMO this is the major drawback. The initialization of the usecase handler could be handled by the resolver as a single entry point to usecase object creation. But the configuration is very convenient using the Avalon service deployment in cocoon.xconf ... Maybe it would be possible to use a builder class for this purpose? <component-instance name="edit.forms" logger="lenya.publication" class="org.apache.lenya.cms.usecases.UsecaseBuilder"> <handler class="org.apache.lenya.cms.editors.forms.FormsEditor"/> <transaction policy="pessimistic"/> <view template="edit/forms/forms" menu="false"/> </component-instance> The usecase resolver would then delegate the usecase POJO initialization to the usecase builder. Maybe this is the cleaner solution, we could get rid of the UsecaseProxy. -- Andreas *************************************************************** Andreas Hartmann wrote: >> BTW I wonder what Cocoon does if the continuation is never called. I >> would suppose the continuation stays active as long as the session >> exists, along with the objects involved. So that shouldn't be a >> problem, thx to session timeouts. i am pretty sure there is a reaper thread that cleans up continuations after the continuation livetime is up. *************************************************************** > > looking at usecases.js, i realized we do not release the flowHelper, > which iiuc is an avalon component just like the usecaseResolver. bug or > feature? > no idea about this one. josias --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
