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