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 08:20:51 GMT
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.

-- 
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