springframework-developer — Spring Framework developers list

[Springframework-developer] 1.0 M3 prepared

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

Everybody,
=20
I've just prepared the release as far as possible: fixed all javadoc =
errors, added missing package javadocs, tested the samples. All tests =
for shipped components pass on my machine (when running via Ant).
=20
The TLD is now loaded from the spring.jar file, referenced via the =
default URI http://www.springframework.org/tags (analogous to Struts and =
JSTL). BaseCommandController uses setCommandName now, with setBeanName =
being deprecated.
=20
Whoever wants to give it a try, fetch the latest CVS contents, run the =
release target, and "play user" with spring-framework-1.0-m3.zip (it's =
in the target/release directrory): unzip it, browse through the docs, =
build the sample wars (call ant warfile or warfile.bat) and drop them =
into your container's webapps directory.
=20
Alef, could you give the tiles-example a final try? I'm not keen on =
including struts.jar in the Spring distribution, so the example should =
be prepared for deployment with a manually added struts.jar.
=20
A final note on a further naming issue: I'm not entirely happy with =
"ListableBeanFactoryImpl". For example, BeanWrapperImpl is *the* =
implementation of BeanWrapper, hardly any chance for alternative =
implementations - the interface is rather a simplified API for it. But =
ListableBeanFactoryImpl implements ConfigurableListableBeanFactory with =
registration methods for a specific properties format; this seems to be =
a different case to me.
=20
So wouldn't it be more appropriate to call it =
"DefaultListableBeanFactory"? That name change should not affect typical =
applications anyway but just "power users" who should be willing to =
migrate via a simple class name change. I quite strongly prefer this =
name to "ListableBeanFactoryImpl", actually. If we agree on the new =
name, let's better change it now instead of in the 1.0 RC phase.
=20
Juergen
=20

Re: [Springframework-developer] Re: [Springframework-user] setting bean properties from system properties

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

Rod Johnson wrote:

>>Of course, the variant to adding more and more mechanisms to access
>>other objects is to put in some (optional) support for an expresion
>>language inside the bean factory. I've been thinking about this for a
>>while now.
>>    
>>
>+1
>
>  
>
>>So assuming that there is a generic expression language plugin facility,
>>and which expression language to use is denoted by a prefix, a
>>hypothetical OGNL example for your case would be:
>>
>><bean id="myBean" class="org.me.myClass">
>>  <property
>>
>>    
>>
>name="myProp"><expr>ognl:@System@getProperties()['my.property.name']</expr><
>/property>
>  
>
>></bean>
>>
>>And if you expose the current factory into the OGNL context, then you
>>could have expressions such as:
>>
>><bean id="myBean" class="org.me.myClass">
>>  <property
>>
>>    
>>
>name="myProp"><expr>ognl:factory.getBean('another-bean-id').someProperty</ex
>pr></property>
>  
>
>></bean>
>>    
>>
>
>I think it's important that we don't sink under steady feature creep of
>supporting more and more single-scenario solutions. So a more general
>solution would be better.
>
>Another 1.1 feature, perhaps.
>
>  
>
There is of course a tradeoff here, where you want to cover the guy 
using a basic BeanFactory in an Applet or somewhere like that where 
every last byte counts, and get him a minimal set of functionality, but 
for the cases where size is not as much of an issue, there are more 
powerful/general solutions.

In this particular case (getting a system property), I think this will 
be able to be handled by the MethodCallFactoryBean I am writing right 
now, in a slightly more verbose fashion...

  <bean id="sysProps" 
class="org.springframework.beans.factory.config.MethodCallFactoryBean">
    <property 
name="staticMethod"><value>java.lang.System.getProperties</value></property>
  </bean>
  <bean id="mySystemProp" 
class="org.springframework.beans.factory.config.MethodCallFactoryBean">
    <property name="target"><ref local='sysProps'/></property>
    <property name="targetMethod"><value>getProperty</value></property>
    <property name="args">
      <list>
        <value>my.property.name</value>
      </list>
  </bean>

So this would cover people using a base beanfactory, while people 
willing to bring in a real expression processor, would have more concise 
mechanisms...

RE: [Springframework-developer] BaseCommandController: setBeanName -> setCommandName

[Trevor C. <pr...@se...>]

This affects us heavily, but makes total sense (my +1).  Once this is
committed I'll start migrating/testing our code.

Trevor


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: November 21, 2003 6:11 AM
To: spr...@li...
Subject: [Springframework-developer] BaseCommandController: setBeanName
-> setCommandName


Everybody,

In the old tradition of last minute changes before Spring releases ;-), I=
'd
like to finally change BaseCommandController's "setBeanName" method to
"setCommandName", as it has been bugging me for quite a while that
"setBeanName" is too generic and misleading. Now that we have a
BeanNameAware interface with the natural method name "setBeanName",
BaseCommandController's naming is even more confusing. "setCommandName"
would accompany the existing "setCommandClass" method nicely.

Of course, setBeanName is a *very* commonly called method in command/form
controller initialization. I consider this a reason to change it before 1=
.0
final, as we would have to stick with it else. I suggest to keep
"setBeanName" as deprecated method for the time being, but clearly recomm=
end
to switch to "setCommandName".

The same applies to our various notions of XML bean references. I'd like =
to
drop support for the deprecated <ref external=3D".../> as of 1.0 RC1, and
suggest to proceed similarly with BaseCommandController's setBeanName. If=
 we
communicate that clearly, we shouldn't cause any migration headaches.

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


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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.537 / Virus Database: 332 - Release Date: 06/11/2003

[Springframework-developer] Re: [Springframework-user] setting bean properties from system properties

[Rod J. <rod...@in...>]

> Of course, the variant to adding more and more mechanisms to access
> other objects is to put in some (optional) support for an expresion
> language inside the bean factory. I've been thinking about this for a
> while now.
+1

>
> So assuming that there is a generic expression language plugin facility,
> and which expression language to use is denoted by a prefix, a
> hypothetical OGNL example for your case would be:
>
> <bean id="myBean" class="org.me.myClass">
>   <property
>
name="myProp"><expr>ognl:@System@getProperties()['my.property.name']</expr><
/property>
> </bean>
>
> And if you expose the current factory into the OGNL context, then you
> could have expressions such as:
>
> <bean id="myBean" class="org.me.myClass">
>   <property
>
name="myProp"><expr>ognl:factory.getBean('another-bean-id').someProperty</ex
pr></property>
> </bean>

I think it's important that we don't sink under steady feature creep of
supporting more and more single-scenario solutions. So a more general
solution would be better.

Another 1.1 feature, perhaps.

Regards,
Rod

[Springframework-developer] Re: [Springframework-user] setting bean properties from system properties

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

(diverting to dev list, as this is more appropriate there)

This would be of some use.

Of course, the variant to adding more and more mechanisms to access 
other objects is to put in some (optional) support for an expresion 
language inside the bean factory. I've been thinking about this for a 
while now.

So assuming that there is a generic expression language plugin facility, 
and which expression language to use is denoted by a prefix, a 
hypothetical OGNL example for your case would be:

<bean id="myBean" class="org.me.myClass">
  <property 
name="myProp"><expr>ognl:@System@getProperties()['my.property.name']</expr></property>
</bean>

And if you expose the current factory into the OGNL context, then you 
could have expressions such as:

<bean id="myBean" class="org.me.myClass">
  <property 
name="myProp"><expr>ognl:factory.getBean('another-bean-id').someProperty</expr></property>
</bean>

and so on...



Eric Pederson wrote:

> It would be very handy to be able to set bean properties based on the 
> value of system properties.    That would allow system 
> administrators to set application properties without touching a .war 
> or .jar that has an applicationContext.xml or 
> PropertyResourceConfigurer property file inside of it.
>  
> For example, I would start up my JVM with a flag -Dmy.property.name=foo
>  
> The applicationContent.xml in the .war or .jar would have
>  
> <bean id="myBean" class="org.me.myClass">
> <property 
> name="myProp"><sysproperty>my.property.name</sysproperty></property>
> </bean>
>  
> This would set myBean.myProp to "foo".
>  
> Thoughts?
>  
>
>
> Eric Pederson
> eri...@ac... 

[Springframework-developer] AbstractFactoryBean implements PropertyValuesProviderFactoryBean, but comments say it doesn't

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

AbstractFactoryBean currently implements 
PropertyValuesProviderFactoryBean. However, comments within it say it 
doesn't. Anybody know how this discrepancy happened?

public abstract class AbstractFactoryBean implements 
PropertyValuesProviderFactoryBean {
  ...
    /**
     * Implementation of PropertyValuesProviderFactoryBean interface. 
Not declared on
     * this class, but subclass can choose to treat this interface as a 
tag interface.
     * Only used if the subclass implements 
PropertyValuesProviderFactoryBean (which
     * it can do without any additional code). This implementation will 
always return
     * the same properties for all objects, ignoring the bean name 
parameter.
     * @param name name of the bean we're creating
     * @see 
org.springframework.beans.factory.PropertyValuesProviderFactoryBean#getPropertyValues(String)
     */
    public PropertyValues getPropertyValues(String name) {
        return this.pvs;
    }

RE: [Springframework-developer] Intercepting a Prototype Bean

[MacMahon, M. <M.M...@em...>]

Hi Rod, all,

Thanks very much for the prompt and detailed replies.

I have tried to apply your suggested solution to my problem but am still
encountering the same issues
I.E the same TestTarget instance is being re-used for each invocation!

Have I misunderstood?

I have defined the following in applicationContext.xml


<!-- TestTarget implements the ITestTarget interface - one method foo() -->
<bean id="TestTarget" class="test.TestTarget" singleton="false">    
</bean>	

<!-- Transaction Interceptor Chain-->

<!-- Specified as a prototype (for mixin behaviour) -->
<bean id="MixinTransactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor"
singleton="false">
	<property name="transactionManager"><ref
local="transactionManager"/></property>	
	<property name="transactionAttributeSource">
        <value>test.ITestTarget.foo=PROPAGATION_REQUIRED</value>
    </property>
</bean>


<!--Applies MixinTransactionInterceptor to TestTarget -->
<bean id="TestInterceptor"
class="org.springframework.aop.framework.ProxyFactoryBean" singleton="true">
	 <property
name="interceptorNames"><value>MixinTransactionInterceptor,TestTarget</value
></property>
	 <property name="singleton"><value>false</value></property>
</bean>



My test is as simple as it can get ;-)

public class TestTarget implements ITestTarget
{	
 private int invocationCount = 0;
    
 public void foo()
 {
 	System.err.println
	(
		"<<TestTarget:foo>> "+toString()+" Invocation Count is
"+(++invocationCount)
	);
 }
}

ITestTarget testInterceptor1 =
(ITestTarget)context.getBean("TestInterceptor");
ITestTarget testInterceptor2 =
(ITestTarget)context.getBean("TestInterceptor");			
testInterceptor1.foo();
testInterceptor2.foo();

Output is 

[java] <<TestTarget:foo>> test.TestTarget@e183e9 Invocation Count is 1
[java] <<TestTarget:foo>> test.TestTarget@e183e9 Invocation Count is 2



On a related note, I think it would be _nice_ to be able to define the
transaction behaviour in the same manner 
adopted by TransactionProxyFactoryBean.

Also, is it possible to apply my MixinTransactionInterceptor to multiple
target classes

	<property name="transactionAttributeSource">
        <value>
		test.ITestTarget.foo=PROPAGATION_REQUIRED		
		test.IOtherObject.bar=PROPAGATION_REQUIRED	  
		</value>
    </property>



Thanks again,

Mark

-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: 20 November 2003 17:29
To: spr...@li...
Subject: Re: [Springframework-developer] Intercepting a Prototype Bean


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/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] BaseCommandController: setBeanName -> setCommandName

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

+1, although this doesn't affect me at all...


jürgen höller [werk3AT] wrote:

>Everybody,
>
>In the old tradition of last minute changes before Spring releases ;-), I'd like to finally change BaseCommandController's "setBeanName" method to "setCommandName", as it has been bugging me for quite a while that "setBeanName" is too generic and misleading. Now that we have a BeanNameAware interface with the natural method name "setBeanName", BaseCommandController's naming is even more confusing. "setCommandName" would accompany the existing "setCommandClass" method nicely.
>
>Of course, setBeanName is a *very* commonly called method in command/form controller initialization. I consider this a reason to change it before 1.0 final, as we would have to stick with it else. I suggest to keep "setBeanName" as deprecated method for the time being, but clearly recommend to switch to "setCommandName".
>
>The same applies to our various notions of XML bean references. I'd like to drop support for the deprecated <ref external=".../> as of 1.0 RC1, and suggest to proceed similarly with BaseCommandController's setBeanName. If we communicate that clearly, we shouldn't cause any migration headaches.
>
>Juergen
>  
>

Re: [Springframework-developer] In BeanFactory, ref to another bean's properties, not to the other bean directly

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

Actually I had the same thought with using a FactoryBean approach, while 
in the shower this morning. It's obviously simpler than modifying the 
bean definition and dtd (the class would probably take all of 20 lines). 
Can anybody think of a reason why it'd be preferable to have a top level 
element (ie 'static-factory') as per my initial proposal? If not, I'll 
do an implementation based on FactoryBean and check it in, since I need 
it anyways...

Now I'm still curious if anybody has an answer to my first question, 
i.e., how are people getting around the need to get at a ref bean's 
properties to set as a property of a bean being defined, as opposed to 
setting that ref bean as a property itself.


Rod Johnson wrote:

>I really like this idea. No Spring dependency.
>
>I would pull the factory method and class into different XML elements.
>
>Or possibly use a generic factory bean that took the static factory class
>and method and optionally args and meant that there was no need for new XML
>or changes to existing code. In fact it would be trivial to implement right
>now.
>
><bean id="whatever" class="GenericWhateverFactoryBean" >
>    <property name="staticFactory"><value>a.b.c.....
>    <property name="staticMethod"><value>myFactory
>
>It could even work out the type.
>
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Friday, November 21, 2003 3:01 AM
>Subject: Re: [Springframework-developer] In BeanFactory, ref to another
>bean's properties, not to the other bean directly
>
>
>  
>
>>How about this for constructing beans via a static factory method
>>
>><bean id="whatever">
>>  <static-factory method="a.b.c.d.MyClass.myFactory"/>
>></bean>
>>
>>which would cover static methods with no args. A second step would be:
>>
>><bean id="whatever">
>>  <static-factory method="a.b.c.d.MyClass.myFactory">
>>    <arg>  ... </arg>
>>    <arg>  ... </arg>
>>  </static-factory>
>></bean>
>>
>>where arg is basically the same thing as constructor-arg in the current
>>dtd...
>>
>>
>>Colin Sampaleanu wrote:
>>
>>    
>>
>>>I keep on running into the case where in defining a bean in a bean
>>>factory or context, I need to set a property to the value of a
>>>property from another bean, not the bean itself. How are people
>>>typically handling this limitation?
>>>
>>>For that matter, it would be very useful to be able to get a bean into
>>>the container via an expression. I am for example using the CCPP
>>>processing API from Sun. All the classes use a factory to get a bean
>>>instance. So if I need a ProfileFactory, I get one with this code,
>>>calling a static method:
>>> ProfileFactory pf  = ProfileFactoryImpl.getInstance();
>>>I have some beans in a context which need this passed in. I would
>>>handle this right now by defining a new class which is a FactoryBean,
>>>and returns the result of the above, but that's kludgy. Now handling
>>>any kind of generic code of this sort needs an expression evaluator,
>>>but I think this particular idiom (a static method call on a class)
>>>could probably be handled in a simpler fashion, built-in?
>>>
>>>What do you guys think?
>>>      
>>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>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/
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] BaseCommandController: setBeanName -> setCommandName

[Rod J. <rod...@in...>]

I think we're close to our ultimate feature set for 1.0. I think the focus
has to be on stability and quality of documentation from now.

I don't think metadata attribute support is going to make 1.0, for example.

I think we should aim for a relatively quick *backward compatible* 1.1
release a couple of months after 1.0. This might include:

- attributes
- "inner beans" as discussed in this list
- a classpath-slurping automatic application context creator as an
additional option

I like Colin's generic factory suggestion. So long as it is implemented
without major impact on existing code I would definitely like to see this in
1.0.

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, November 21, 2003 11:36 AM
Subject: RE: [Springframework-developer] BaseCommandController:
setBeanName -> setCommandName


Darren,

RC1 is planned for early December, and should indeed represent a feature
freeze. The goal is to release a proper 1.0 final in early January, allowing
for one month of intense testing, and for polishing of documentation. If we
don't encounter any obstacles, we will *not* release a further milestone M4
before RC1.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Friday, November 21, 2003 12:30 PM
To: spr...@li...
Subject: Re: [Springframework-developer] BaseCommandController:
setBeanName -> setCommandName



> Of course, setBeanName is a *very* commonly called method in
> command/form controller initialization. I consider this a reason to
> change it before 1.0 final, as we would have to stick with it else.

+1 : setCommandName is much clearer.

> The same applies to our various notions of XML bean references. I'd
> like to drop support for the deprecated <ref external=".../> as of
> 1.0 RC1, and suggest to proceed similarly with
> BaseCommandController's setBeanName. If we communicate that clearly,
> we shouldn't cause any migration headaches.

What's the plan for RC1 - is it feature and API freeze once RC1 is released
with only bugs being considered afterwards?  Just wondering if anything
concrete was behind the changed naming strategy.


--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp


-------------------------------------------------------
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/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] BaseCommandController: setBeanName -> setCommandName

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

Darren,

RC1 is planned for early December, and should indeed represent a feature =
freeze. The goal is to release a proper 1.0 final in early January, =
allowing for one month of intense testing, and for polishing of =
documentation. If we don't encounter any obstacles, we will *not* =
release a further milestone M4 before RC1.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Friday, November 21, 2003 12:30 PM
To: spr...@li...
Subject: Re: [Springframework-developer] BaseCommandController:
setBeanName -> setCommandName



> Of course, setBeanName is a *very* commonly called method in=20
> command/form controller initialization. I consider this a reason to=20
> change it before 1.0 final, as we would have to stick with it else.=20

+1 : setCommandName is much clearer.

> The same applies to our various notions of XML bean references. I'd=20
> like to drop support for the deprecated <ref external=3D".../> as of=20
> 1.0 RC1, and suggest to proceed similarly with=20
> BaseCommandController's setBeanName. If we communicate that clearly,=20
> we shouldn't cause any migration headaches.

What's the plan for RC1 - is it feature and API freeze once RC1 is =
released
with only bugs being considered afterwards?  Just wondering if anything
concrete was behind the changed naming strategy.


--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp


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

Re: [Springframework-developer] BaseCommandController: setBeanName -> setCommandName

[Darren D. <dda...@kg...>]

> Of course, setBeanName is a *very* commonly called method in 
> command/form controller initialization. I consider this a reason to 
> change it before 1.0 final, as we would have to stick with it else. 

+1 : setCommandName is much clearer.

> The same applies to our various notions of XML bean references. I'd 
> like to drop support for the deprecated <ref external=".../> as of 
> 1.0 RC1, and suggest to proceed similarly with 
> BaseCommandController's setBeanName. If we communicate that clearly, 
> we shouldn't cause any migration headaches.

What's the plan for RC1 - is it feature and API freeze once RC1 is released
with only bugs being considered afterwards?  Just wondering if anything
concrete was behind the changed naming strategy.


--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] BaseCommandController: setBeanName -> setCommandName

[Rod J. <rod...@in...>]

Fine.
----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, November 21, 2003 11:11 AM
Subject: [Springframework-developer] BaseCommandController: setBeanName ->
setCommandName


Everybody,

In the old tradition of last minute changes before Spring releases ;-), I'd
like to finally change BaseCommandController's "setBeanName" method to
"setCommandName", as it has been bugging me for quite a while that
"setBeanName" is too generic and misleading. Now that we have a
BeanNameAware interface with the natural method name "setBeanName",
BaseCommandController's naming is even more confusing. "setCommandName"
would accompany the existing "setCommandClass" method nicely.

Of course, setBeanName is a *very* commonly called method in command/form
controller initialization. I consider this a reason to change it before 1.0
final, as we would have to stick with it else. I suggest to keep
"setBeanName" as deprecated method for the time being, but clearly recommend
to switch to "setCommandName".

The same applies to our various notions of XML bean references. I'd like to
drop support for the deprecated <ref external=".../> as of 1.0 RC1, and
suggest to proceed similarly with BaseCommandController's setBeanName. If we
communicate that clearly, we shouldn't cause any migration headaches.

Juergen


DI Jürgen Höller
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


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

[Springframework-developer] BaseCommandController: setBeanName -> setCommandName

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

Everybody,

In the old tradition of last minute changes before Spring releases ;-), =
I'd like to finally change BaseCommandController's "setBeanName" method =
to "setCommandName", as it has been bugging me for quite a while that =
"setBeanName" is too generic and misleading. Now that we have a =
BeanNameAware interface with the natural method name "setBeanName", =
BaseCommandController's naming is even more confusing. "setCommandName" =
would accompany the existing "setCommandClass" method nicely.

Of course, setBeanName is a *very* commonly called method in =
command/form controller initialization. I consider this a reason to =
change it before 1.0 final, as we would have to stick with it else. I =
suggest to keep "setBeanName" as deprecated method for the time being, =
but clearly recommend to switch to "setCommandName".

The same applies to our various notions of XML bean references. I'd like =
to drop support for the deprecated <ref external=3D".../> as of 1.0 RC1, =
and suggest to proceed similarly with BaseCommandController's =
setBeanName. If we communicate that clearly, we shouldn't cause any =
migration headaches.

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

[Springframework-developer] Re: About MVC

[Darren D. <dda...@kg...>]

Resurrecting this from a few days back, and to recap; 

Views often need access to 'secondary level' model data to decorate the data
returned by the controller, which is highly specific to the user gesture that
triggered that controller.  ie, a form post triggers a search controller to
obtain and return a list of results based on the user's input criteria, but
the view wants to wrap those results with a navigation menu and some latest
news - all of which are dependent on different business data or logic, and
none of which have anything to do with the search controller.  This is not a
portal, where the semantics are very different.  Tiles solves it, but Tiles is
view-technology specific.  View decoration is specific to a view and should be
configurable at the view definition level.  Although in practice, many views
may use the same 'decoration', this is solved already with parent view
definitions.

I took a look at Juergen's additions to  the view classes that enable a Map of
context objects to be added in the same way as static attributes.  This helps
go some way towards solving what I see the problem is, but it's not the whole
answer.

If the context object is itself not the secondary model data you wish to make
available to the view, but rather is a business object capable of retreiving
or generating that data, then something further needs to happen.  While
Velocity and JSP may be able to call a method on the object it's possibly not
desirable for them to do so, and other view technologies can't.  The options
would be to make the object some sort of FactoryBean (? not sure about this)
or implement another specific interface that the View can use to pull data
from the object.  Initially I mooted the other interface method but in fact
neither of these may be desirable or even possible if it's an existing
business component doing the work.

Specifying the method name to call for each object in the Map is another
option, but I guess this would break the current beans DTD for an
XmlViewResolver and would be difficult to parameterise.  Even so, this would
be closest to a view-technology agnostic (but view specific) solution I think.
 Anyone else?

--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] In BeanFactory, ref to another bean's properties, not to the other bean directly

[Rod J. <rod...@in...>]

I really like this idea. No Spring dependency.

I would pull the factory method and class into different XML elements.

Or possibly use a generic factory bean that took the static factory class
and method and optionally args and meant that there was no need for new XML
or changes to existing code. In fact it would be trivial to implement right
now.

<bean id="whatever" class="GenericWhateverFactoryBean" >
    <property name="staticFactory"><value>a.b.c.....
    <property name="staticMethod"><value>myFactory

It could even work out the type.

Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Friday, November 21, 2003 3:01 AM
Subject: Re: [Springframework-developer] In BeanFactory, ref to another
bean's properties, not to the other bean directly


> How about this for constructing beans via a static factory method
>
> <bean id="whatever">
>   <static-factory method="a.b.c.d.MyClass.myFactory"/>
> </bean>
>
> which would cover static methods with no args. A second step would be:
>
> <bean id="whatever">
>   <static-factory method="a.b.c.d.MyClass.myFactory">
>     <arg>  ... </arg>
>     <arg>  ... </arg>
>   </static-factory>
> </bean>
>
> where arg is basically the same thing as constructor-arg in the current
> dtd...
>
>
> Colin Sampaleanu wrote:
>
> > I keep on running into the case where in defining a bean in a bean
> > factory or context, I need to set a property to the value of a
> > property from another bean, not the bean itself. How are people
> > typically handling this limitation?
> >
> > For that matter, it would be very useful to be able to get a bean into
> > the container via an expression. I am for example using the CCPP
> > processing API from Sun. All the classes use a factory to get a bean
> > instance. So if I need a ProfileFactory, I get one with this code,
> > calling a static method:
> >  ProfileFactory pf  = ProfileFactoryImpl.getInstance();
> > I have some beans in a context which need this passed in. I would
> > handle this right now by defining a new class which is a FactoryBean,
> > and returns the result of the above, but that's kludgy. Now handling
> > any kind of generic code of this sort needs an expression evaluator,
> > but I think this particular idiom (a static method call on a class)
> > could probably be handled in a simpler fashion, built-in?
> >
> > What do you guys think?
>
>
>
>
>
>
> -------------------------------------------------------
> 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
>

Re: [Springframework-developer] In BeanFactory, ref to another bean's properties, not to the other bean directly

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

How about this for constructing beans via a static factory method

<bean id="whatever">
  <static-factory method="a.b.c.d.MyClass.myFactory"/>
</bean>

which would cover static methods with no args. A second step would be:

<bean id="whatever">
  <static-factory method="a.b.c.d.MyClass.myFactory">
    <arg>  ... </arg>
    <arg>  ... </arg>
  </static-factory>
</bean>

where arg is basically the same thing as constructor-arg in the current 
dtd...


Colin Sampaleanu wrote:

> I keep on running into the case where in defining a bean in a bean 
> factory or context, I need to set a property to the value of a 
> property from another bean, not the bean itself. How are people 
> typically handling this limitation?
>
> For that matter, it would be very useful to be able to get a bean into 
> the container via an expression. I am for example using the CCPP 
> processing API from Sun. All the classes use a factory to get a bean 
> instance. So if I need a ProfileFactory, I get one with this code, 
> calling a static method:
>  ProfileFactory pf  = ProfileFactoryImpl.getInstance();
> I have some beans in a context which need this passed in. I would 
> handle this right now by defining a new class which is a FactoryBean, 
> and returns the result of the above, but that's kludgy. Now handling 
> any kind of generic code of this sort needs an expression evaluator, 
> but I think this particular idiom (a static method call on a class) 
> could probably be handled in a simpler fashion, built-in?
>
> What do you guys think?

Re: [Springframework-developer] Re: Creating Application Context getBean 'closures'

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

I was thinking of the first, with the idea that there is no Spring class 
dependency, and you achieve total inversion of control.

Your second option would work of course. It does achieve the IOC aspect, 
but doesn't remove the Spring  (if the GenericFactory interface comes 
from Spring), and you would have to cast in the using bean instead of in 
the proxy. The IOC and hiding of other beans in the BF are probably the 
most important things anyway.

(Of course, both of these do have a negative aspect, compared to just 
using BeanFactory directly; with BeanFActory the using bean can declare 
itself BeanFactoryAware and get the reference with no extra configuration).


roger holbrook wrote:

>Hi Colin
>
>Your thoughts on implementation hiding have got me thinking...
>
>But before I test anything could you clarify the sort of usage you
>have in mind - specifically, would it make a difference whether the
>implementation hiding factories were themselves 'typed' or 'generic' ie. do
>you want / need the type of the factory to vary with the type that it
>generates, or would a single generic factory be adequate ?
>
>In other words, does one or other of the following make a difference ?
>
>1.  Typed interface factories:
>
>interface MyFirstInterfaceFactory {
>    MyFirstInterface getInstance()
>}
>
>interface MySecondInterfaceFactory {
>    MySecondInterface getInstance()
>}
>
>
>2.  Generic interface factory:
>
>interface GenericFactory {
>    Object getInstance()
>    Class getClass()
>}
>
>where different instances of GenericFactory will return from getClass() the
>relevant type, MyFirstInterface, MySecondInterface etc..
>
>I'll try & test something tomorrow
>
>Roger
>
>
>
>"Colin Sampaleanu" <col...@ex...> wrote in message
>news:3FB...@ex......
>  
>
>>I think I may be missing something, but I think it's desireable to be
>>able to create in an easy fashion, 'closures' which encapsulate getting
>>a bean from a bean factory.
>>
>>Say you have an interface
>>  interface MyInteface {   ... whatever }
>>
>>and you have a factory Interface
>>  interface MyInterfaceFactory {
>>    MyInterface getInstance();
>>  }
>>
>>And you have a user of the factory, who you'd rather have no knowledge
>>of Spring, which is why he's using the factory instead of calling
>>getBean himself:
>>class User {
>>  MyInterfaceFactory _myfac;
>>  public void setMyInterfaceFactory(MyInterfaceFactory myfac) { _myfac =
>>myfac; }
>>  public void someMethod() {
>>    // need a new instance of MyInterface to work with
>>    MyInterface myint = _myfac.getInstance();
>>      ...
>>  }
>>}
>>
>>Now I have a bean factory
>><beans>
>>  <bean id="myinterface" singleton="false"
>>class="com.whatever.MyInterfaceImpl">
>>  </bean>
>>  <bean id="user" class="com.whatever.User">
>>    <property name="myInterfaceFactory"><ref bean="xxxxxxxx"/></property>
>>  </bean>
>></beans>
>>
>>now, as per the above, context.getBean("myinterface") is already a
>>factory for objects implementing MyInterface. But I don't want the User
>>object to know anything about contexts. And I'd rather not create an
>>actual object that implements MyInterfaceFactory. It seems like a waste,
>>since all I am doing here is trying to create a level of indirection,
>>and I already have a factory inside the context itself, and I may want
>>to use this approach in 30 different places, just to add a level of
>>indirection in creating new objects.
>>
>>So what I think is needed is some variation of ProxyFactoryBean (but a
>>separate class), which given a target bean (which is itself a factory),
>>and a factory interface having a method with no args which returns a
>>certain type, creates on the fly a new class implementing the factory
>>interface, which will just use the target factory bean to actually
>>supply the instance. So the bean def above would become:
>><beans>
>>  <bean id="myinterface" singleton="false"
>>class="com.whatever.MyInterfaceImpl">
>>  </bean>
>>  <bean id="myinterface-factory"
>>    
>>
>class="org.springframework.whatever.XXXX">
>  
>
>>    <property name="targetBean"><ref bean="xxxxxxxx"/></property>
>>    <property
>>name="interface"><value>x.y.z.AFactoryInterface</value></property>
>>  </bean>
>>  <bean id="user" class="com.whatever.User">
>>    <property name="myInterfaceFactory"><ref
>>bean="myinterface-factory"/></property>
>>  </bean>
>></beans>
>>
>>Am I missing an existing way to do this? Is this worth adding to spring
>>as a convenience built-in, along the lines of TransactionProxyFactoryBean?
>>
>>    
>>

[Springframework-developer] Re: Creating Application Context getBean 'closures'

[roger h. <apo...@sn...>]

Hi Colin

Your thoughts on implementation hiding have got me thinking...

But before I test anything could you clarify the sort of usage you
have in mind - specifically, would it make a difference whether the
implementation hiding factories were themselves 'typed' or 'generic' ie. do
you want / need the type of the factory to vary with the type that it
generates, or would a single generic factory be adequate ?

In other words, does one or other of the following make a difference ?

1.  Typed interface factories:

interface MyFirstInterfaceFactory {
    MyFirstInterface getInstance()
}

interface MySecondInterfaceFactory {
    MySecondInterface getInstance()
}


2.  Generic interface factory:

interface GenericFactory {
    Object getInstance()
    Class getClass()
}

where different instances of GenericFactory will return from getClass() the
relevant type, MyFirstInterface, MySecondInterface etc..

I'll try & test something tomorrow

Roger



"Colin Sampaleanu" <col...@ex...> wrote in message
news:3FB...@ex......
> I think I may be missing something, but I think it's desireable to be
> able to create in an easy fashion, 'closures' which encapsulate getting
> a bean from a bean factory.
>
> Say you have an interface
>   interface MyInteface {   ... whatever }
>
> and you have a factory Interface
>   interface MyInterfaceFactory {
>     MyInterface getInstance();
>   }
>
> And you have a user of the factory, who you'd rather have no knowledge
> of Spring, which is why he's using the factory instead of calling
> getBean himself:
> class User {
>   MyInterfaceFactory _myfac;
>   public void setMyInterfaceFactory(MyInterfaceFactory myfac) { _myfac =
> myfac; }
>   public void someMethod() {
>     // need a new instance of MyInterface to work with
>     MyInterface myint = _myfac.getInstance();
>       ...
>   }
> }
>
> Now I have a bean factory
> <beans>
>   <bean id="myinterface" singleton="false"
> class="com.whatever.MyInterfaceImpl">
>   </bean>
>   <bean id="user" class="com.whatever.User">
>     <property name="myInterfaceFactory"><ref bean="xxxxxxxx"/></property>
>   </bean>
> </beans>
>
> now, as per the above, context.getBean("myinterface") is already a
> factory for objects implementing MyInterface. But I don't want the User
> object to know anything about contexts. And I'd rather not create an
> actual object that implements MyInterfaceFactory. It seems like a waste,
> since all I am doing here is trying to create a level of indirection,
> and I already have a factory inside the context itself, and I may want
> to use this approach in 30 different places, just to add a level of
> indirection in creating new objects.
>
> So what I think is needed is some variation of ProxyFactoryBean (but a
> separate class), which given a target bean (which is itself a factory),
> and a factory interface having a method with no args which returns a
> certain type, creates on the fly a new class implementing the factory
> interface, which will just use the target factory bean to actually
> supply the instance. So the bean def above would become:
> <beans>
>   <bean id="myinterface" singleton="false"
> class="com.whatever.MyInterfaceImpl">
>   </bean>
>   <bean id="myinterface-factory"
class="org.springframework.whatever.XXXX">
>     <property name="targetBean"><ref bean="xxxxxxxx"/></property>
>     <property
> name="interface"><value>x.y.z.AFactoryInterface</value></property>
>   </bean>
>   <bean id="user" class="com.whatever.User">
>     <property name="myInterfaceFactory"><ref
> bean="myinterface-factory"/></property>
>   </bean>
> </beans>
>
> Am I missing an existing way to do this? Is this worth adding to spring
> as a convenience built-in, along the lines of TransactionProxyFactoryBean?
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

[Springframework-developer] In BeanFactory, ref to another bean's properties, not to the other bean directly

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

I keep on running into the case where in defining a bean in a bean 
factory or context, I need to set a property to the value of a property 
from another bean, not the bean itself. How are people typically 
handling this limitation?

For that matter, it would be very useful to be able to get a bean into 
the container via an expression. I am for example using the CCPP 
processing API from Sun. All the classes use a factory to get a bean 
instance. So if I need a ProfileFactory, I get one with this code, 
calling a static method:
  ProfileFactory pf  = ProfileFactoryImpl.getInstance();
I have some beans in a context which need this passed in. I would handle 
this right now by defining a new class which is a FactoryBean, and 
returns the result of the above, but that's kludgy. Now handling any 
kind of generic code of this sort needs an expression evaluator, but I 
think this particular idiom (a static method call on a class) could 
probably be handled in a simpler fashion, built-in?

What do you guys think?

Re: [Springframework-developer] Intercepting a Prototype Bean

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

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

Re: [Springframework-developer] Re: Re: Intercepting a Prototype Bean

[Rod J. <rod...@in...>]

I think I can change it in M3. However, they will be equals() and have the
same target.

Regards,
Rod

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

Re: [Springframework-developer] AutoProxyCreator problem

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

Indeed, it did - I've removed it because bean definitions and thus the =
RootBeanDefinition class are an internal implemenation detail of the =
AbstractBeanFactory class hierarchy, while BeanPostProcessor is supposed =
to be a generic interface for all BeanFactory implementations.
=20
I'll change AbstractBeanFactory's getMergedBeanDefinition to public. =
That will allow for letting a BeanPostProcessor implement =
BeanFactoryAware, and cast the passed BeanFactory to AbstractBeanFactory =
to be able to invoke getMergedBeanDefinition. This way, a =
BeanPostProcessor implementation can choose to be aware of bean =
definitions but doesn't have to.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Kopylenko, Dmitry
Gesendet: Do 20.11.2003 22:01
An: 'spr...@li...'
Betreff: RE: [Springframework-developer] AutoProxyCreator problem



I believe that postProcessBean() used to have BeanDefinition as =
argument.

D.

-----Original Message-----
From: Rajeev Kaul [mailto:Ra...@cu...]
Sent: Thursday, November 20, 2003 3:52 PM
To: spr...@li...
Subject: Re: [Springframework-developer] AutoProxyCreator problem


Rod,

You mean, modify the BeanPostProcessor interface method =
postProcessBean() to
include the bean definition?  This would involve modifying =
BeanPostProcessor
implementations and the applyBeanPostProcessors() method of the
AbstractBeanFactory class to include the bean definition.

regards,

Rajeev


----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Thursday, November 20, 2003 12:23 PM
Subject: Re: [Springframework-developer] AutoProxyCreator problem


> It's meant to be an SPI interface. However I think with the
> PostProcessor API there may be a call for exposing the BeanDefinition
> to _That_. Not via the BeanFactoyr interface though.
>
> R
> ----- Original Message -----
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Thursday, November 20, 2003 8:00 PM
> Subject: RE: [Springframework-developer] AutoProxyCreator problem
>
>
> > Rajeev,
> >
> > You're right. There is no public API for getBeanDefinition(). There
> > is a protected abstract getBeanDefinition(String) in
> > AbstractBeanFactory
> designed
> > for subclasses to implement "Template Method" design pattern.
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: Rajeev Kaul [mailto:Ra...@cu...]
> > Sent: Thursday, November 20, 2003 2:39 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] AutoProxyCreator problem
> >
> >
> > Dmitry,
> >
> > How do you get the bean definition from a bean factory?  There does
> > not
> seem
> > to be any public method for it.
> >
> > regards,
> >
> > Rajeev
> > ----- Original Message -----
> > From: "Kopylenko, Dmitry" <dko...@su...>
> > To: "'Rajeev Kaul '" <Ra...@cu...>;
> > <spr...@li...>
> > Sent: Wednesday, November 19, 2003 5:16 PM
> > Subject: RE: [Springframework-developer] AutoProxyCreator problem
> >
> >
> > > As to your first problem, you would need to create a new instance
> > > of the BeanFactory Consider the following piece of code (taken
> > > from
> > > EnterpriseServices.createInvokerInterceptor() ):
> > >
> > > // Infinite cycle: tries to create the bean if we don't use a
> > > different factory ListableBeanFactoryImpl bf2 =3D new
> > > ListableBeanFactoryImpl(); bf2.registerBeanDefinition(beanName,
> > > definition); cpii.setBeanFactory(bf2);
> > >
> > > ...where cpii is the reference of type
> > > AbstractPoolingInvokerInterceptor which extends
> > > PrototypeInvokerInterceptor
> > >
> > > I guess this is what you need.
> > >
> > > Dmitriy.
> > >
> > > -----Original Message-----
> > > From: Rajeev Kaul
> > > To: spr...@li...
> > > Sent: 11/19/2003 7:33 PM
> > > Subject: Re: [Springframework-developer] AutoProxyCreator problem
> > >
> > > I am thinking of a solution for condensing the verbose
> > > configuration (shown below) for prototype business logic beans I
> > > am using in my application.  A shared controller instance
> > > (singelton) creates the business logic bean.  However the business
> > > logic bean must be instantiated per each thread that runs through
> > > the shared controller. I have been using the configuration shown
> > > below:
> > >
> > >
> > > <bean id=3D"prototypeBean" class=3D"xyz.BusLogicBean"
> > > singleton=3D"false">
> > >
> > > <property name=3D"count"><value>10</value></property>
> > >
> > > </bean>
> > >
> > > <bean id=3D"prototypeInvokerInterceptor"
> > > =
class=3D"org.springframework.aop.interceptor.PrototypeInvokerInterce
> > > ptor
> > > ">
> > >
> > >
> > > <property
> > > name=3D"targetBeanName"><value>prototypeBean</value></property>
> > >
> > > </bean>
> > >
> > > <bean id=3D"prototype"
> > > class=3D"org.springframework.aop.framework.ProxyFactoryBean">
> > >
> > > <property
> > > =
name=3D"interceptorNames"><value>prototypeInvokerInterceptor</value>
> > > </pr
> > > op
> > > erty>
> > >
> > > </bean>
> > >
> > >
> > >
> > > As you can see this is very verbose, especially if you have a lot
> > > of these business logic beans in your application.  I tried using
> > > a derived version of BeanNameAutoProxyCreator to solve this, but
> > > ran into problems. I would like to replace this configuration with
> > > something shown below:
> > >
> > >
> > >
> > > <bean id=3D"prototypeBean" class=3D"xyz.BusLogicBean"
> > > singleton=3D"false" proxy=3D"prototype">
> > >
> > > <property name=3D"count"><value>10</value></property>
> > >
> > > </bean>
> > >
> > > This would involve adding a "PROXY" attribute which would specify
> > > the type of proxy interceptor desired for the bean.  For example,
> > > "prototype" would mean ProxyFactoryBean with
> > > PrototypeInvokerInterceptor, "default" would mean ProxyFactoryBean
> > > with InvokerInterceptor, etc.  In loadBeanDefinition() method of
> > > the XmlBeanFactory class, the supporting proxy classes
> > > (ProxyFactoryBean and PrototypeInvokerInterceptor) could be
> > > automatically generated and registered.
> > >
> > > Any suggestions, comments, ...?
> > >
> > >
> > >
> > > Rajeev
> > >
> > > ----- Original Message -----
> > > From: Rajeev Kaul <mailto:Ra...@cu...>
> > > To: spr...@li...
> > > <mailto:spr...@li...>
> > > Sent: Tuesday, November 18, 2003 1:29 PM
> > > Subject: [Springframework-developer] AutoProxyCreator problem
> > >
> > >
> > > I have been trying to use BeanNameAutoProxyCreator class (I
> > > noticed there are no test cases for it) to create proxies for
> > > "prototype" business objects. I extended the
> > > BeanNameAutoProxyCreator class to use the
> > > PrototypeInvokerInterceptor in the "createInvokerInterceptor()"
> > > method.  However, this results in an infinite loop, as the
> > > PrototypeInvokerInterceptor calls the beanFactory getBean() method
> > > which in turn triggers the beanPostProcessor and the cycle repeats
> > > endlessly.
> > >
> > > Any suggestions on getting around this problem?
> > >
> > > It would have been better, if the BeanNameAutoProxyCreator class
> > > was designed to take invokerInterceptor as a property, which could
> > > be specified in the configuration, instead of having to subclass
> > > it to use other invokerInterceptor(s).
> > >
> > > Rajeev Kaul
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-devel
> > > oper
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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-develop
> > er
> >
> >
> > -------------------------------------------------------
> > 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-develop
> > er
> >
>
>
>
>
> -------------------------------------------------------
> 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/
_______________________________________________
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/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] AutoProxyCreator problem

[Kopylenko, D. <dko...@ac...>]

I believe that postProcessBean() used to have BeanDefinition as argument.

D.

-----Original Message-----
From: Rajeev Kaul [mailto:Ra...@cu...] 
Sent: Thursday, November 20, 2003 3:52 PM
To: spr...@li...
Subject: Re: [Springframework-developer] AutoProxyCreator problem


Rod,

You mean, modify the BeanPostProcessor interface method postProcessBean() to
include the bean definition?  This would involve modifying BeanPostProcessor
implementations and the applyBeanPostProcessors() method of the
AbstractBeanFactory class to include the bean definition.

regards,

Rajeev


----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Thursday, November 20, 2003 12:23 PM
Subject: Re: [Springframework-developer] AutoProxyCreator problem


> It's meant to be an SPI interface. However I think with the 
> PostProcessor API there may be a call for exposing the BeanDefinition 
> to _That_. Not via the BeanFactoyr interface though.
>
> R
> ----- Original Message -----
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Thursday, November 20, 2003 8:00 PM
> Subject: RE: [Springframework-developer] AutoProxyCreator problem
>
>
> > Rajeev,
> >
> > You're right. There is no public API for getBeanDefinition(). There 
> > is a protected abstract getBeanDefinition(String) in 
> > AbstractBeanFactory
> designed
> > for subclasses to implement "Template Method" design pattern.
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: Rajeev Kaul [mailto:Ra...@cu...]
> > Sent: Thursday, November 20, 2003 2:39 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] AutoProxyCreator problem
> >
> >
> > Dmitry,
> >
> > How do you get the bean definition from a bean factory?  There does 
> > not
> seem
> > to be any public method for it.
> >
> > regards,
> >
> > Rajeev
> > ----- Original Message -----
> > From: "Kopylenko, Dmitry" <dko...@su...>
> > To: "'Rajeev Kaul '" <Ra...@cu...>;
> > <spr...@li...>
> > Sent: Wednesday, November 19, 2003 5:16 PM
> > Subject: RE: [Springframework-developer] AutoProxyCreator problem
> >
> >
> > > As to your first problem, you would need to create a new instance 
> > > of the BeanFactory Consider the following piece of code (taken 
> > > from
> > > EnterpriseServices.createInvokerInterceptor() ):
> > >
> > > // Infinite cycle: tries to create the bean if we don't use a 
> > > different factory ListableBeanFactoryImpl bf2 = new 
> > > ListableBeanFactoryImpl(); bf2.registerBeanDefinition(beanName,
> > > definition); cpii.setBeanFactory(bf2);
> > >
> > > ...where cpii is the reference of type 
> > > AbstractPoolingInvokerInterceptor which extends 
> > > PrototypeInvokerInterceptor
> > >
> > > I guess this is what you need.
> > >
> > > Dmitriy.
> > >
> > > -----Original Message-----
> > > From: Rajeev Kaul
> > > To: spr...@li...
> > > Sent: 11/19/2003 7:33 PM
> > > Subject: Re: [Springframework-developer] AutoProxyCreator problem
> > >
> > > I am thinking of a solution for condensing the verbose 
> > > configuration (shown below) for prototype business logic beans I 
> > > am using in my application.  A shared controller instance 
> > > (singelton) creates the business logic bean.  However the business 
> > > logic bean must be instantiated per each thread that runs through 
> > > the shared controller. I have been using the configuration shown 
> > > below:
> > >
> > >
> > > <bean id="prototypeBean" class="xyz.BusLogicBean" 
> > > singleton="false">
> > >
> > > <property name="count"><value>10</value></property>
> > >
> > > </bean>
> > >
> > > <bean id="prototypeInvokerInterceptor" 
> > > class="org.springframework.aop.interceptor.PrototypeInvokerInterce
> > > ptor
> > > ">
> > >
> > >
> > > <property 
> > > name="targetBeanName"><value>prototypeBean</value></property>
> > >
> > > </bean>
> > >
> > > <bean id="prototype" 
> > > class="org.springframework.aop.framework.ProxyFactoryBean">
> > >
> > > <property 
> > > name="interceptorNames"><value>prototypeInvokerInterceptor</value>
> > > </pr
> > > op
> > > erty>
> > >
> > > </bean>
> > >
> > >
> > >
> > > As you can see this is very verbose, especially if you have a lot 
> > > of these business logic beans in your application.  I tried using 
> > > a derived version of BeanNameAutoProxyCreator to solve this, but 
> > > ran into problems. I would like to replace this configuration with 
> > > something shown below:
> > >
> > >
> > >
> > > <bean id="prototypeBean" class="xyz.BusLogicBean" 
> > > singleton="false" proxy="prototype">
> > >
> > > <property name="count"><value>10</value></property>
> > >
> > > </bean>
> > >
> > > This would involve adding a "PROXY" attribute which would specify 
> > > the type of proxy interceptor desired for the bean.  For example, 
> > > "prototype" would mean ProxyFactoryBean with 
> > > PrototypeInvokerInterceptor, "default" would mean ProxyFactoryBean 
> > > with InvokerInterceptor, etc.  In loadBeanDefinition() method of 
> > > the XmlBeanFactory class, the supporting proxy classes 
> > > (ProxyFactoryBean and PrototypeInvokerInterceptor) could be 
> > > automatically generated and registered.
> > >
> > > Any suggestions, comments, ...?
> > >
> > >
> > >
> > > Rajeev
> > >
> > > ----- Original Message -----
> > > From: Rajeev Kaul <mailto:Ra...@cu...>
> > > To: spr...@li...
> > > <mailto:spr...@li...>
> > > Sent: Tuesday, November 18, 2003 1:29 PM
> > > Subject: [Springframework-developer] AutoProxyCreator problem
> > >
> > >
> > > I have been trying to use BeanNameAutoProxyCreator class (I 
> > > noticed there are no test cases for it) to create proxies for 
> > > "prototype" business objects. I extended the 
> > > BeanNameAutoProxyCreator class to use the 
> > > PrototypeInvokerInterceptor in the "createInvokerInterceptor()" 
> > > method.  However, this results in an infinite loop, as the 
> > > PrototypeInvokerInterceptor calls the beanFactory getBean() method 
> > > which in turn triggers the beanPostProcessor and the cycle repeats 
> > > endlessly.
> > >
> > > Any suggestions on getting around this problem?
> > >
> > > It would have been better, if the BeanNameAutoProxyCreator class 
> > > was designed to take invokerInterceptor as a property, which could 
> > > be specified in the configuration, instead of having to subclass 
> > > it to use other invokerInterceptor(s).
> > >
> > > Rajeev Kaul
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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-devel
> > > oper
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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-develop
> > er
> >
> >
> > -------------------------------------------------------
> > 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-develop
> > er
> >
>
>
>
>
> -------------------------------------------------------
> 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/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] AutoProxyCreator problem

[Rajeev K. <Ra...@cu...>]

Rod,

You mean, modify the BeanPostProcessor interface method postProcessBean() to
include the bean definition?  This would involve modifying BeanPostProcessor
implementations and the applyBeanPostProcessors() method of the
AbstractBeanFactory class to include the bean definition.

regards,

Rajeev


----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Thursday, November 20, 2003 12:23 PM
Subject: Re: [Springframework-developer] AutoProxyCreator problem


> It's meant to be an SPI interface. However I think with the PostProcessor
> API there may be a call for exposing the BeanDefinition to _That_. Not via
> the BeanFactoyr interface though.
>
> R
> ----- Original Message -----
> From: "Kopylenko, Dmitry" <dko...@su...>
> To: <spr...@li...>
> Sent: Thursday, November 20, 2003 8:00 PM
> Subject: RE: [Springframework-developer] AutoProxyCreator problem
>
>
> > Rajeev,
> >
> > You're right. There is no public API for getBeanDefinition(). There is a
> > protected abstract getBeanDefinition(String) in AbstractBeanFactory
> designed
> > for subclasses to implement "Template Method" design pattern.
> >
> > Regards,
> > Dmitriy.
> >
> > -----Original Message-----
> > From: Rajeev Kaul [mailto:Ra...@cu...]
> > Sent: Thursday, November 20, 2003 2:39 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] AutoProxyCreator problem
> >
> >
> > Dmitry,
> >
> > How do you get the bean definition from a bean factory?  There does not
> seem
> > to be any public method for it.
> >
> > regards,
> >
> > Rajeev
> > ----- Original Message -----
> > From: "Kopylenko, Dmitry" <dko...@su...>
> > To: "'Rajeev Kaul '" <Ra...@cu...>;
> > <spr...@li...>
> > Sent: Wednesday, November 19, 2003 5:16 PM
> > Subject: RE: [Springframework-developer] AutoProxyCreator problem
> >
> >
> > > As to your first problem, you would need to create a new instance of
> > > the BeanFactory Consider the following piece of code (taken from
> > > EnterpriseServices.createInvokerInterceptor() ):
> > >
> > > // Infinite cycle: tries to create the bean if we don't use a
> > > different factory ListableBeanFactoryImpl bf2 = new
> > > ListableBeanFactoryImpl(); bf2.registerBeanDefinition(beanName,
> > > definition); cpii.setBeanFactory(bf2);
> > >
> > > ...where cpii is the reference of type
> > > AbstractPoolingInvokerInterceptor which extends
> > > PrototypeInvokerInterceptor
> > >
> > > I guess this is what you need.
> > >
> > > Dmitriy.
> > >
> > > -----Original Message-----
> > > From: Rajeev Kaul
> > > To: spr...@li...
> > > Sent: 11/19/2003 7:33 PM
> > > Subject: Re: [Springframework-developer] AutoProxyCreator problem
> > >
> > > I am thinking of a solution for condensing the verbose configuration
> > > (shown below) for prototype business logic beans I am using in my
> > > application.  A shared controller instance (singelton) creates the
> > > business logic bean.  However the business logic bean must be
> > > instantiated per each thread that runs through the shared controller.
> > > I have been using the configuration shown below:
> > >
> > >
> > > <bean id="prototypeBean" class="xyz.BusLogicBean" singleton="false">
> > >
> > > <property name="count"><value>10</value></property>
> > >
> > > </bean>
> > >
> > > <bean id="prototypeInvokerInterceptor"
> > > class="org.springframework.aop.interceptor.PrototypeInvokerInterceptor
> > > ">
> > >
> > >
> > > <property
> > > name="targetBeanName"><value>prototypeBean</value></property>
> > >
> > > </bean>
> > >
> > > <bean id="prototype"
> > > class="org.springframework.aop.framework.ProxyFactoryBean">
> > >
> > > <property
> > > name="interceptorNames"><value>prototypeInvokerInterceptor</value></pr
> > > op
> > > erty>
> > >
> > > </bean>
> > >
> > >
> > >
> > > As you can see this is very verbose, especially if you have a lot of
> > > these business logic beans in your application.  I tried using a
> > > derived version of BeanNameAutoProxyCreator to solve this, but ran
> > > into problems. I would like to replace this configuration with
> > > something shown below:
> > >
> > >
> > >
> > > <bean id="prototypeBean" class="xyz.BusLogicBean" singleton="false"
> > > proxy="prototype">
> > >
> > > <property name="count"><value>10</value></property>
> > >
> > > </bean>
> > >
> > > This would involve adding a "PROXY" attribute which would specify the
> > > type of proxy interceptor desired for the bean.  For example,
> > > "prototype" would mean ProxyFactoryBean with
> > > PrototypeInvokerInterceptor, "default" would mean ProxyFactoryBean
> > > with InvokerInterceptor, etc.  In loadBeanDefinition() method of the
> > > XmlBeanFactory class, the supporting proxy classes (ProxyFactoryBean
> > > and PrototypeInvokerInterceptor) could be automatically generated and
> > > registered.
> > >
> > > Any suggestions, comments, ...?
> > >
> > >
> > >
> > > Rajeev
> > >
> > > ----- Original Message -----
> > > From: Rajeev Kaul <mailto:Ra...@cu...>
> > > To: spr...@li...
> > > <mailto:spr...@li...>
> > > Sent: Tuesday, November 18, 2003 1:29 PM
> > > Subject: [Springframework-developer] AutoProxyCreator problem
> > >
> > >
> > > I have been trying to use BeanNameAutoProxyCreator class (I noticed
> > > there are no test cases for it) to create proxies for "prototype"
> > > business objects. I extended the BeanNameAutoProxyCreator class to use
> > > the PrototypeInvokerInterceptor in the "createInvokerInterceptor()"
> > > method.  However, this results in an infinite loop, as the
> > > PrototypeInvokerInterceptor calls the beanFactory getBean() method
> > > which in turn triggers the beanPostProcessor and the cycle repeats
> > > endlessly.
> > >
> > > Any suggestions on getting around this problem?
> > >
> > > It would have been better, if the BeanNameAutoProxyCreator class was
> > > designed to take invokerInterceptor as a property, which could be
> > > specified in the configuration, instead of having to subclass it to
> > > use other invokerInterceptor(s).
> > >
> > > Rajeev Kaul
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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/
> > _______________________________________________
> > 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/
> > _______________________________________________
> > 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/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer