a simple approach for 1.4 would be to "autowire" the dependencies.
1) try to find a bean with name==field.name and type==field.type
2) if 1 fails try to lookup bean only by field.type
3) if 2 returns none: ignore, if more then one: error
thoughts?
-Igor
On 11/11/05, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
I would be very interested in a 1.4 port of this. Do you think it
could use the same annotation based approach, but using Qdox to
process instead of the built in 1.5 annotation functionality?
On 11/11/05, Christian Essl < [EMAIL PROTECTED]> wrote:
> The code realy looks good.
>
> Concerning the Proxy. For the cglib proxy you should definately not
> forward the call to finalize(), because when the proxy gets GC it will
> call finalize() on the target and that is not what you want. I think same
> reasons apply for the other Object methods except equals, hasCode and
> toStrign. JDK proxies do not forward them as well.
>
> Serializing: CGLIB proxies. I think the problem if you just plainly
> serialize them withotu writeReplace/readResolve is that if the proxy gets
> desiarialized in another VM than the dynamically create class of CGLIB
> could not be yet there. So this could make problems in clusters etc.
>
> Christian
>
> On Fri, 11 Nov 2005 00:50:13 -0800, Igor Vaynberg
> < [EMAIL PROTECTED]> wrote:
>
> > more refactoring/tests and some new things:
> >
> > 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
> >
> >
> >
> > 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
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
>
>
>
> --
> Christian Essl
>
>
>
>
>
> ___________________________________________________________
> Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
