ProxyFactory keeps creating new instances, despite SingletonTargetSource

[Injecteer]

hi all

I have a problem with the following piece o'code:

      ProxyFactory pf = new ProxyFactory();
      pf.setProxyTargetClass( true );

      pf.addAdvisor( advisor );
      pf.setTargetSource( new SingletonTargetSource( object ) );
      Object proxy = pf.getProxy(); //<-- here I'm getting a blank new instance instead of a proxied object

Any ideas, how to make (fool?) the ProxyFactory return the proxied object instead of an empty proxy?

Thanks

[Rick Evans]

Hi Injecteer

Not trying to be funny here, but what exactly do you mean?

The title of the post is 'ProxyFactory keeps creating new instances', but in the body of your post you say that the 'blank new instance'. By 'blank new instance' new you mean that a new instance of your object is being created using the default no-arg constructor?

Remember that when using CGLIB-based proxies, an extra instance of your class will be created... one for the 'real' object (the one that you pass into the constructor of the SingletonTargetSource), and then another extra one when the proxy is realised by the AOP framework because CGLIB will create a subclass that will be the proxy. So everytime you call getProxy(), and you are using CGLIB, yes! a new instance of the subclass of your class will indeed be being created. This is a 'feature' of class based proxies... however, only one instance of your 'real' object is ever going to be instantiated, and that is the one that you instantiated yourself and passed into the constructor of the SingletonTargetSource.

I know I haven't answered your question... sorry for the lecture

Cheers
Rick

[Injecteer]

thanks for the answer (attempt ) Rick,

The thing is, that in case of a JdkDynProxy you get a "proxied" object, with the property values being equal to the original.
I thought, that I'd get the same behaviour also in case with the Cglib-based approach, but the properties of the proxy remain not set, like I've invoked a non-arg constructor.

Is this intentionally done that way?

[Rick Evans]

Hi

... the properties of the proxy remain not set, like I've invoked a non-arg constructor.

The properties of the proxy are indeed going to be not set, just like you've invoked a non-arg constructor because that is exactly what has happened. The CGLIB-based proxy creating strategy class will invoke the no-arg ctor when creating the class based proxy.

Is this intentionally done that way?

Yes. All of the state is preserved on your 'real' object instance. There is no state (well, state in the sense of your business) on the proxy, it is all inside your object, where it should be. The CGLIB-based class proxy is just a mechanism for exposing the same interface as the class that is being proxied, nothing more.

I wrote (briefly) about this 'feature in the reference manual (3rd bullet point):

http://static.springframework.org/sp...l#aop-proxying

I could have gone into more detail about this, but this would be CGLIB-specific and nothing really to do with Spring per-se. The Spring documentation is (to my mind) too large as it is, and showing signs of its age. It needs a darn good editing, and while I have no time right now to do the editing, I do try to keep the amount of stuff that goes into the documentation at each release down to a minimum - even if some folks do say that I have a purple writing style I'm trying to improve that.

Cheers
Rick

[Jörg Heinicke]

The Spring documentation is (to my mind) too large as it is, and showing signs of its age. It needs a darn good editing, and while I have no time right now to do the editing, I do try to keep the amount of stuff that goes into the documentation at each release down to a minimum - even if some folks do say that I have a purple writing style I'm trying to improve that.

Rick,

(slightly off-topic, but) be assured Spring has one of the best documentation of the big open source projects I'm aware of. And in my current project I had to work with lots of new stuff and so much documentation, for example Liferay or Hibernate. Maybe this could be one of the next polls: Which parts do you want to have improved in the reference?

Regards
Jörg