cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: Apples enhancements
Date Wed, 07 Mar 2007 18:11:14 GMT
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>> Reinhard Poetz wrote:
>>> 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)
>> Do not get me wrong. You are way more experienced so I don't feel like 
>> enforcing my solution (which is btw a 5 liner). Still some discussion 
>> won't hurt :)
> The only argument for making both options available is less 
> configuration. But thinking more about it, I probably want all my Apples 
> being managed by Spring in the future.
>>>> 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?
>> Exactly. There is no point in such construct (at least I don't see it) 
>> and it may be a very dangerous mistake to be made.
> I Will look into it. I think it is possible to prevent it since with 
> Carsten's help we have access to the Spring app context in the 
> interpreter now which should make it possible to find out a bean's scope.

There is a small gotcha': currently managed apples are looked up using a 
service manager, not spring directly. Should we switch to spring lookup?

One more thing: even if a bean is spring managed it is being 
instantiated with LifecycleHelper anyway.

I'll try to commit some fix (laaack of time).

Leszek Gawron               
CTO at MobileBox Ltd.

View raw message