springframework-developer — Spring Framework developers list

Re: [Springframework-developer] BeanFactory support for add(Foo) wiring?

[Chistophe V. <c.v...@pa...>]

On Friday 30 April 2004 16:53, j=FCrgen h=F6ller [werk3AT] wrote:
> Request for feedback :-)
>
> http://sourceforge.net/forum/forum.php?thread_id=3D1066336&forum_id=3D250=
339
>
> Juergen

I could use something like this.
I also have beans that have to register themselves with another bean. Using=
 an=20
addXXX(XXX) method could be very handy for this.

No idea what the best syntax for this should be though.

=2D-=20
Kind regards,
Christophe Vanfleteren

Re: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[<jue...@we...>]

If you use a PrototypeTargetSource with TransactionProxyFactoryBean, =
you'll get a new prototype *per method invocation* on the proxy. I =
assume what you actually want is a prototype proxy with a single =
prototype target, with all invocations on the proxy going to the same =
target object.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Friday, April 30, 2004 5:03 PM
To: spr...@li...
Subject: Re: Rr: [Springframework-developer] Why is
TransactionProxyFactoryBean forced to be singleton


Actually, it looks like all that would be needed to do is set a=20
prototype target source creator of some sort into the=20
CustomTargetSourceCreators list. Now there is no non-abstract prototype=20
target source creator that people can use, and even if there was, it's=20
somewhat of a pain for people to create one just for this purpose. Does=20
it make sense to have BeanNameAutoProxy creator by default register a=20
prototype custom target source creator? (it could still be overriden of=20
course). If you think about it, the current default BeanNameAutoProxy=20
creator default behaviour is wrong anyways in the face of wrapping=20
prototype beans, since it will generate a singleton proxy around just=20
one instance from the prototype bean that is being wrapped, instead of=20
ensuring a prototype is returned each time.

Regards,
Colin

Colin Sampaleanu wrote:

> I'm not 100% sure I agree. At a minimum, we need to document this as=20
> an alternative to TransactionProxyFactoryBean, since I think a lot of=20
> people just using examples won't realize they can do it. But even=20
> then, it's a fair bit more verbose than TransactionProxyFactoryBean,=20
> which is also a lot more verbose than using BeanNameAutoProxyCreator=20
> on a bunch of beans with the same basic handling.
>
> One addition which would cover some cases is enhancing=20
> BeanNameAutoProxyCreator, or creating some variant of it, so that it=20
> can work in a prototype fashion. So when working in prototype mode,=20
> what it produces and stuffs back in the context is a prototype=20
> (isSingleton=3Dfalse) ProxyFactoryBean instance, effectively the same =
as=20
> if the user had used the basic ProxyFactoryBean to do transactional=20
> interception, in non-singleton fashion.
>
> What do you think?
>
> Regards,
> Colin
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>> Wrapping prototypes with transactional proxies should work nicely=20
>> when using ProxyFactoryBean plus TransactionInterceptor. The target=20
>> there is just a bean name, not a bean reference - so this will work=20
>> with a prototype, despite the FactoryBean being a singleton.
>>
>> TransactionProxyFactoryBean is essentially a convenience class that's =

>> really meant to be used for the typical case of singleton targets,=20
>> referring to them via a bean reference. I'd prefer to leave it that=20
>> way, recommending ProxyFactoryBean plus TransactionInterceptor for=20
>> prototypes.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On =
Behalf
>> Of Colin Sampaleanu
>> Sent: Friday, April 30, 2004 2:20 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Why is
>> TransactionProxyFactoryBean forced to be singleton
>>
>>
>> The nasty thing is that while it is relatively easy to make=20
>> TransactionProxyFactoryBean non-singleton in the sense that it=20
>> respects its internal 'singleton' property and generates a new proxy=20
>> on each getObject() call if non-singleton, this is effectively=20
>> useless since it will be operating on the same target, and the=20
>> container will only give it the target once since all FactoryBeans=20
>> are singletons unless the container gives it a new target each time,=20
>> which currently there is no way to make happen since currently=20
>> factorybean objects themselves have to be singleton in terms of the=20
>> container and are only populated once. For this to work, the=20
>> 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=20
>> 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=20
>> around with basic container behaviour (i.e. forced singleton status=20
>> of factorybeans).?
>>
>> Regards,
>> Colin
>>
>>
>> Colin Sampaleanu wrote:
>>
>> =20
>>
>>> 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=20
>>> bf.getBean("xxx"), and needs to get back a new transactionally=20
>>> wrapped instance on every call, sine the object is stateful, unlike=20
>>> every other service I've wrapped transactionally so far.
>>>
>>> Does anybody know why the class was set up to operate in singleton=20
>>> mode only? It makes sense as a default of course, but I can't see=20
>>> anything in the code precluding allowing it to operate in=20
>>> non-singleton mode as well, if things were moved around a bit...
>>>   =20
>>



-------------------------------------------------------
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.=20
http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: Rr: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[Colin S. <col...@ex...>]

Actually, it looks like all that would be needed to do is set a=20
prototype target source creator of some sort into the=20
CustomTargetSourceCreators list. Now there is no non-abstract prototype=20
target source creator that people can use, and even if there was, it's=20
somewhat of a pain for people to create one just for this purpose. Does=20
it make sense to have BeanNameAutoProxy creator by default register a=20
prototype custom target source creator? (it could still be overriden of=20
course). If you think about it, the current default BeanNameAutoProxy=20
creator default behaviour is wrong anyways in the face of wrapping=20
prototype beans, since it will generate a singleton proxy around just=20
one instance from the prototype bean that is being wrapped, instead of=20
ensuring a prototype is returned each time.

Regards,
Colin

Colin Sampaleanu wrote:

> I'm not 100% sure I agree. At a minimum, we need to document this as=20
> an alternative to TransactionProxyFactoryBean, since I think a lot of=20
> people just using examples won't realize they can do it. But even=20
> then, it's a fair bit more verbose than TransactionProxyFactoryBean,=20
> which is also a lot more verbose than using BeanNameAutoProxyCreator=20
> on a bunch of beans with the same basic handling.
>
> One addition which would cover some cases is enhancing=20
> BeanNameAutoProxyCreator, or creating some variant of it, so that it=20
> can work in a prototype fashion. So when working in prototype mode,=20
> what it produces and stuffs back in the context is a prototype=20
> (isSingleton=3Dfalse) ProxyFactoryBean instance, effectively the same a=
s=20
> if the user had used the basic ProxyFactoryBean to do transactional=20
> interception, in non-singleton fashion.
>
> What do you think?
>
> Regards,
> Colin
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>> Wrapping prototypes with transactional proxies should work nicely=20
>> when using ProxyFactoryBean plus TransactionInterceptor. The target=20
>> there is just a bean name, not a bean reference - so this will work=20
>> with a prototype, despite the FactoryBean being a singleton.
>>
>> TransactionProxyFactoryBean is essentially a convenience class that's=20
>> really meant to be used for the typical case of singleton targets,=20
>> referring to them via a bean reference. I'd prefer to leave it that=20
>> way, recommending ProxyFactoryBean plus TransactionInterceptor for=20
>> prototypes.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behal=
f
>> Of Colin Sampaleanu
>> Sent: Friday, April 30, 2004 2:20 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Why is
>> TransactionProxyFactoryBean forced to be singleton
>>
>>
>> The nasty thing is that while it is relatively easy to make=20
>> TransactionProxyFactoryBean non-singleton in the sense that it=20
>> respects its internal 'singleton' property and generates a new proxy=20
>> on each getObject() call if non-singleton, this is effectively=20
>> useless since it will be operating on the same target, and the=20
>> container will only give it the target once since all FactoryBeans=20
>> are singletons unless the container gives it a new target each time,=20
>> which currently there is no way to make happen since currently=20
>> factorybean objects themselves have to be singleton in terms of the=20
>> container and are only populated once. For this to work, the=20
>> factorybean has to be a prototype, and the target has to be a prototyp=
e.
>>
>> While wrapping stateful objects like this is not as common as=20
>> wrapping stateless objects, it's something we should be able to suppor=
t.
>>
>> Can anybody see a simple way to do this, before we start mucking=20
>> around with basic container behaviour (i.e. forced singleton status=20
>> of factorybeans).?
>>
>> Regards,
>> Colin
>>
>>
>> Colin Sampaleanu wrote:
>>
>> =20
>>
>>> I just realized that TransactionProxyFactoryBean always returns true=20
>>> for ProxyFactoryBean's the isSingleton() method, and internally does=20
>>> not support non-singleton operation, since it only sets up the proxy=20
>>> once in afterPropertiesSet().
>>>
>>> I have a case where a client of the beanfactory is using=20
>>> bf.getBean("xxx"), and needs to get back a new transactionally=20
>>> wrapped instance on every call, sine the object is stateful, unlike=20
>>> every other service I've wrapped transactionally so far.
>>>
>>> Does anybody know why the class was set up to operate in singleton=20
>>> mode only? It makes sense as a default of course, but I can't see=20
>>> anything in the code precluding allowing it to operate in=20
>>> non-singleton mode as well, if things were moved around a bit...
>>>   =20
>>

[Springframework-developer] BeanFactory support for add(Foo) wiring?

[<jue...@we...>]

Request for feedback :-)

http://sourceforge.net/forum/forum.php?thread_id=3D1066336&forum_id=3D250=
339

Juergen


DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

Re: Rr: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[Colin S. <col...@ex...>]

I'm not 100% sure I agree. At a minimum, we need to document this as an=20
alternative to TransactionProxyFactoryBean, since I think a lot of=20
people just using examples won't realize they can do it. But even then,=20
it's a fair bit more verbose than TransactionProxyFactoryBean, which is=20
also a lot more verbose than using BeanNameAutoProxyCreator on a bunch=20
of beans with the same basic handling.

One addition which would cover some cases is enhancing=20
BeanNameAutoProxyCreator, or creating some variant of it, so that it can=20
work in a prototype fashion. So when working in prototype mode, what it=20
produces and stuffs back in the context is a prototype=20
(isSingleton=3Dfalse) ProxyFactoryBean instance, effectively the same as=20
if the user had used the basic ProxyFactoryBean to do transactional=20
interception, in non-singleton fashion.

What do you think?

Regards,
Colin

j=FCrgen h=F6ller [werk3AT] wrote:

>Wrapping prototypes with transactional proxies should work nicely when u=
sing ProxyFactoryBean plus TransactionInterceptor. The target there is ju=
st a bean name, not a bean reference - so this will work with a prototype=
, despite the FactoryBean being a singleton.
>
>TransactionProxyFactoryBean is essentially a convenience class that's re=
ally meant to be used for the typical case of singleton targets, referrin=
g to them via a bean reference. I'd prefer to leave it that way, recommen=
ding ProxyFactoryBean plus TransactionInterceptor for prototypes.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Friday, April 30, 2004 2:20 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Why is
>TransactionProxyFactoryBean forced to be singleton
>
>
>The nasty thing is that while it is relatively easy to make=20
>TransactionProxyFactoryBean non-singleton in the sense that it respects=20
>its internal 'singleton' property and generates a new proxy on each=20
>getObject() call if non-singleton, this is effectively useless since it=20
>will be operating on the same target, and the container will only give=20
>it the target once since all FactoryBeans are singletons unless the=20
>container gives it a new target each time, which currently there is no=20
>way to make happen since currently factorybean objects themselves have=20
>to be singleton in terms of the container and are only populated once.=20
>For this to work, the factorybean has to be a prototype, and the target=20
>has to be a prototype.
>
>While wrapping stateful objects like this is not as common as wrapping=20
>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=20
>with basic container behaviour (i.e. forced singleton status of=20
>factorybeans).?
>
>Regards,
>Colin
>
>
>Colin Sampaleanu wrote:
>
> =20
>
>>I just realized that TransactionProxyFactoryBean always returns true=20
>>for ProxyFactoryBean's the isSingleton() method, and internally does=20
>>not support non-singleton operation, since it only sets up the proxy=20
>>once in afterPropertiesSet().
>>
>>I have a case where a client of the beanfactory is using=20
>>bf.getBean("xxx"), and needs to get back a new transactionally wrapped=20
>>instance on every call, sine the object is stateful, unlike every=20
>>other service I've wrapped transactionally so far.
>>
>>Does anybody know why the class was set up to operate in singleton=20
>>mode only? It makes sense as a default of course, but I can't see=20
>>anything in the code precluding allowing it to operate in=20
>>non-singleton mode as well, if things were moved around a bit...
>>   =20
>>

Re: Rr: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[Dmitriy K. <dko...@ru...>]

I was writing to say the same thing, but Juergen's message came first ;-))

+1 for using ProxyFactoryBean + TxInterceptor for prototypes

Regards,
Dmitriy.


jürgen höller [werk3AT] wrote:

> Wrapping prototypes with transactional proxies should work nicely when using ProxyFactoryBean plus TransactionInterceptor. The target there is just a bean name, not a bean reference - so this will work with a prototype, despite the FactoryBean being a singleton.
> 
> TransactionProxyFactoryBean is essentially a convenience class that's really meant to be used for the typical case of singleton targets, referring to them via a bean reference. I'd prefer to leave it that way, recommending ProxyFactoryBean plus TransactionInterceptor for prototypes.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Friday, April 30, 2004 2:20 PM
> To: spr...@li...
> 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
> 
> 
> -------------------------------------------------------
> 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_id149&alloc_id66&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Rr: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[<jue...@we...>]

Wrapping prototypes with transactional proxies should work nicely when =
using ProxyFactoryBean plus TransactionInterceptor. The target there is =
just a bean name, not a bean reference - so this will work with a =
prototype, despite the FactoryBean being a singleton.

TransactionProxyFactoryBean is essentially a convenience class that's =
really meant to be used for the typical case of singleton targets, =
referring to them via a bean reference. I'd prefer to leave it that way, =
recommending ProxyFactoryBean plus TransactionInterceptor for =
prototypes.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Friday, April 30, 2004 2:20 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Why is
TransactionProxyFactoryBean forced to be singleton


The nasty thing is that while it is relatively easy to make=20
TransactionProxyFactoryBean non-singleton in the sense that it respects=20
its internal 'singleton' property and generates a new proxy on each=20
getObject() call if non-singleton, this is effectively useless since it=20
will be operating on the same target, and the container will only give=20
it the target once since all FactoryBeans are singletons unless the=20
container gives it a new target each time, which currently there is no=20
way to make happen since currently factorybean objects themselves have=20
to be singleton in terms of the container and are only populated once.=20
For this to work, the factorybean has to be a prototype, and the target=20
has to be a prototype.

While wrapping stateful objects like this is not as common as wrapping=20
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=20
with basic container behaviour (i.e. forced singleton status of=20
factorybeans).?

Regards,
Colin


Colin Sampaleanu wrote:

> I just realized that TransactionProxyFactoryBean always returns true=20
> for ProxyFactoryBean's the isSingleton() method, and internally does=20
> not support non-singleton operation, since it only sets up the proxy=20
> once in afterPropertiesSet().
>
> I have a case where a client of the beanfactory is using=20
> bf.getBean("xxx"), and needs to get back a new transactionally wrapped =

> instance on every call, sine the object is stateful, unlike every=20
> other service I've wrapped transactionally so far.
>
> Does anybody know why the class was set up to operate in singleton=20
> mode only? It makes sense as a default of course, but I can't see=20
> anything in the code precluding allowing it to operate in=20
> 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.=20
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Re: [Commons Validator] Error on Startup

[Dmitriy K. <dko...@ru...>]

I believe there is no guaranteed order in Servlet 2.3 spec, however this order is strictly enforced in 2.4 - listeners then servlets.

Regards,
Dmitriy.

> Aren't listeners
> supposed to load before servlets?  If not, I guess I'll have to use the
> Servlet.  I'm on Tomcat 5.0.19.
> 
> Thanks,

Re: [Springframework-developer] can't attach patch to JIRA?

[Dmitriy K. <dko...@ru...>]

I meant to say version 2.6... ;-)


Dmitriy Kopylenko wrote:

> I can't seem to find the "attachment" function either. Is this something 
> that in version 1.6 has been moved somewhere?
> 
> Seth Ladd wrote:
> 
>> Hello,
>>
>> I'm registered with JIRA, but can't attach a patch to an (very 
>> trivial) issue I just created.  Do I not have permissions (username: 
>> sethladd) or is JIRA misconfigured again?
>>
>> Thanks!
>> Seth
>>
>>
>>
>> -------------------------------------------------------
>> 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
> 
> 
> 
> 
> -------------------------------------------------------
> 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

Re: [Springframework-developer] can't attach patch to JIRA?

[Dmitriy K. <dko...@ru...>]

I can't seem to find the "attachment" function either. Is this something that in version 1.6 has been moved somewhere?

Seth Ladd wrote:

> Hello,
> 
> I'm registered with JIRA, but can't attach a patch to an (very trivial) 
> issue I just created.  Do I not have permissions (username: sethladd) or 
> is JIRA misconfigured again?
> 
> Thanks!
> Seth
> 
> 
> 
> -------------------------------------------------------
> 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

Re: [Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[Colin S. <col...@ex...>]

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

[Springframework-developer] [Commons Validator] Messages not resolved

[Matt R. <li...@ra...>]

I have two apps - one is based on Servlet 2.4 and one on 2.3.  From what
I can tell, all the configuration is the same for commons validator.
I'm certain that the JARs are the same on both projects.  Now I'm having
a really strange problem.  On the 2.4 project (done with an XSD in
web.xml), the messages resolve fine, so if lastName is required, I get
"Last Name is a required field."  If I try the same thing on the 2.3
project, I get "{0} is a required field."  Everything looks right for
JSTL and all my other messages are getting resolved - except for
messages from the validation engine.  I've pasted my relevant config
below.  I tried manipulating the 2.3/2.4 thing too - that didn't help.

Another difference b/w the 2 projects is one uses
org.springframework.web.servlet.view.JstlView and the 2nd (non-working)
one uses TilesJstlView.

I'm using the latest stuff from CVS.

Thanks,

Matt

    <bean id="userFormController"
class="org.appfuse.webapp.action.UserFormController">
        ...
        <property name="validator"><ref
bean="beanValidator"/></property>
        ...
    </bean>

    <!-- This file is really named ApplicationResources_en.properties to
JSTL will pick 
         it up as the default. I know it doesn't sound right, but it
works.  I tried 
         renaming w/o the extension, no dice. -->
    <bean id="messageSource" 
 
class="org.springframework.context.support.ResourceBundleMessageSource">
        <property
name="basename"><value>ApplicationResources</value></property>
    </bean>

    <bean id="validatorFactory"
class="org.springframework.validation.commons.DefaultValidatorFactory" 
        init-method="init">
		<property name="resources">
            <list>
                <value>WEB-INF/validation.xml</value>
                <value>WEB-INF/validator-rules.xml</value>
                <value>WEB-INF/validator-rules-custom.xml</value>
            </list>
		</property>
	</bean>

	<bean id="beanValidator"
class="org.springframework.validation.commons.BeanValidator">
		<property name="validatorFactory"><ref
local="validatorFactory"/></property>
	</bean>

RE: [Springframework-developer] Re: [Commons Validator] Error on Startup

[Matt R. <li...@ra...>]

I found that adding /WEB-INF/action-servlet.xml to my
contextConfigLocation <context-param> solved my issue.  Aren't listeners
supposed to load before servlets?  If not, I guess I'll have to use the
Servlet.  I'm on Tomcat 5.0.19.

Thanks,

Matt

> -----Original Message-----
> From: spr...@li... 
> [mailto:spr...@li...]
>  On Behalf Of Rob Moore
> Sent: Tuesday, April 27, 2004 2:09 PM
> To: spr...@li...
> Subject: [Springframework-developer] Re: [Commons Validator] 
> Error on Startup
> 
> 
> Hey, Matt,
> 
> I ran into something similar -- perhaps it is the issue you 
> are facing. 
> If you are running in a container that doesn't follow the Servlet 2.4 
> initialization order you will not be able to use the 
> ContextLoaderListener. Instead, you'll need to use the 
> ContextLoaderServlet and ensure that it loads before the 
> DispatcherServlet. When I came across this it was manifested 
> by a failed 
> dependency -- that is, the reference I expected to be 
> available wasn't 
> in the context so configuration failed.
> 
> HTH,
> 
> Rob
> 
> Matt Raible wrote:
> > I figured out what the issue is - but don't know how to fix 
> it.  If I 
> > put the validatorFactory into my "applicationContext.xml", then 
> > everything works as expected.  But if I put it into 
> > "action-servlet.xml", then it doesn't work. It would be nice if it 
> > were able to be in both places.  If it can't be, it should 
> probably be 
> > documented and explained.
> > 
> > Matt
> > 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at 
> ThinkGeek For a limited time only, get FREE Ground shipping 
> on all orders of $35 or more. Hurry up and shop folks, this 
> offer expires April 30th! 
> http://www.thinkgeek.com/freeshipping/?cpg=> 12297
> 
> _______________________________________________
> 
> Springframework-developer mailing list 
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] Testing Controllers and FormControllers

[<jue...@we...>]

IMO, there's a strong difference between the "mock" and the "test" tree: =
The latter is a rough test suite for the framework itself, while the =
former contains polished mock classes that are also useful for =
applications, thus get distributed as "spring-mock.jar". The mocks would =
even fit better in "src" than in "test" in that respect.
=20
Actually, the "mock" tree is more similar to the main "src" tree than =
the "test" tree in a number of respects: It's meant to be used by =
applications, shipped as jar , included in the javadoc, and requires =
higher coding standards than the framework test suite. I'm quite =
strongly against keeping that sort of classes in the "test" tree.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 30.04.2004 03:18
An: spr...@li...
Betreff: Re: [Springframework-developer] Testing Controllers and =
FormControllers



Luke Taylor wrote:

> Luke Taylor wrote:
>
>>
>> It looks like the target/mock-classes directory needs to be created
>> in build.xml to stop it falling over on a clean build.
>>
>
> It was just that the mockjar target had "build" as a dependency rather
> than "buildmock". I've changed it in CVS.
>
>> Not quite sure how I'm going to squeeze it into the Maven build =
yet...
>>
>
> I'm not sure I see the benefit of a separate "mock" tree in the main
> directory rather than just storing them as support classes in the test
> tree (since they're required by the test classes anyway). It would be
> easy enough to build the separate jar of the org.springframework.mock
> package from the compiled test classes.

Actually that's a pretty valid point...




-------------------------------------------------------
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=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] can't attach patch to JIRA?

[Seth L. <se...@eh...>]

Hello,

I'm registered with JIRA, but can't attach a patch to an (very trivial) 
issue I just created.  Do I not have permissions (username: sethladd) or 
is JIRA misconfigured again?

Thanks!
Seth

Re: [Springframework-developer] Testing Controllers and FormControllers

[Colin S. <col...@ex...>]

Luke Taylor wrote:

> Luke Taylor wrote:
>
>>
>> It looks like the target/mock-classes directory needs to be created 
>> in build.xml to stop it falling over on a clean build.
>>
>
> It was just that the mockjar target had "build" as a dependency rather 
> than "buildmock". I've changed it in CVS.
>
>> Not quite sure how I'm going to squeeze it into the Maven build yet...
>>
>
> I'm not sure I see the benefit of a separate "mock" tree in the main 
> directory rather than just storing them as support classes in the test 
> tree (since they're required by the test classes anyway). It would be 
> easy enough to build the separate jar of the org.springframework.mock 
> package from the compiled test classes.

Actually that's a pretty valid point...

Re: [Springframework-developer] Testing Controllers and FormControllers

[Luke T. <lu...@mo...>]

Luke Taylor wrote:
> 
> It looks like the target/mock-classes directory needs to be created in 
> build.xml to stop it falling over on a clean build.
> 

It was just that the mockjar target had "build" as a dependency rather 
than "buildmock". I've changed it in CVS.

> Not quite sure how I'm going to squeeze it into the Maven build yet...
> 

I'm not sure I see the benefit of a separate "mock" tree in the main 
directory rather than just storing them as support classes in the test 
tree (since they're required by the test classes anyway). It would be 
easy enough to build the separate jar of the org.springframework.mock 
package from the compiled test classes.

Luke.


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

Re: [Springframework-developer] Testing Controllers and FormControllers

[Luke T. <ne...@fr...>]

jürgen höller [werk3AT] wrote:
> BTW, I've already committed the factored-out "mock" tree, including adapted build scripts etc.
>  
> Juergen
>  

It looks like the target/mock-classes directory needs to be created in 
build.xml to stop it falling over on a clean build.

Not quite sure how I'm going to squeeze it into the Maven build yet...

Luke.

-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

[Springframework-developer] Why is TransactionProxyFactoryBean forced to be singleton

[Colin S. <col...@ex...>]

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

Re: [Springframework-developer] Q: Magic behind PropertyConfigurer

[Dmitriy K. <dko...@ru...>]

Alex,

to answer your first question - the "magic" behind PropertyConfigurer's Resource property conversion from String is done by org.springframework.core.io.ResourceEditor

Regards,
Dmitriy.


Alexi Polenur wrote:

> Hi all,
> 
> In Petclinic I see following in applicationContext.xml
> 
>    <bean id="propertyConfigurer" 
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
> 
>        <property 
> name="location"><value>/WEB-INF/jdbc.properties</value></property>
>    </bean>
> 
> The  location property in PropertyPlaceholderConfigurer is of type 
> Resource. The question is, how does Spring "knows" to take 
> /WEB-INF/jdbc.properties string and construct an instance wich 
> implements a Resource interface. How does it knows what implementation 
> of this interface to use?
> 
> The second part of my question is a "real question". What I would like 
> to do is to have PropertyConfigurer to setup different property set 
> based on context (system property).
> 
> The reason I need it is for moving code from one environment to another. 
> For example when I move my app. from development to production my DB is 
> changing so I would like my PropertyConfigurer to read different 
> property file based on some system property which identifies environment.
> 
> The way I am trying to do it is by creating a special subclass of a 
> Resource which uses a ResourceBundle instead of single property file. 
> Each locale in ResourceBundle represents an environment (dev, test, 
> prod). My context now looks like that:
> 
>     <bean id="resourceA" class="myresources.ContextualResource">
>    </bean>
>          <bean id="propertyConfigurer" 
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
> 
>        <property name="locations">
>                    <list>
>                        <ref local="resourceA"/>
>                    </list>
>                </property>
>    </bean>
> 
> Does it sound like a resonable approach? Has somebody done it before ? 
> Is it better way of doing this ?
> 
> Thanks, Alexi
> 
> 
> -------------------------------------------------------
> 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

[Springframework-developer] Q: Magic behind PropertyConfigurer

[Alexi P. <apo...@ya...>]

Hi all,

In Petclinic I see following in applicationContext.xml

    <bean id="propertyConfigurer" 
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property 
name="location"><value>/WEB-INF/jdbc.properties</value></property>
    </bean>

The  location property in PropertyPlaceholderConfigurer is of type 
Resource. The question is, how does Spring "knows" to take 
/WEB-INF/jdbc.properties string and construct an instance wich 
implements a Resource interface. How does it knows what implementation 
of this interface to use?

The second part of my question is a "real question". What I would like 
to do is to have PropertyConfigurer to setup different property set 
based on context (system property).

The reason I need it is for moving code from one environment to another. 
For example when I move my app. from development to production my DB is 
changing so I would like my PropertyConfigurer to read different 
property file based on some system property which identifies environment.

The way I am trying to do it is by creating a special subclass of a 
Resource which uses a ResourceBundle instead of single property file. 
Each locale in ResourceBundle represents an environment (dev, test, 
prod). My context now looks like that:

     <bean id="resourceA" class="myresources.ContextualResource">
    </bean>
       
    <bean id="propertyConfigurer" 
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
                    <list>
                        <ref local="resourceA"/>
                    </list>
                </property>
    </bean>

Does it sound like a resonable approach? Has somebody done it before ? 
Is it better way of doing this ?

Thanks, Alexi

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Dmitriy K. <dko...@ru...>]

Les,

I've checked in the code into the sandbox: org.springframework.web.portlet.* Please note that it is almost 97% replica of the web.servlet package (class by class) I don't 
know if this would present maintenance headaches, but at this point I don't have any ideas of doing it any other ways... May be someone will have a better idea, but we 
had to make the first step!!

Regards,
Dmitriy.


Les A. Hazlewood wrote:

> I think this is just great.  Any idea of when others can take a look at the
> code?
> 
> Thanks for heading the effort Bill :)
> 
> Regards,
> 
> Les
> 
> P.S.  Since code has been somewhat replicated in places, what does this mean for
> long term maintenance for the two packages (i.e. o.s.w.servlet.* and
> o.s.w.portlet.*)?  What kind of synchronization efforts would be required, if
> any?
> 
> Quoting "William G. Thompson, Jr." <wg...@ru...>:
> 
> 
>>Folks,
>>
>>Spring Portlet MVC layer is rendering JSTL Views with full
>>ApplicationContext support!!!
>>
>>I ended having to port just about the entire
>>org.springframework.web.servlet.* package.
>>
>>Should this go into the sandbox?  I suspect that it may still need some
>>refactoring...after we play with it a bit more.
>>
>>later.
>>Bill
>>--
>>William G. Thompson, Jr.
>>Associate Director of New Technologies
>>Administrative Computing Services, Rutgers University
>>voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru...
>>
>>
>>
>>-------------------------------------------------------
>>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
>>
> 
> 
> 
> -------------------------------------------------------
> 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

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[William G. T. Jr. <wg...@ru...>]

Les A. Hazlewood wrote:
> I think this is just great.  Any idea of when others can take a look at the
> code?

I am hoping we can get it into the sandbox soon.  I can also put up a 
jar at a URL you can snarf later today.

> 
> Thanks for heading the effort Bill :)

No problem...it was nice to dig into the internals of Spring...anyway we 
need this badly as we are about to start a major Portlet dev cycle for 
myRutgers.

> 
> Regards,
> 
> Les
> 
> P.S.  Since code has been somewhat replicated in places, what does this mean for
> long term maintenance for the two packages (i.e. o.s.w.servlet.* and
> o.s.w.portlet.*)?  What kind of synchronization efforts would be required, if
> any?

The MVC architecture is essentially the same and the Portlet API 
somewhat mirrors the Servlet API.  However there are enough differences 
that made it necessary to have the seperate package.

It is a testament to the Spring architecture that every time there was 
dependancy outside of o.s.w.servlet.* I could reuse that code without 
any modification.


> 
> Quoting "William G. Thompson, Jr." <wg...@ru...>:
> 
> 
>>Folks,
>>
>>Spring Portlet MVC layer is rendering JSTL Views with full
>>ApplicationContext support!!!
>>
>>I ended having to port just about the entire
>>org.springframework.web.servlet.* package.
>>
>>Should this go into the sandbox?  I suspect that it may still need some
>>refactoring...after we play with it a bit more.
>>
>>later.
>>Bill

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Dmitriy K. <dko...@ru...>]

I'll check it into the sandbox...

Juergen, Alef, everyone, could you take a look at it...?

Regards,
Dmitriy.


William G. Thompson, Jr. wrote:

> Folks,
> 
> Spring Portlet MVC layer is rendering JSTL Views with full 
> ApplicationContext support!!!
> 
> I ended having to port just about the entire 
> org.springframework.web.servlet.* package.
> 
> Should this go into the sandbox?  I suspect that it may still need some 
> refactoring...after we play with it a bit more.
> 
> later.
> Bill

Re: [Springframework-developer] Spring Portlet MVC layer is rendering JSTL Views!!!

[Les A. H. <le...@ha...>]

I think this is just great.  Any idea of when others can take a look at the
code?

Thanks for heading the effort Bill :)

Regards,

Les

P.S.  Since code has been somewhat replicated in places, what does this mean for
long term maintenance for the two packages (i.e. o.s.w.servlet.* and
o.s.w.portlet.*)?  What kind of synchronization efforts would be required, if
any?

Quoting "William G. Thompson, Jr." <wg...@ru...>:

> Folks,
>
> Spring Portlet MVC layer is rendering JSTL Views with full
> ApplicationContext support!!!
>
> I ended having to port just about the entire
> org.springframework.web.servlet.* package.
>
> Should this go into the sandbox?  I suspect that it may still need some
> refactoring...after we play with it a bit more.
>
> later.
> Bill
> --
> William G. Thompson, Jr.
> Associate Director of New Technologies
> Administrative Computing Services, Rutgers University
> voice: 732 445-5428 | fax: 732 445-5493 | wg...@ru...
>
>
>
> -------------------------------------------------------
> 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
>