SpringWebApplicationFactory - which will pull the webapplication subclass out of spring application context
SpringInjector/SpringWebApplica
tion - make it very simple to inject objects using @SpringBean annotation with lazy-init proxies
SpringWebPage - autoinitailizes its subclasses using the SpringInjector
I also deprecated all the old stuff and moved it into wicket.contrib.spring.old package. The new stuff is the "official/supported/standard/whateveryouwanttocallit" way to do spring integration.
currently we only provide an easy way to inject objects using jdk5 annotations. it is possible to create a jdk1.4 object locator factories, but there are many options as to how to store metadata/do the lookup. if someone is interested in this please let me know and we can discuss some ways of doing this.
As always, any feedback is greatly appreciated.
-Igor
SpringWebPage - autoinitailizes its subclasses using the SpringInjector
I also deprecated all the old stuff and moved it into wicket.contrib.spring.old package. The new stuff is the "official/supported/standard/whateveryouwanttocallit" way to do spring integration.
currently we only provide an easy way to inject objects using jdk5 annotations. it is possible to create a jdk1.4 object locator factories, but there are many options as to how to store metadata/do the lookup. if someone is interested in this please let me know and we can discuss some ways of doing this.
As always, any feedback is greatly appreciated.
-Igor
On 11/9/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
heh, looks like we pretty much did the same thing. my proxies arent as advanced as yours, dont know if that a plus or a minus at this point. I liked the lazyinitproxy interface so i just added that to my code.
im attaching the code to make it easier to find.
-Igor
On 11/9/05, Christian Essl <[EMAIL PROTECTED] > wrote:Unfortunately the public cvs is late so I can't see your changes yet.
Anyway before I've read this mail I started on reworking the proxing code
(attached). SerializableLazyProxyCreator is the only thing with content
the others are interfaces and one (basic) test.
There are quite some changes:
- uses as now as said yesterday an ObjectResolver (I've to check with your
refactoring)
- fixed differend bugs in my original writeReplace/resolve code of the
CGLIB proxy
- JDK and CGLIB proxies implement LazyInitProxy. This can be useful to see
if an object is already a lazy init proxy and to get the ObjectResolver
from it (the cglib intercepors don't have to be serialziable anymore).
- JDK and CLGIB: added handling of equals/hashCode methods (compares the
proxy for identity - instead of forwarind to the target)
- CGLIB: truned of the forward of the other Object methods to the target
(especially finalize()) - exactly like for JDK proxies (toString() is
forwarded)
- JDK proxies: better method invocation exception handling
- JDK and CGLIB: when the result of a method call is the target itself it
returns the proxy (at least one point of leaking of the target can be
excluded)
- I don't serialize the class but the class name and get it from the
context ClassLoader - is this ok?
- and finally all is now in one class which automatically makes either a
cglib or class proxy (don't know wheter this is good)
There is also a rudimentary test case, which however only tests the CGLIB
thing. There are also some println statements still in the code (it is
hard to properly unit test the writeReplace/readResolve methods).
Christian
On Wed, 9 Nov 2005 00:20:32 -0800, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:
> round 1 of refactoring is in. its much more elegant now. feedback please.
>
> -Igor
>
>
