Menu
▾
▴
springframework-developer
|
From: Colin S. <col...@ex...> - 2004-04-29 18:35:06
|
I just realized that TransactionProxyFactoryBean always returns true for
ProxyFactoryBean's the isSingleton() method, and internally does not
support non-singleton operation, since it only sets up the proxy once in
afterPropertiesSet().
I have a case where a client of the beanfactory is using
bf.getBean("xxx"), and needs to get back a new transactionally wrapped
instance on every call, sine the object is stateful, unlike every other
service I've wrapped transactionally so far.
Does anybody know why the class was set up to operate in singleton mode
only? It makes sense as a default of course, but I can't see anything in
the code precluding allowing it to operate in non-singleton mode as
well, if things were moved around a bit...
Regards,
Colin
|
|
From: Colin S. <col...@ex...> - 2004-04-30 12:16:52
|
The nasty thing is that while it is relatively easy to make
TransactionProxyFactoryBean non-singleton in the sense that it respects
its internal 'singleton' property and generates a new proxy on each
getObject() call if non-singleton, this is effectively useless since it
will be operating on the same target, and the container will only give
it the target once since all FactoryBeans are singletons unless the
container gives it a new target each time, which currently there is no
way to make happen since currently factorybean objects themselves have
to be singleton in terms of the container and are only populated once.
For this to work, the factorybean has to be a prototype, and the target
has to be a prototype.
While wrapping stateful objects like this is not as common as wrapping
stateless objects, it's something we should be able to support.
Can anybody see a simple way to do this, before we start mucking around
with basic container behaviour (i.e. forced singleton status of
factorybeans).?
Regards,
Colin
Colin Sampaleanu wrote:
> I just realized that TransactionProxyFactoryBean always returns true
> for ProxyFactoryBean's the isSingleton() method, and internally does
> not support non-singleton operation, since it only sets up the proxy
> once in afterPropertiesSet().
>
> I have a case where a client of the beanfactory is using
> bf.getBean("xxx"), and needs to get back a new transactionally wrapped
> instance on every call, sine the object is stateful, unlike every
> other service I've wrapped transactionally so far.
>
> Does anybody know why the class was set up to operate in singleton
> mode only? It makes sense as a default of course, but I can't see
> anything in the code precluding allowing it to operate in
> non-singleton mode as well, if things were moved around a bit...
|
|
From: Rod J. <rod...@in...> - 2004-05-05 23:45:57
|
ProxyFactoryBean supports stateful proxies. This is covered in the test
suite. As this is a minority usage I think it's reasonable that in the
interests of simplicity TransactionProxyFactoryBean, as a convenience,
focuses on the 98% usage.
----- Original Message -----
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Friday, April 30, 2004 1:20 PM
Subject: Re: [Springframework-developer] Why is TransactionProxyFactoryBean
forced to be singleton
> The nasty thing is that while it is relatively easy to make
> TransactionProxyFactoryBean non-singleton in the sense that it respects
> its internal 'singleton' property and generates a new proxy on each
> getObject() call if non-singleton, this is effectively useless since it
> will be operating on the same target, and the container will only give
> it the target once since all FactoryBeans are singletons unless the
> container gives it a new target each time, which currently there is no
> way to make happen since currently factorybean objects themselves have
> to be singleton in terms of the container and are only populated once.
> For this to work, the factorybean has to be a prototype, and the target
> has to be a prototype.
>
> While wrapping stateful objects like this is not as common as wrapping
> stateless objects, it's something we should be able to support.
>
> Can anybody see a simple way to do this, before we start mucking around
> with basic container behaviour (i.e. forced singleton status of
> factorybeans).?
>
> Regards,
> Colin
>
>
> Colin Sampaleanu wrote:
>
> > I just realized that TransactionProxyFactoryBean always returns true
> > for ProxyFactoryBean's the isSingleton() method, and internally does
> > not support non-singleton operation, since it only sets up the proxy
> > once in afterPropertiesSet().
> >
> > I have a case where a client of the beanfactory is using
> > bf.getBean("xxx"), and needs to get back a new transactionally wrapped
> > instance on every call, sine the object is stateful, unlike every
> > other service I've wrapped transactionally so far.
> >
> > Does anybody know why the class was set up to operate in singleton
> > mode only? It makes sense as a default of course, but I can't see
> > anything in the code precluding allowing it to operate in
> > non-singleton mode as well, if things were moved around a bit...
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Colin S. <col...@ex...> - 2004-05-11 13:06:05
|
Rod, At the TSS Symposium you mentioned having done some code to allow the appcontext to dynamically modify a class so that a create or getter method within it could actualy be hooked up to a prototype bean within the factory. What are your thoughts on adding this code in at this time? It would actually be of use to me... Colin |
