cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: Apples enhancements
Date Tue, 06 Mar 2007 17:44:53 GMT
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>> Reinhard Poetz wrote:
>>> Leszek Gawron wrote:
>>>> Reinhard Poetz wrote:
>>>>>
>>>>> I added/changed three things in Apples:
>>>>>
>>>>>  - Apples can be Spring beans. In order to lookup a bean, prepand 
>>>>> #, e.g. to lookup a bean of name 'myBean', use <map:call 
>>>>> function="#myBean"/>.
>>>>>
>>>>>  - Add an AppleNotFoundException which informs why an Apple can't 
>>>>> be initialized.
>>>>>
>>>>>  - Add sendStatus() to the AppleResponse interface.
>>>>>
>>>>> Comments?
>>>> I think you implemented a duplicate. Some time ago I have commited 
>>>> ServiceApplesProcessor which looks up apples using service manager.
>>>>
>>>> The only thing you have to to is to use different "flow language"
>>>
>>> I see, but I don't like to have another flow language because I want 
>>> to use both Apple initialization options in the same sitemap. WDYT?
>>
>> 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.


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.

-- 
Leszek Gawron                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.


Mime
View raw message