cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Apples enhancements
Date Wed, 07 Mar 2007 06:51:44 GMT
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>> Leszek Gawron wrote:
>>> What 'apple initialization options' are you refering to ?
>>
>>  - Thread.currentThread().getContextClassLoader().loadClass(appleName);
>>  - sitemapManager.lookup(beanName);
> 
> And why would you like to mix those? Either you want managed apples or 
> you don't. If some do not need to be managed the only thing you need to 
> do is:
> 
> <bean id="appleName" class="o.a.c.apples.AppleName" scope="prototype"/>
> 
> and you have the same functionality but more consistent.

right and as your solution was in place first, I will remove the support for 
#[bean-name] apples (btw, sooner or later we should deprecate the "call 
function" as it doesn't fit for a generic controller concept at all)

> There is one more thing that I dislike about current apples + spring 
> integration: you can mix ApplesController vs. StatelessApplesController 
> (which triggers different continuations handling) and prototype scope 
> vs. singleton scope.
> 
> The most dangerous situation is marking a bean singleton and not 
> implementing StatelessAppleController. This way a continuation will be 
> created with a singleton apple which other threads also will use.
> 
> Simply put: ApplesProcessor.callFunction should not depend on marker 
> interfaces if used with managed apples.

What do you want to say? Shall we disallow singleton scoped beans that do not 
implement StatelessAppleController?

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message