Menu
▾
▴
Re: [Springframework-developer] Intercepting a Prototype Bean
|
From: <jue...@we...> - 2003-11-20 21:26:05
|
I've already implemented option 2, i.e. throwing a =
BeanDefinitionStoreException if a FactoryBean is defined as prototype. =
I'll also adapt isSingleton, as I agree that the current behavior for =
FactoryBeans is counter-intuitive.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von roger holbrook
Gesendet: Do 20.11.2003 20:45
An: spr...@li...
Betreff: [Springframework-developer] Re: Re: Intercepting a Prototype =
Bean
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=3D"proto"
class=3D"org.springframework.aop.framework.ProxyFactoryBean">
<property name=3D"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=FCrgen h=F6ller [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=3D"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=3D"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=3D"TestTarget" class=3D"test.MyTarget" singleton=3D"false">
> > </bean>
> >
> >
> > <bean id=3D"TestInterceptor"
> >
>
class=3D"org.springframework.transaction.interceptor.TransactionProxyFact=
oryBe
> > an" singleton=3D"false">
> > <property name=3D"transactionManager"><ref
> > local=3D"transactionManager"/></property>
> >
> > <property name=3D"target"><ref local=3D"TestTarget"/></property>
> >
> >
> > <property name=3D"transactionAttributes">
> > <props>
> > <prop key=3D"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=3D"prototypeTarget"
> class=3D"org.springframework.aop.interceptor.SideEffectBean"
> singleton=3D"false">
> <property name=3D"count"><value>10</value></property>
> </bean>
>
> <!-- This can be a singleton or a prototype (for mixin behaviour) -->
> <bean id=3D"debugInterceptor"
> class=3D"org.springframework.aop.interceptor.DebugInterceptor">
> </bean>
>
>
> <bean id=3D"prototype"
> class=3D"org.springframework.aop.framework.ProxyFactoryBean">
> <!-- will automatically create invoker interceptor for the prototype =
-->
> <property
>
name=3D"interceptorNames"><value>debugInterceptor,prototypeTarget</value>=
</pro
> perty>
>
> <!-- Note this -->
> <property name=3D"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/
-------------------------------------------------------
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
|
