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 http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
