|
From: roger h. <apo...@sn...> - 2003-11-20 19:46:34
|
Hi Juergen
As Mark's experience has just demonstrated, the fact that FactoryBean's are
not required to be singleton's does provide a very ready source of confusion
for the uninitiated. The only reason I was aware of this problem, was
because initially I too was very confused, until I had spent good deal of
time working out what the code was actually doing.
I would definitely favour option 2.
While we're on the subject of FactoryBean's and their curiosities, another
thing that took me a long time to work out was the non-uniform dereferencing
of factory bean names. ie isSingleton() and getBean() do not behave
consistently.
If I have a prototype FactoryBean named "proto", ie:
<bean id="proto"
class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="singleton"><value>false</value></property>
</bean>
a call to
beanFactory.isSingleton("proto");
will return true, but repeated calls to
beaFactory.getBean("proto")
will indeed return separate prototype instances.
Personally, I find this very counterintuitive and would be happy to see this
changed ;)
Roger
"jürgen höller [werk3AT]" <jue...@we...> wrote in message
news:170...@co......
Roger,
This is indeed true, and I have not been aware of it: If a FactoryBean is
defined as prototype, getBean will currently return the FactoryBean itself.
There are obviously two solutions for this:
1. make getBean return the FactoryBean-created object even for FactoryBean
prototypes
2. require FactoryBeans to be defined as singletons by forbidding
singleton="false"
Option 2 isn't bad in the first place, as it's hard to image why a
FactoryBean itself should be a prototype. Of course, option 1 could be
easily implemented too, and it leaves the choice to the application
developer. Opinions?
We should definitely address this for 1.0 M3, to be released this weekend!
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of roger holbrook
Sent: Thursday, November 20, 2003 7:28 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Intercepting a Prototype Bean
Rod
I think this is a probably bug in AbstractBeanFactory - currently any
getBean() for a FactoryBean that was defined with a bean attribute of
singleton="false", will always return the FactoryBean instance, rather than
a Proxy instance. This happens because createBean() does not do any factory
dereferencing.
One fix would just be to trap the combination when the beans are being
defined.
Even if createBean() were actually handling the dereferencing correctly,
I think there would still be a problem on a normal sequence of getBean()
calls - since each call would generate a new FactoryBean instance and a new
Proxy instance, but the application code would only ever see a reference to
the latter. Application code would only be able collect references to the
FactoryBean themselves by explicitly calling getBean("&name"), and then
using these to generate Proxy instances.
A bit confusing really
Roger
"Rod Johnson" <rod...@in...> wrote in message
news:06aa01c3af8b$d4467c90$e900a8c0@chopin...
> Mark,
>
> > Is it possible to apply an interceptor to a prototype bean?
> Yes.
>
> > The prototype is stateful - i.e one per user
> Yes, Spring supports mixins, ie one interceptor per mixin instance.
>
> > I have defined the following in applicationContext.xml
> >
> >
> > <bean id="TestTarget" class="test.MyTarget" singleton="false">
> > </bean>
> >
> >
> > <bean id="TestInterceptor"
> >
>
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBe
> > an" singleton="false">
> > <property name="transactionManager"><ref
> > local="transactionManager"/></property>
> >
> > <property name="target"><ref local="TestTarget"/></property>
> >
> >
> > <property name="transactionAttributes">
> > <props>
> > <prop key="foo">PROPAGATION_REQUIRED</prop>
> > </props>
> > </property>
> > </bean>
> >
> >
> >
> > When I invoke the method foo I get a ClassCastException
>
> Not sure why this is happening but you may need to create the interceptor
> chain manually to use a prototype, as TransactionProxyFactoryBean propably
> assumes it's dealing with a singleton. So you need to create a chain that
> includes:
> - the name of your prototype
> - the interceptor names, which may be singletons or prototypes as you
> require. Use a prototype for mixin support.
>
> The following example comes from the test suite, with minor changes to
make
> it more obvious:
>
>
> <bean id="prototypeTarget"
> class="org.springframework.aop.interceptor.SideEffectBean"
> singleton="false">
> <property name="count"><value>10</value></property>
> </bean>
>
> <!-- This can be a singleton or a prototype (for mixin behaviour) -->
> <bean id="debugInterceptor"
> class="org.springframework.aop.interceptor.DebugInterceptor">
> </bean>
>
>
> <bean id="prototype"
> class="org.springframework.aop.framework.ProxyFactoryBean">
> <!-- will automatically create invoker interceptor for the prototype -->
> <property
>
name="interceptorNames"><value>debugInterceptor,prototypeTarget</value></pro
> perty>
>
> <!-- Note this -->
> <property name="singleton"><value>false</value></property>
> </bean>
>
> There is a bug in M2 to do with prototype AOP handling, which is fixed in
> the forthcoming M3. However I don't think it should affect you in such a
> simple usage.
>
>
> Regards,
> Rod
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
|