You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/04/13 11:55:22 UTC

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)

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


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)

Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org