subject:"\[Wicket\-user\] My take on Spring integration"

ok, lots more refactoring in.

lazy init proxies now intercept hashcode,equals,tostring,finalize.

i tried implementing writereplace and readresolve but it doesnt seem to
be working, getting another weird class cast exception. writereplace
works fine, and the object it generates deserializes into a proxy, so
something weird is happening somewhere. maybe you can take a look, it
has a failing unit test.

i created a IFieldValueFactory and generalized the injector away from
proxies. I renamed the IObjectLocator to IProxyTargetLocator. Instead
of IObjectLocatorFactory there is now ProxyFieldValueFactory which acts
as an adapter between the IProxyTargetLocator and IFieldValueFactory.
So now you can inject arbitrary values using the injector, not just
proxies.

created CompoundFieldValueFactory to allow injection from multiple IFieldValueFactories.

-Igor

On 11/11/05, Christian Essl [EMAIL PROTECTED] wrote:
On Fri, 11 Nov 2005 14:51:16 -0800, Igor Vaynberg[EMAIL PROTECTED] wrote: i was actually thinking of creating a CompoundObjectLocatorFactory which
would try its children until one returns a non-null. will try to get to that tonight as well :)That's better than my suggestion - Thank you.While I suggested to use an IObjectLocatorFactory I now think it would be
better if the ProxyInjector would take something like:interface IFieldInstanceCreator{Object createFieldInstance(Object fieldOwner, Field field);}The IInstanceCreator creates the Proxy or what ever it things fits right.
(For convinience you could have a ObjectLocatorFactory which implementsIInstanceCreator).The reason for this is that I'd like to have an annotation(SessionProperty) which injects my ShoppingCard from the my WebSession. I
think it could be useful in other arears as well where there is not thesame serialization problem as with spring beans or a better way than touse an object locator - just less coupling.Christian
___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. Downloadit 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.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

Re: Re: [Wicket-user] My take on Spring integration

2005-11-12 Thread Christian Essl

Thanks a lot for doing this. Unfortunately I can still not check out the
changes. When I can I'll take a look at the LazyInitProxyFactory.

Christian

On Sat, 12 Nov 2005 01:12:21 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote:

ok, lots more refactoring in.

lazy init proxies now intercept hashcode,equals,tostring,finalize.

i tried implementing writereplace and readresolve but it doesnt seem to
be

working, getting another weird class cast exception. writereplace works
fine, and the object it generates deserializes into a proxy, so something
weird is happening somewhere. maybe you can take a look, it has a failing
unit test.

i created a IFieldValueFactory and generalized the injector away from
proxies. I renamed the IObjectLocator to IProxyTargetLocator. Instead of
IObjectLocatorFactory there is now ProxyFieldValueFactory which acts as
an
adapter between the IProxyTargetLocator and IFieldValueFactory. So now
you

can inject arbitrary values using the injector, not just proxies.

created CompoundFieldValueFactory to allow injection from multiple
IFieldValueFactories.

-Igor

On 11/11/05, Christian Essl [EMAIL PROTECTED] wrote:

On Fri, 11 Nov 2005 14:51:16 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote:

i was actually thinking of creating a CompoundObjectLocatorFactory
which

would try its children until one returns a non-null.

will try to get to that tonight as well :)

That's better than my suggestion - Thank you.

While I suggested to use an IObjectLocatorFactory I now think it would
be

better if the ProxyInjector would take something like:

interface IFieldInstanceCreator{
Object createFieldInstance(Object fieldOwner, Field field);
}

The IInstanceCreator creates the Proxy or what ever it things fits
right.

(For convinience you could have a ObjectLocatorFactory which implements
IInstanceCreator).

The reason for this is that I'd like to have an annotation
(SessionProperty) which injects my ShoppingCard from the my WebSession.
I

think it could be useful in other arears as well where there is not the
same serialization problem as with spring beans or a better way than to
use an object locator - just less coupling.

Christian

___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
anmelden: http://mail.yahoo.de

--
Christian Essl

___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: Re: [Wicket-user] My take on Spring integration

fixed the serialization problem. it was just too tired last night to see it.

-Igor
On 11/12/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
ok, lots more refactoring in.

lazy init proxies now intercept hashcode,equals,tostring,finalize.

created CompoundFieldValueFactory to allow injection from multiple IFieldValueFactories.

-Igor

On 11/11/05, Christian Essl
[EMAIL PROTECTED] wrote:

On Fri, 11 Nov 2005 14:51:16 -0800, Igor Vaynberg[EMAIL PROTECTED] wrote: i was actually thinking of creating a CompoundObjectLocatorFactory which
would try its children until one returns a non-null. will try to get to that tonight as well :)That's better than my suggestion - Thank you.While I suggested to use an IObjectLocatorFactory I now think it would be
better if the ProxyInjector would take something like:interface IFieldInstanceCreator{Object createFieldInstance(Object fieldOwner, Field field);}The IInstanceCreator creates the Proxy or what ever it things fits right.
(For convinience you could have a ObjectLocatorFactory which implementsIInstanceCreator).The reason for this is that I'd like to have an annotation(SessionProperty) which injects my ShoppingCard from the my WebSession. I
think it could be useful in other arears as well where there is not thesame serialization problem as with spring beans or a better way than touse an object locator - just less coupling.Christian

___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. Downloadit 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.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

Re: Re: [Wicket-user] My take on Spring integration

Looking at your code makes me want to think we can use some abstract
classes. The fact that you extended SpringInjector instead of
ProxyInjector ... i will need to come up with something for that...

Do you mind if i put your stuff into the main project? Not sure how to
manage this stuff best...plugins will require different dependencies so
that will pollute the main projects, but the plugins are too small to
warrant their own projects...

decisions decisions

-Igor
On 11/11/05, Christian Essl [EMAIL PROTECTED] wrote:
Igor made it quite easy to add your own way to inject things (not justSpringBeans). You just implement your own IObjectLocatorFactory and extendthe SpringInjector to use this one.Enclosed is some code which uses jakarta commons-attributes to do the same
thing as JDK1.5 annotations does with javadoc (the code is not tested butit is fairly simple so it should work).BTW: Maybe the ProxyInjector could take an array of IObjectLocatorFactoryand takes the first one which does not return null. This way you could
combine different IObjectLocatorFatories in one place?ChristianOn Fri, 11 Nov 2005 14:34:28 -0600, 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

Re: Re: [Wicket-user] My take on Spring integration

fixed the serialization problem. it was just too tired last night to see it.

-Igor
On 11/12/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
ok, lots more refactoring in.

lazy init proxies now intercept hashcode,equals,tostring,finalize.

created CompoundFieldValueFactory to allow injection from multiple IFieldValueFactories.

-Igor

On 11/11/05, Christian Essl
[EMAIL PROTECTED] wrote:

Re: Re: [Wicket-user] My take on Spring integration

2005-11-11 Thread Igor Vaynberg

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 yourrefactoring)- fixed differend bugs in my original writeReplace/resolve code of the
CGLIB proxy- JDK and CGLIB proxies implement LazyInitProxy. This can be useful to seeif 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 theproxy 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 itreturns 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 thecontext ClassLoader - is this ok?- and finally all is now in one class which automatically makes either acglib or class proxy (don't know wheter this is good)
There is also a rudimentary test case, which however only tests the CGLIBthing. There are also some println statements still in the code (it ishard to properly unit test the writeReplace/readResolve methods).
ChristianOn 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

Re: Re: [Wicket-user] My take on Spring integration

2005-11-11 Thread Christian Essl


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

Re: Re: [Wicket-user] My take on Spring integration

2005-11-11 Thread Ryan Sonnek

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

Re: Re: [Wicket-user] My take on Spring integration

2005-11-11 Thread Igor Vaynberg

unlike annotations javadocs are not present at runtime, so i dont see a
way to extract that metadata without some code generation step.

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 itcould use the same annotation based approach, but using Qdox toprocess 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

Re: Re: [Wicket-user] My take on Spring integration

2005-11-11 Thread Christian Essl

Igor made it quite easy to add your own way to inject things (not just 
SpringBeans). You just implement your own IObjectLocatorFactory and extend 
the SpringInjector to use this one.


Enclosed is some code which uses jakarta commons-attributes to do the same 
thing as JDK1.5 annotations does with javadoc (the code is not tested but 
it is fairly simple so it should work).


BTW: Maybe the ProxyInjector could take an array of IObjectLocatorFactory 
and takes the first one which does not return null. This way you could 
combine different IObjectLocatorFatories in one place?


Christian



On Fri, 11 Nov 2005 14:34:28 -0600, 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





___

Re: Re: [Wicket-user] My take on Spring integration

2005-11-11 Thread Igor Vaynberg

i was actually thinking of creating a CompoundObjectLocatorFactory which would try its children until one returns a non-null.

will try to get to that tonight as well :)

-Igor
On 11/11/05, Christian Essl [EMAIL PROTECTED] wrote:
Igor made it quite easy to add your own way to inject things (not justSpringBeans). You just implement your own IObjectLocatorFactory and extendthe SpringInjector to use this one.Enclosed is some code which uses jakarta commons-attributes to do the same
thing as JDK1.5 annotations does with javadoc (the code is not tested butit is fairly simple so it should work).BTW: Maybe the ProxyInjector could take an array of IObjectLocatorFactoryand takes the first one which does not return null. This way you could
combine different IObjectLocatorFatories in one place?ChristianOn Fri, 11 Nov 2005 14:34:28 -0600, 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

Re: Re: [Wicket-user] My take on Spring integration

2005-11-11 Thread Christian Essl

On Fri, 11 Nov 2005 14:51:16 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote:

i was actually thinking of creating a CompoundObjectLocatorFactory which
would try its children until one returns a non-null.

will try to get to that tonight as well :)

That's better than my suggestion - Thank you.

While I suggested to use an IObjectLocatorFactory I now think it would be
better if the ProxyInjector would take something like:

interface IFieldInstanceCreator{
Object createFieldInstance(Object fieldOwner, Field field);
}

The IInstanceCreator creates the Proxy or what ever it things fits right.
(For convinience you could have a ObjectLocatorFactory which implements
IInstanceCreator).

The reason for this is that I'd like to have an annotation
(SessionProperty) which injects my ShoppingCard from the my WebSession. I
think it could be useful in other arears as well where there is not the
same serialization problem as with spring beans or a better way than to
use an object locator - just less coupling.

Christian

___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: Re: [Wicket-user] My take on Spring integration

2005-11-09 Thread Igor Vaynberg

round 1 of refactoring is in. its much more elegant now. feedback please.

-Igor
On 11/8/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
thats pretty much exactly what i was thinking.
-Igor
On 11/8/05, Christian Essl [EMAIL PROTECTED]
wrote:
Very good. I am still playing around with the writeReplace thing.Regarding the refactoring what do you thing about this:Instead of the ISpringContextLocator have ainterface ObjectResolverFactory{

ObjectResolver getObjectResolver(Field field);}interface ObjectResolver{ Object resolve();}The (Spring)Initializer than calls for *each* field theObjectResolverFactory. If the ObjectResolverFactory thinks the field is
suitable for injection (ie has a SpringBean Annotation or JNDI Annotation)it returns an ObjectResolver otherwise null.And the code which creates the proxy could than beProxyCreator.create(Class proxyType, ObjectResolver res).
This would than make my wrapping context very simple.Thanks,ChristianOn Tue, 8 Nov 2005 13:45:31 -0800, Igor Vaynberg
[EMAIL PROTECTED]
wrote: ok, got the pure cglib solution working. just had to call enhancer.setInterfaces(new Class[] { Serializable.class}) to weave in the serializable interface. now it appears everything is working. sweet.
i am going to do a lot of refactoring today. maybe you can make your wrappingcontext use the same proxies as this thing so we can keep it all in one place. -Igor

On 11/8/05, Igor Vaynberg [EMAIL PROTECTED] wrote: I would rather weave it in using cglib and stay away from a
spring-specific proxy impl, becuase this thing can easily be
generalized to things beyound spring, like jndi lookups, etc. -Igor On 11/8/05, Christian Essl

[EMAIL PROTECTED] wrote: On Tue, 8 Nov 2005 11:59:22 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote:
Im still getting a class cast exception using cglib directly. im probably doing something dumb, you want to take a look? SpringInitializer

line 61 is commented out, thats where proxies are created for concrete objects. I think the problem is in the SpringLazyLookupInterceptor.intercept

() method you should at the end call proxy.invoke(target, args) instead of proxy.invokeSuper(). invokeSuper expects that the given argument is the enhanced instance.

You need it to call methods on the super (original) class. By the way, the spring one works fine IF the dependency implements

Serializable, because then the proxy itself becomes serializable since its a subclass. so im wondering if we can just weave in that interface
into
the created subclass and that will solve our problem. what do you think? That seems reasonable. I'll post a question on the spring list and see

what they say. Christian -Igor On 11/8/05, Christian Essl
[EMAIL PROTECTED] wrote: I do not know wheter read/writeObject is called on objects
referenced from
session attributes (full serialization closure). However the spec does not speak about writeReplace() and readResolve() so 'legaly' you should be on the right side if
you rely on these. Enclosed is some code which I guess does what is described on the cglib
howto page. I have not tested the code yet. I'll try to do so until tomorrow. Anyway is it so important to inject objects without interfaces?
Christian On Tue, 8 Nov 2005 09:07:24 -0800, Igor Vaynberg

[EMAIL PROTECTED] wrote: got the proxies for concrete objects working, but another dead endunfortunately. seems cglib proxies are not serializable objects.
intheirhowto they recommend overriding read/write resolve and reconstructing theproxy, but those are not guaranteed to be called when nonstandard
serialization is used. not sure where to go from here -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
--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. Downloadit 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

Re: Re: [Wicket-user] My take on Spring integration

2005-11-09 Thread Christian Essl

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



SerializableLazyProxyCreator.java
Description: Binary data


LazyInitProxy.java
Description: Binary data


ObjectResolver.java
Description: Binary data


SerializableLazyProxyCreatorTest.java
Description: Binary data

Re: AW: Re: [Wicket-user] My take on Spring integration

2005-11-09 Thread Alexandru Popescu



Looks like I've missed the part of where is this work available. Is it a way to 
access it?

./alex
--
.w( the_mindstorm )p.




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

Re: Re: [Wicket-user] My take on Spring integration

2005-11-09 Thread Christian Essl

It is in wicket-stuff under wicket-contrib-spring. And there in the 
wicket.contrib.spring.injection  package.


Christian

On Thu, 10 Nov 2005 00:07:44 +0200, Alexandru Popescu 
[EMAIL PROTECTED] wrote:




Looks like I've missed the part of where is this work available. Is it a 
way to access it?


./alex
--
.w( the_mindstorm )p.




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




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

Re: [Wicket-user] My take on Spring integration

2005-11-09 Thread Alexandru Popescu


#: Christian Essl changed the world a bit at a time by saying on  11/10/2005 
12:29 AM :#
It is in wicket-stuff under wicket-contrib-spring. And there in the 
wicket.contrib.spring.injection  package.


Christian



Thanks a lot Christian.

./alex
--
.w( the_mindstorm )p.

On Thu, 10 Nov 2005 00:07:44 +0200, Alexandru Popescu 
[EMAIL PROTECTED] wrote:




Looks like I've missed the part of where is this work available. Is it a 
way to access it?


./alex
--
.w( the_mindstorm )p.




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

Re: [Wicket-user] My take on Spring integration

2005-11-08 Thread Alexandru Popescu

Somewhere in this thread I think I have identified a suggestion that looked very much in the 
direction I would like to see it going. Unfortunately, right now I will need to pass through the 
thread again and identify it.


Probably the way I would go would be to define an annotation @SpringBean(lazy=true|false) that would 
be type level.


Than I would use a simple aspect that:
1/ in case of a @SpringBean(lazy=false) would work upon the constructor and inject everything 
required by the page/component (also using the field/setter level annotation)

2/ in case of a @SpringBean(lazy=true) would work on the getters to inject the 
dependency lazy.

The aspect would look quite simple as there is no complex thing to be done.

I think that as Igor is suggesting some proxy solution may work too. However I am not quite sure how 
the part of creating proxies would work as you don't really have an interface defined only for the 
SpringAware setters.


./alex
--
.w( the_mindstorm )p.

#: Igor Vaynberg changed the world a bit at a time by saying on  11/8/2005 
10:07 AM :#

heh
why do i only get to work on this stuff when i can barely keep my eyes open?

works great when i use a dynamic proxy - ie the dependency is an interface.
there is some class cast exception with cglib when the dependency is a
concrete class, maybe someone can take a look.

basically what this is does is this:
traverses the class hierarchy and looks for any fields that are annotated
with a SpringBean annotation, for any field it creates a proxy that will
load the dependency on first method invocation and sets the proxy as the
field value. the proxy does not replace the field value with the dependency
when its loaded, but instead forwards the invocations itself. this allows
the proxy to remain as the field value and be serialized and deserialized
instead of the dependency and thus solves the deserialization problem
because the proxy keeps enough information to be able to lookup the
dependency on its own.

this approach allows pages or components to carry spring references and
there is very low overhead because everything is lazy, and the hierarchy is
only traversed once.

right now the impl is jdk5 because that's the easiest, but this will work
just fine with jdk4, just need a way to store the metadata elsewhere - like
wicket metadata store in 1.2. it can also be easily extended to pull out
dependencies from places other then spring - the principle is the same.

the code (which needs to be refactored a lot) is in wicket-contrib-spring
project in wicket-stuff. see the wicket.contrib.spring.injection for code
and tests (examples :) )

this can work automatically for pages, just create a constructor like this:

SpringEnabledPage extends WebPage {
public SpringEnabledPage() {
super();
SpringInitailizer.initialize(this, getSpringContextLocator());
}
}

and then any page that extends the current page gets the proxies created
automatically

does this sound good to people and will any one actually use it? or is this
not ioc enough and i am just wasting my time?

Good night,
-Igor



On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:


or a JNDIAnnotation, anything is possible with this approach.

Let me try and get some of it going tonight and we can move from there.

-Igor


On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:

 I think there should be both of your implementations.

 IMO the constructor based impl should have the protected doInject
 method,
 because to me it seems to be the easiest way to inject manually services
 in the constructor without the need to manually proxy them.

 Yes with cglib we'll hit the final problem. I think - don't know - we'll
 need also a default constructor. Anyway spring runs into the same
 problem
 if it uses ie transaction proxies because spring does also use cglib for

 non interface based AOP. Maybe use spring AOP directly, which is well
 tested and performend.

 To me it would be fine to only use interfaces, because in the end those
 things are services I want to replace for mocking, remoting or
 whatsoever.
 So interfaces are a good (recomended) practice.

 By the way we could also create an EJBInjection annotation.

 Christian



 On Mon, 7 Nov 2005 16:22:02 -0800, Igor Vaynberg [EMAIL PROTECTED]
 
 wrote:

  but using that same idea, there is nothing stopping you from creating
 a
  subclass that calls the decorating factory from the constructor.
 
  So some of these init proxies are going to have to be cglib proxies?
 We
  can
  check if the field's type is an interface, and if so we can create a
  regular
  proxy, but if its not we try to create a cglib proxy? Do we hit the
 same
  final method drawbacks?
 
  -Igor
 
 
  On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
 
  That's right. That's propably the cleanest way and you can use it on
  each
  component.
 
  The problem why I came up with the constructor aproach initially was
  that
  generally all the subcomponents are created and setup in the

Re: Re: [Wicket-user] My take on Spring integration

Wow great job Igor. Thanks for doing it. I think that's the proper way to 
go.


Regarding cglib I think you should use spring AOP (it is already a 
dependency and generalization can wait a bit). Spring AOP handles all that 
and a bit more and is easy to use. Ie for cglib like in the current 
implementation you would also have to do something for serializing the 
proxy (http://cglib.sourceforge.net/howto.html) and maybe there are other 
things. With spring AOP:



final Class proxyClass = //class/interface needed to inject
ProxyFactory fact = new ProxyFactory();
fact.setTargetSource(new TargetSource(){
private transient _target;
public Class getTargetClass(){return proxyClass;}
public boolean isStatic(){return false;}
public Object getTarget() throws Exception
{
   if(_target == null)
_target = loadTheTarget();
   return _target;
}
public void releaseTarget(Object arg0) throws Exception{}
});

if(!proxyClass.isInterface())
   fact.setProxyTargetClass(true); //will use cglib

Object proxy = fact.getProxy();
//inject the proxy (done)

Just of my head two further suggestions:
1.) If a field is not null than do not inject anything. This way custom 
injections could be done
2.) If a Compnoent implements Initializable than call init(). So setter 
injection can be done and the componetn can do its full setup in the init 
method - basically like in the constructor.


What I'm working on now is an ApplicationContext which wrapps the 'real' 
ApplicationContext and does create for getBean() etc automatically the 
proxies. I think this way I'll never have to worry about the serialization 
problem for such beans.


Christian




On Tue, 8 Nov 2005 00:07:30 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



heh
why do i only get to work on this stuff when i can barely keep my eyes 
open?


works great when i use a dynamic proxy - ie the dependency is an 
interface.

there is some class cast exception with cglib when the dependency is a
concrete class, maybe someone can take a look.

basically what this is does is this:
traverses the class hierarchy and looks for any fields that are annotated
with a SpringBean annotation, for any field it creates a proxy that will
load the dependency on first method invocation and sets the proxy as the
field value. the proxy does not replace the field value with the 
dependency

when its loaded, but instead forwards the invocations itself. this allows
the proxy to remain as the field value and be serialized and deserialized
instead of the dependency and thus solves the deserialization problem
because the proxy keeps enough information to be able to lookup the
dependency on its own.

this approach allows pages or components to carry spring references and
there is very low overhead because everything is lazy, and the hierarchy 
is

only traversed once.

right now the impl is jdk5 because that's the easiest, but this will work
just fine with jdk4, just need a way to store the metadata elsewhere - 
like

wicket metadata store in 1.2. it can also be easily extended to pull out
dependencies from places other then spring - the principle is the same.

the code (which needs to be refactored a lot) is in wicket-contrib-spring
project in wicket-stuff. see the wicket.contrib.spring.injection for code
and tests (examples :) )

this can work automatically for pages, just create a constructor like 
this:


SpringEnabledPage extends WebPage {
public SpringEnabledPage() {
super();
SpringInitailizer.initialize(this, getSpringContextLocator());
}
}

and then any page that extends the current page gets the proxies created
automatically

does this sound good to people and will any one actually use it? or is 
this

not ioc enough and i am just wasting my time?

Good night,
-Igor



On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:


or a JNDIAnnotation, anything is possible with this approach.

Let me try and get some of it going tonight and we can move from there.

-Igor


On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:

 I think there should be both of your implementations.

 IMO the constructor based impl should have the protected doInject
 method,
 because to me it seems to be the easiest way to inject manually 
services

 in the constructor without the need to manually proxy them.

 Yes with cglib we'll hit the final problem. I think - don't know - 
we'll

 need also a default constructor. Anyway spring runs into the same
 problem
 if it uses ie transaction proxies because spring does also use cglib 
for


 non interface based AOP. Maybe use spring AOP directly, which is well
 tested and performend.

 To me it would be fine to only use interfaces, because in the end 
those

 things are services I want to replace for mocking, remoting or
 whatsoever.
 So interfaces are a good (recomended) practice.

 By the way we could also create an EJBInjection annotation.

 Christian



 On Mon, 7 Nov 2005 16:22:02 -0800, Igor Vaynberg 
[EMAIL PROTECTED]

 
 wrote:

Re: Re: [Wicket-user] My take on Spring integration


Yes you are right!

I was now more thinking of Igors proposal todo the 'injection' from the 
outside:


MyComponent comp = new MyComponent(id);
//set this and that
SpringInitializer.initialize(comp,locator);

If you'd do it from the inside (as the original code) it is a different 
story.


I don't know what is better. What do you think?

Christian


On Tue, 8 Nov 2005 16:36:51 +0100, Johan Compagner [EMAIL PROTECTED] 
wrote:



Just of my head two further suggestions:
1.) If a field is not null than do not inject anything. This way custom
injections could be done




Fields are always null because they are not initialized yet by the sub 
class


(when having a super class that does the injections)




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

Re: Re: [Wicket-user] My take on Spring integration

What I'm working on now is an ApplicationContext which wrapps the 'real'ApplicationContext and does create for getBean() etc automatically the
proxies. I think this way I'll never have to worry about the serializationproblem for such beans.
but what will inject your pages?

-Igor

Re: Re: [Wicket-user] My take on Spring integration


It is more for components:
//constructor
public OrderPage(){
 add(new 
CustomerPanel(customer,getWrappingContext().getBean(customerDAO,CustomerDAO.class));

}

Just for normal DI in code.

Christian

On Tue, 8 Nov 2005 08:31:47 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:




What I'm working on now is an ApplicationContext which wrapps the 'real'
ApplicationContext and does create for getBean() etc automatically the
proxies. I think this way I'll never have to worry about the 
serialization

problem for such beans.



but what will inject your pages?

-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

Re: Re: [Wicket-user] My take on Spring integration

Im still getting a class cast exception using cglib directly. im
probably doing something dumb, you want to take a look?
SpringInitializer line 61 is commented out, thats where proxies are
created for concrete objects.

By the way, the spring one works fine IF the dependency implements
Serializable, because then the proxy itself becomes serializable since
its a subclass. so im wondering if we can just weave in that interface
into the created subclass and that will solve our problem. what do you
think?

-Igor
On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote:
I do not know wheter read/writeObject is called on objects referenced fromsession attributes (full serialization closure). However the spec doesnot speak about writeReplace()and readResolve() so 'legaly' you should be on the right side if you rely
on these.Enclosed is some code which I guess does what is described on the cglibhowto page. I have not tested the code yet. I'll try to do so untiltomorrow.Anyway is it so important to inject objects without interfaces?
ChristianOn Tue, 8 Nov 2005 09:07:24 -0800, Igor Vaynberg [EMAIL PROTECTED]wrote: got the proxies for concrete objects working, but another dead end
 unfortunately. seems cglib proxies are not serializable objects. in their howto they recommend overriding read/write resolve and reconstructing the proxy, but those are not guaranteed to be called when nonstandard
 serialization is used. not sure where to go from here -Igor

Re: Re: [Wicket-user] My take on Spring integration

On Tue, 8 Nov 2005 11:59:22 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



Im still getting a class cast exception using cglib directly. im probably
doing something dumb, you want to take a look? SpringInitializer line 61 
is

commented out, thats where proxies are created for concrete objects.


I think the problem is in the SpringLazyLookupInterceptor.intercept() 
method you should at the
end call proxy.invoke(target, args) instead of proxy.invokeSuper(). 
invokeSuper expects that the given argument is the enhanced instance. You 
need it to call methods on the super (original) class.




By the way, the spring one works fine IF the dependency implements
Serializable, because then the proxy itself becomes serializable since 
its a

subclass. so im wondering if we can just weave in that interface into the
created subclass and that will solve our problem. what do you think?


That seems reasonable. I'll post a question on the spring list and see 
what they say.


Christian



-Igor


On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote:


I do not know wheter read/writeObject is called on objects referenced 
from

session attributes (full serialization closure). However the spec does
not speak about writeReplace()
and readResolve() so 'legaly' you should be on the right side if you 
rely

on these.

Enclosed is some code which I guess does what is described on the cglib
howto page. I have not tested the code yet. I'll try to do so until
tomorrow.

Anyway is it so important to inject objects without interfaces?

Christian

On Tue, 8 Nov 2005 09:07:24 -0800, Igor Vaynberg 
[EMAIL PROTECTED]

wrote:

 got the proxies for concrete objects working, but another dead end
 unfortunately. seems cglib proxies are not serializable objects. in
their
 howto they recommend overriding read/write resolve and reconstructing
the
 proxy, but those are not guaranteed to be called when nonstandard
 serialization is used. not sure where to go from here

 -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

Re: Re: [Wicket-user] My take on Spring integration

I would rather weave it in using cglib and stay away from a
spring-specific proxy impl, becuase this thing can easily be
generalized to things beyound spring, like jndi lookups, etc.

-Igor
On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote:
On Tue, 8 Nov 2005 11:59:22 -0800, Igor Vaynberg [EMAIL PROTECTED]wrote: Im still getting a class cast exception using cglib directly. im probably
doing something dumb, you want to take a look? SpringInitializer line 61 is commented out, thats where proxies are created for concrete objects.I think the problem is in the SpringLazyLookupInterceptor.intercept
()method you should at theend call proxy.invoke(target, args) instead of proxy.invokeSuper().invokeSuper expects that the given argument is the enhanced instance. Youneed it to call methods on the super (original) class.
By the way, the spring one works fine IF the dependency implements Serializable, because then the proxy itself becomes serializable since its a subclass. so im wondering if we can just weave in that interface into the
created subclass and that will solve our problem. what do you think?That seems reasonable. I'll post a question on the spring list and seewhat they say.Christian -Igor
On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote: I do not know wheter read/writeObject is called on objects referenced
from session attributes (full serialization closure). However the spec does not speak about writeReplace() and readResolve() so 'legaly' you should be on the right side if you
rely on these. Enclosed is some code which I guess does what is described on the cglib howto page. I have not tested the code yet. I'll try to do so until tomorrow.
Anyway is it so important to inject objects without interfaces? Christian On Tue, 8 Nov 2005 09:07:24 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote: got the proxies for concrete objects working, but another dead end unfortunately. seems cglib proxies are not serializable objects. in
their howto they recommend overriding read/write resolve and reconstructing the proxy, but those are not guaranteed to be called when nonstandard serialization is used. not sure where to go from here
-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. Downloadit for free - -and be entered to win a 42 plasma tv or your very ownSony(tm)PSP.Click here to play:
http://sourceforge.net/geronimo.php___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: Re: [Wicket-user] My take on Spring integration

ok, got the pure cglib solution working.
just had to call enhancer.setInterfaces(new Class[] { Serializable.class}) to weave in the serializable interface.

now it appears everything is working. sweet.
i am going to do a lot of refactoring today. maybe you can make your
wrappingcontext use the same proxies as this thing so we can keep it
all in one place.

-Igor
On 11/8/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
I would rather weave it in using cglib and stay away from a
spring-specific proxy impl, becuase this thing can easily be
generalized to things beyound spring, like jndi lookups, etc.

()method you should at theend call proxy.invoke(target, args) instead of proxy.invokeSuper().invokeSuper expects that the given argument is the enhanced instance. Youneed it to call methods on the super (original) class.
By the way, the spring one works fine IF the dependency implements Serializable, because then the proxy itself becomes serializable since its a subclass. so im wondering if we can just weave in that interface into the
created subclass and that will solve our problem. what do you think?That seems reasonable. I'll post a question on the spring list and seewhat they say.Christian -Igor

On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote: I do not know wheter read/writeObject is called on objects referenced

from session attributes (full serialization closure). However the spec does not speak about writeReplace() and readResolve() so 'legaly' you should be on the right side if you
rely on these. Enclosed is some code which I guess does what is described on the cglib howto page. I have not tested the code yet. I'll try to do so until tomorrow.
Anyway is it so important to inject objects without interfaces? Christian On Tue, 8 Nov 2005 09:07:24 -0800, Igor Vaynberg

[EMAIL PROTECTED] wrote: got the proxies for concrete objects working, but another dead end unfortunately. seems cglib proxies are not serializable objects. in
their howto they recommend overriding read/write resolve and reconstructing the proxy, but those are not guaranteed to be called when nonstandard serialization is used. not sure where to go from here
-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. Downloadit for free - -and be entered to win a 42 plasma tv or your very ownSony(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

Re: Re: [Wicket-user] My take on Spring integration

Very good. I am still playing around with the writeReplace thing.

Regarding the refactoring what do you thing about this:

Instead of the ISpringContextLocator have a

interface ObjectResolverFactory{
ObjectResolver getObjectResolver(Field field);
}

interface ObjectResolver{
Object resolve();
}

The (Spring)Initializer than calls for *each* field the
ObjectResolverFactory. If the ObjectResolverFactory thinks the field is
suitable for injection (ie has a SpringBean Annotation or JNDI Annotation)
it returns an ObjectResolver otherwise null.

And the code which creates the proxy could than be
ProxyCreator.create(Class proxyType, ObjectResolver res).

This would than make my wrapping context very simple.

Thanks,
Christian

On Tue, 8 Nov 2005 13:45:31 -0800, Igor Vaynberg [EMAIL PROTECTED]
wrote:

ok, got the pure cglib solution working.
just had to call enhancer.setInterfaces(new Class[]
{ Serializable.class})

to weave in the serializable interface.

now it appears everything is working. sweet.
i am going to do a lot of refactoring today. maybe you can make your
wrappingcontext use the same proxies as this thing so we can keep it all
in

one place.

-Igor

On 11/8/05, Igor Vaynberg [EMAIL PROTECTED] wrote:

I would rather weave it in using cglib and stay away from a
spring-specific proxy impl, becuase this thing can easily be
generalized to

things beyound spring, like jndi lookups, etc.

-Igor

On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote:

On Tue, 8 Nov 2005 11:59:22 -0800, Igor Vaynberg
[EMAIL PROTECTED]
wrote:

Im still getting a class cast exception using cglib directly. im
probably
doing something dumb, you want to take a look? SpringInitializer
line

61
is
commented out, thats where proxies are created for concrete objects.

I think the problem is in the SpringLazyLookupInterceptor.intercept ()
method you should at the
end call proxy.invoke(target, args) instead of proxy.invokeSuper().
invokeSuper expects that the given argument is the enhanced instance.
You
need it to call methods on the super (original) class.

By the way, the spring one works fine IF the dependency implements
Serializable, because then the proxy itself becomes serializable
since

its a
subclass. so im wondering if we can just weave in that interface
into

the
created subclass and that will solve our problem. what do you think?

That seems reasonable. I'll post a question on the spring list and see
what they say.

Christian

-Igor

On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote:

I do not know wheter read/writeObject is called on objects
referenced

from
session attributes (full serialization closure). However the spec
does
not speak about writeReplace()
and readResolve() so 'legaly' you should be on the right side if
you

rely
on these.

Enclosed is some code which I guess does what is described on the
cglib
howto page. I have not tested the code yet. I'll try to do so until
tomorrow.

Anyway is it so important to inject objects without interfaces?

Christian

On Tue, 8 Nov 2005 09:07:24 -0800, Igor Vaynberg
[EMAIL PROTECTED]
wrote:

got the proxies for concrete objects working, but another dead
end
unfortunately. seems cglib proxies are not serializable objects.
in

their
howto they recommend overriding read/write resolve and
reconstructing
the
proxy, but those are not guaranteed to be called when nonstandard
serialization is used. not sure where to go from here

-Igor

--
Christian Essl

___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
anmelden: http://mail.yahoo.de

--
Christian Essl

___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: Re: [Wicket-user] My take on Spring integration

thats pretty much exactly what i was thinking.
-Igor
On 11/8/05, Christian Essl [EMAIL PROTECTED] wrote:
Very good. I am still playing around with the writeReplace thing.Regarding the refactoring what do you thing about this:Instead of the ISpringContextLocator have ainterface ObjectResolverFactory{
ObjectResolver getObjectResolver(Field field);}interface ObjectResolver{ Object resolve();}The (Spring)Initializer than calls for *each* field theObjectResolverFactory. If the ObjectResolverFactory thinks the field is
suitable for injection (ie has a SpringBean Annotation or JNDI Annotation)it returns an ObjectResolver otherwise null.And the code which creates the proxy could than beProxyCreator.create(Class proxyType, ObjectResolver res).
This would than make my wrapping context very simple.Thanks,ChristianOn Tue, 8 Nov 2005 13:45:31 -0800, Igor Vaynberg [EMAIL PROTECTED]
wrote: ok, got the pure cglib solution working. just had to call enhancer.setInterfaces(new Class[] { Serializable.class}) to weave in the serializable interface. now it appears everything is working. sweet.
i am going to do a lot of refactoring today. maybe you can make your wrappingcontext use the same proxies as this thing so we can keep it all in one place. -Igor
On 11/8/05, Igor Vaynberg [EMAIL PROTECTED] wrote: I would rather weave it in using cglib and stay away from a spring-specific proxy impl, becuase this thing can easily be
generalized to things beyound spring, like jndi lookups, etc. -Igor On 11/8/05, Christian Essl
[EMAIL PROTECTED] wrote: On Tue, 8 Nov 2005 11:59:22 -0800, Igor Vaynberg [EMAIL PROTECTED] wrote:
Im still getting a class cast exception using cglib directly. im probably doing something dumb, you want to take a look? SpringInitializer
line 61 is commented out, thats where proxies are created for concrete objects. I think the problem is in the SpringLazyLookupInterceptor.intercept
() method you should at the end call proxy.invoke(target, args) instead of proxy.invokeSuper(). invokeSuper expects that the given argument is the enhanced instance.
You need it to call methods on the super (original) class. By the way, the spring one works fine IF the dependency implements
Serializable, because then the proxy itself becomes serializable since its a subclass. so im wondering if we can just weave in that interface into
the created subclass and that will solve our problem. what do you think? That seems reasonable. I'll post a question on the spring list and see
what they say. Christian -Igor On 11/8/05, Christian Essl
[EMAIL PROTECTED] wrote: I do not know wheter read/writeObject is called on objects referenced from
session attributes (full serialization closure). However the spec does not speak about writeReplace() and readResolve() so 'legaly' you should be on the right side if
you rely on these. Enclosed is some code which I guess does what is described on the cglib
howto page. I have not tested the code yet. I'll try to do so until tomorrow. Anyway is it so important to inject objects without interfaces?
Christian On Tue, 8 Nov 2005 09:07:24 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote: got the proxies for concrete objects working, but another dead endunfortunately. seems cglib proxies are not serializable objects.
intheirhowto they recommend overriding read/write resolve and reconstructing theproxy, but those are not guaranteed to be called when nonstandard
serialization is used. not sure where to go from here -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 --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. Downloadit 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.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

AW: Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread sven

IMHO pages are standing on the borderline between a stateful GUI and the rest 
of the application in form of stateless services. 
DI should be done by the IoC container, creating the pages can better be done 
the standard Wicket way (e.g. with PageParameters).

As described before I'm using a custom page factory that cooperates with a 
wrapped page factory and the containing bean factory:

public class SpringInjectingPageFactory implements IPageFactory, 
BeanFactoryAware {

 private AutowireCapableBeanFactory beanFactory;
 private IPageFactory pageFactory;

 public void setPageFactory(IPageFactory pageFactory) {
  this.pageFactory = pageFactory;
 }

 public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
  this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
 }

 public Page newPage(Class pageClass) {
  Page page = this.pageFactory.newPage(pageClass);

  injectDependencies(page, pageClass.getName());

  return page;
 }

 public Page newPage(Class pageClass, PageParameters parameters) {
  Page page = this.pageFactory.newPage(pageClass, parameters);

  injectDependencies(page, pageClass.getName());

  return page;
 }

 private void injectDependencies(Page page, String beanName) {
  if (this.beanFactory.containsBean(beanName)) {
this.beanFactory.applyBeanPropertyValues(page, beanName);
  }
 }
}

Note that if you don't specify a name or id attribute for beans, they will be 
registered under their classname in Spring.
And NO, I don't use autowiring: applyBeanPropertyValues() does not autowire 
although it is located in AutowireCapableBeanFactory.

Sven

you are right, this is not ioc. but are pages/components managed by an ioc
container?
-Igor


On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:

 #: Igor Vaynberg changed the world a bit at a time by saying on 11/6/2005
 7:06 PM :#
  Or how about a simple solution:
 
  public MyApplication extends WebApplication {
  public Object lookup(String name) {
  Object=...do a lookup from somewhere like spring context or app
 object...;
  return object;
  }
  }
 
  public MyPage extends Page {
  public transient SomeService service;
 
  public SomeService getService() {
  if (service==null) {
  service=getApplication().lookup(SomeService.class.getName());
  }
  return service;
  }
 
  I know its not quiete as elegant as ioc but it has none of the
 performance
  hits an automatic injection would cause if it would be done on
  deserialization of every component. Also its a lazy lookup so you dont
 do it
  until its needed, and its only done once per page (until it gets
  deserialized).
 
  -Igor
 

 But this was exactly what I was suggesting to avoid ;-). Lookups and
 factories are not ioc/di.

 ./alex
 --
 .w( the_mindstorm )p.



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

Re: Re: [Wicket-user] My take on Spring integration

and you have to have the pages defined as beans in the application context? with their properties specified?

-Igor
On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
but how does the above handle deserealization of pages? there is nothing to reinject the dependencies.

-Igor
On 11/7/05, [EMAIL PROTECTED] 
[EMAIL PROTECTED] wrote:
IMHO pages are standing on the borderline between a stateful GUI and the rest of the application in form of stateless services.DI
should be done by the IoC container, creating the pages can better be
done the standard Wicket way (e.g. with PageParameters).As described before I'm using a custom page factory that cooperates with a wrapped page factory and the containing bean factory:public class SpringInjectingPageFactory implements IPageFactory, BeanFactoryAware {
 private AutowireCapableBeanFactory beanFactory; private IPageFactory pageFactory; public void setPageFactory(IPageFactory pageFactory) {this.pageFactory = pageFactory; } public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
this.beanFactory = (AutowireCapableBeanFactory)beanFactory; } public Page newPage(Class pageClass) {Page page = this.pageFactory.newPage(pageClass);injectDependencies(page, pageClass.getName

());return page; } public Page newPage(Class pageClass, PageParameters parameters) {Page page = this.pageFactory.newPage(pageClass, parameters);injectDependencies(page, pageClass.getName

());return page; } private void injectDependencies(Page page, String beanName) {if (this.beanFactory.containsBean(beanName)) {this.beanFactory.applyBeanPropertyValues(page, beanName);

} }}Note that if you don't specify a name or id attribute for beans, they will be registered under their classname in Spring.And
NO, I don't use autowiring: applyBeanPropertyValues() does not autowire
although it is located in AutowireCapableBeanFactory.Svenyou are right, this is not ioc. but are pages/components managed by an ioccontainer?-IgorOn 11/6/05, Alexandru Popescu 
[EMAIL PROTECTED] wrote: #: Igor Vaynberg changed the world a bit at a time by saying on 11/6/2005
 7:06 PM :#
  Or how about a simple solution:   public MyApplication extends WebApplication {  public Object lookup(String name) {  Object=...do a lookup from somewhere like spring context or app
 object...;  return object;  }  }   public MyPage extends Page {  public transient SomeService service; 
  public SomeService getService() {  if (service==null) {  service=getApplication().lookup(SomeService.class.getName());  }  return service;

  }   I know its not quiete as elegant as ioc but it has none of the performance  hits an automatic injection would cause if it would be done on
  deserialization of every component. Also its a lazy lookup so you dont
 do it  until its needed, and its only done once per page (until it gets  deserialized).   -Igor  But this was exactly what I was suggesting to avoid ;-). Lookups and
 factories are not ioc/di. ./alex -- .w( the_mindstorm )p. ---
 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. Downloadit 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.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

Re: Re: [Wicket-user] My take on Spring integration

but how does the above handle deserealization of pages? there is nothing to reinject the dependencies.

-Igor
On 11/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
IMHO pages are standing on the borderline between a stateful GUI and the rest of the application in form of stateless services.DI
should be done by the IoC container, creating the pages can better be
done the standard Wicket way (e.g. with PageParameters).As described before I'm using a custom page factory that cooperates with a wrapped page factory and the containing bean factory:public class SpringInjectingPageFactory implements IPageFactory, BeanFactoryAware {
 private AutowireCapableBeanFactory beanFactory; private IPageFactory pageFactory; public void setPageFactory(IPageFactory pageFactory) {this.pageFactory = pageFactory; } public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
this.beanFactory = (AutowireCapableBeanFactory)beanFactory; } public Page newPage(Class pageClass) {Page page = this.pageFactory.newPage(pageClass);injectDependencies(page, pageClass.getName
());return page; } public Page newPage(Class pageClass, PageParameters parameters) {Page page = this.pageFactory.newPage(pageClass, parameters);injectDependencies(page, pageClass.getName
());return page; } private void injectDependencies(Page page, String beanName) {if (this.beanFactory.containsBean(beanName)) {this.beanFactory.applyBeanPropertyValues(page, beanName);
} }}Note that if you don't specify a name or id attribute for beans, they will be registered under their classname in Spring.And
NO, I don't use autowiring: applyBeanPropertyValues() does not autowire
although it is located in AutowireCapableBeanFactory.Svenyou are right, this is not ioc. but are pages/components managed by an ioccontainer?-IgorOn 11/6/05, Alexandru Popescu 
[EMAIL PROTECTED] wrote: #: Igor Vaynberg changed the world a bit at a time by saying on 11/6/2005 7:06 PM :#
  Or how about a simple solution:   public MyApplication extends WebApplication {  public Object lookup(String name) {  Object=...do a lookup from somewhere like spring context or app
 object...;  return object;  }  }   public MyPage extends Page {  public transient SomeService service; 
  public SomeService getService() {  if (service==null) {  service=getApplication().lookup(SomeService.class.getName());  }  return service;
  }   I know its not quiete as elegant as ioc but it has none of the performance  hits an automatic injection would cause if it would be done on  deserialization of every component. Also its a lazy lookup so you dont
 do it  until its needed, and its only done once per page (until it gets  deserialized).   -Igor  But this was exactly what I was suggesting to avoid ;-). Lookups and
 factories are not ioc/di. ./alex -- .w( the_mindstorm )p. ---
 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. Downloadit 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.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread Eduardo Rocha

2005/11/6, Eelco Hillenius [EMAIL PROTECTED]:
 I see absolutely nothing wrong with lookups at that level. It's less
 code than you would need for any component configuration and it's more
 efficient too. And there are just no disadvantages, are there?


The Application class have references to all of the beans needed,
while it never uses them. With a big application, there could be
several of beans there, and get pretty messy. One could use instead
many ServiceLocators (not being the Application class), grouping
similar beans together to aliviate this problem (of course if it is
ever considered a problem :)).

And at the end of the day, the page is always referencing a class for
lookup. I don't think it is a problem, and has the advantage of lazy
loading, as Igor frequently talks about, but IoC is simply better,
more elegant. If you can use it, there is no reason for a lookup, the
code gets simpler. When you are testing a page, you set the dependency
in the page, you do not need to set the dependency in the locator.



 And... for this whole discussion: if you like one approach... go
 implement it now! Create your own component factory, annotations
 processor, aop, and please contribute when you've got something nice
 working. Or let us know when you need specific changes to Wicket to
 support your needs. We'll most probably honor such requests if they
 are reasonable as we've done in the past.

 Eelco


 On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
  #: Igor Vaynberg changed the world a bit at a time by saying on  11/6/2005 
  7:06 PM :#
   Or how about a simple solution:
  
   public MyApplication extends WebApplication {
   public Object lookup(String name) {
   Object=...do a lookup from somewhere like spring context or app object...;
   return object;
   }
   }
  
   public MyPage extends Page {
   public transient SomeService service;
  
   public SomeService getService() {
   if (service==null) {
   service=getApplication().lookup(SomeService.class.getName());
   }
   return service;
   }
  
   I know its not quiete as elegant as ioc but it has none of the performance
   hits an automatic injection would cause if it would be done on
   deserialization of every component. Also its a lazy lookup so you dont do 
   it
   until its needed, and its only done once per page (until it gets
   deserialized).
  
   -Igor
  
 
  But this was exactly what I was suggesting to avoid ;-). Lookups and 
  factories are not ioc/di.
 
  ./alex
  --
  .w( the_mindstorm )p.
 
 
 
  ---
  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



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

Re: Re: [Wicket-user] My take on Spring integration


Hi Igor,

I looked through your code. Thanks for implementing it. I am not sure 
wheter readObject() is the right place to do the (re)injection. According 
to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be 
called on session-attributes. (Instead  session attributes which implement 
HttpSessionActiviationListeners are informed on deserialization). Even if 
readObject is called I am not sure wheter there is an ApplicationContext 
to get to the BeanContext.


I don't know wheter wicket has a mean to propogate these HttpSessionEvents 
on deserialization or a similar callback? If so I guess you could do the 
(re)injection there.


Christian

On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



here is something i threw together that solves the deserialization and
ability to use the new operator to create pages. atleast i think it
doesits really late here and all i really know so far is that it
compiles :)

the idea is pretty simple, do the injection in the default constructor, 
and

then do it anytime the object is deserialized. you use a @SpringBean
annotation to denote the dependency. it can either be used on a field or 
on
a setter. If you specify the bean name it will be used to find the bean, 
if
you dont then the field's type or the setters argument type will be used 
for

the lookup.

-Igor


On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:


and you have to have the pages defined as beans in the application
context? with their properties specified?

-Igor


On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:

 but how does the above handle deserealization of pages? there is 
nothing

 to reinject the dependencies.

 -Igor


 On 11/7/05, [EMAIL PROTECTED]  [EMAIL PROTECTED] wrote:
 
  IMHO pages are standing on the borderline between a stateful GUI and
  the rest of the application in form of stateless services.
  DI should be done by the IoC container, creating the pages can 
better

  be done the standard Wicket way (e.g. with PageParameters).
 
  As described before I'm using a custom page factory that cooperates
  with a wrapped page factory and the containing bean factory:
 
  public class SpringInjectingPageFactory implements IPageFactory,
  BeanFactoryAware {
 
  private AutowireCapableBeanFactory beanFactory;
  private IPageFactory pageFactory;
 
  public void setPageFactory(IPageFactory pageFactory) {
  this.pageFactory = pageFactory;
  }
 
  public void setBeanFactory(BeanFactory beanFactory) throws
  BeansException {
  this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
  }
 
  public Page newPage(Class pageClass) {
  Page page = this.pageFactory.newPage(pageClass);
 
  injectDependencies(page, pageClass.getName ());
 
  return page;
  }
 
  public Page newPage(Class pageClass, PageParameters parameters) {
  Page page = this.pageFactory.newPage(pageClass, parameters);
 
  injectDependencies(page, pageClass.getName ());
 
  return page;
  }
 
  private void injectDependencies(Page page, String beanName) {
  if (this.beanFactory.containsBean(beanName)) {
  this.beanFactory.applyBeanPropertyValues(page, beanName);
  }
  }
  }
 
  Note that if you don't specify a name or id attribute for beans, 
they

  will be registered under their classname in Spring.
  And NO, I don't use autowiring: applyBeanPropertyValues() does not
  autowire although it is located in AutowireCapableBeanFactory.
 
  Sven
 
  you are right, this is not ioc. but are pages/components managed by
  an ioc
  container?
  -Igor
  
  
  On 11/6/05, Alexandru Popescu  
[EMAIL PROTECTED]

  wrote:
  
   #: Igor Vaynberg changed the world a bit at a time by saying on
  11/6/2005
   7:06 PM :#
Or how about a simple solution:
   
public MyApplication extends WebApplication {
public Object lookup(String name) {
Object=...do a lookup from somewhere like spring context or app
   object...;
return object;
}
}
   
public MyPage extends Page {
public transient SomeService service;
   
public SomeService getService() {
if (service==null) {
service=getApplication().lookup(SomeService.class.getName());
}
return service;
}
   
I know its not quiete as elegant as ioc but it has none of the
   performance
hits an automatic injection would cause if it would be done on
deserialization of every component. Also its a lazy lookup so 
you

  dont
   do it
until its needed, and its only done once per page (until it 
gets

deserialized).
   
-Igor
   
  
   But this was exactly what I was suggesting to avoid ;-). Lookups
  and
   factories are not ioc/di.
  
   ./alex
   --
   .w( the_mindstorm )p.
  
  
  
   ---
   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:

Re: Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread Johan Compagner

And there is also a thing like XML Serialization
Which also doesn't use the java read/write object at all.
On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
Hi Igor,I looked through your code. Thanks for implementing it. I am not surewheter readObject() is the right place to do the (re)injection. Accordingto the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be
called on session-attributes. (Insteadsession attributes which implementHttpSessionActiviationListeners are informed on deserialization). Even ifreadObject is called I am not sure wheter there is an ApplicationContext
to get to the BeanContext.I don't know wheter wicket has a mean to propogate these HttpSessionEventson deserialization or a similar callback? If so I guess you could do the(re)injection there.Christian
On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg [EMAIL PROTECTED]wrote: here is something i threw together that solves the deserialization and
 ability to use the new operator to create pages. atleast i think it doesits really late here and all i really know so far is that it compiles :) the idea is pretty simple, do the injection in the default constructor,
 and then do it anytime the object is deserialized. you use a @SpringBean annotation to denote the dependency. it can either be used on a field or on a setter. If you specify the bean name it will be used to find the bean,
 if you dont then the field's type or the setters argument type will be used for the lookup. -Igor On 11/7/05, Igor Vaynberg 
[EMAIL PROTECTED] wrote: and you have to have the pages defined as beans in the application context? with their properties specified? -Igor
 On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:   but how does the above handle deserealization of pages? there is
 nothing  to reinject the dependencies.   -IgorOn 11/7/05, [EMAIL PROTECTED]
  [EMAIL PROTECTED] wrote: IMHO pages are standing on the borderline between a stateful GUI and   the rest of the application in form of stateless services.
   DI should be done by the IoC container, creating the pages can better   be done the standard Wicket way (e.g. with PageParameters). As described before I'm using a custom page factory that cooperates
   with a wrapped page factory and the containing bean factory: public class SpringInjectingPageFactory implements IPageFactory,   BeanFactoryAware {
 private AutowireCapableBeanFactory beanFactory;   private IPageFactory pageFactory; public void setPageFactory(IPageFactory pageFactory) {
   this.pageFactory = pageFactory;   } public void setBeanFactory(BeanFactory beanFactory) throws   BeansException {
   this.beanFactory = (AutowireCapableBeanFactory)beanFactory;   } public Page newPage(Class pageClass) {   Page page = this.pageFactory.newPage
(pageClass); injectDependencies(page, pageClass.getName ()); return page;   } public Page newPage(Class pageClass, PageParameters parameters) {
   Page page = this.pageFactory.newPage(pageClass, parameters); injectDependencies(page, pageClass.getName ()); return page;
   } private void injectDependencies(Page page, String beanName) {   if (this.beanFactory.containsBean(beanName)) {   
this.beanFactory.applyBeanPropertyValues(page, beanName);   }   }   } Note that if you don't specify a name or id attribute for beans,
 they   will be registered under their classname in Spring.   And NO, I don't use autowiring: applyBeanPropertyValues() does not   autowire although it is located in AutowireCapableBeanFactory.
 Sven you are right, this is not ioc. but are pages/components managed by   an ioc   container?
   -Igor On 11/6/05, Alexandru Popescu  [EMAIL PROTECTED]
   wrote:   #: Igor Vaynberg changed the world a bit at a time by saying on   11/6/20057:06 PM :#
 Or how about a simple solution: public MyApplication extends WebApplication { public Object lookup(String name) {
 Object=...do a lookup from somewhere like spring context or appobject...; return object; }
 } public MyPage extends Page { public transient SomeService service;
 public SomeService getService() { if (service==null) { service=getApplication().lookup(SomeService.class.getName
()); } return service; } I know its not quiete as elegant as ioc but it has none of the
performance hits an automatic injection would cause if it would be done on deserialization of every component. Also its a lazy lookup so
 you   dontdo it until its needed, and its only done once per page (until it gets deserialized).
 -Igor   But this was exactly what I was suggesting to avoid ;-). Lookups
   andfactories are not ioc/di.   ./alex--.w( the_mindstorm )p.
 ---SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.Downloadit

AW: Re: Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread sven

and you have to have the pages defined as beans in the application context? 
with their properties specified?

Yes, I configure most wicket stuff in a separate context, which is bootstrapped 
by a custom application factory:

bean class=XYPage singleton=false
property name=service ref=AService/
/bean

but how does the above handle deserealization of pages?
there is nothing to reinject the dependencies.

Yep, I'm still looking for the hook in Wicket ;).

Sven

On 11/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:IMHO pages are standing 
on the borderline between a stateful GUI and the rest of the application in 
form of stateless services.
DIshould be done by the IoC container, creating the pages can better bedone the 
standard Wicket way (e.g. with PageParameters).

As described before I'm using a custom page factory that cooperates with a 
wrapped page factory and the containing bean factory:

public class SpringInjectingPageFactory implements IPageFactory, 
BeanFactoryAware {

 private AutowireCapableBeanFactory beanFactory;
 private IPageFactory pageFactory;

 public void setPageFactory(IPageFactory pageFactory) {
  this.pageFactory = pageFactory;
 }

 public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
  this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
 }

 public Page newPage(Class pageClass) {
  Page page = this.pageFactory.newPage(pageClass);

  injectDependencies(page, pageClass.getName());

  return page;
 }

 public Page newPage(Class pageClass, PageParameters parameters) {
  Page page = this.pageFactory.newPage(pageClass, parameters);

  injectDependencies(page, pageClass.getName());

  return page;
 }

 private void injectDependencies(Page page, String beanName) {
  if (this.beanFactory.containsBean(beanName)) {
this.beanFactory.applyBeanPropertyValues(page, beanName);
  }
 }
}

Note that if you don't specify a name or id attribute for beans, they will be 
registered under their classname in Spring.
AndNO, I don't use autowiring: applyBeanPropertyValues() does not 
autowirealthough it is located in AutowireCapableBeanFactory.

Sven

you are right, this is not ioc. but are pages/components managed by an ioc
container?
-Igor


On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:

 #: Igor Vaynberg changed the world a bit at a time by saying on 11/6/2005
 7:06 PM :#
  Or how about a simple solution:
 
  public MyApplication extends WebApplication {
  public Object lookup(String name) {
  Object=...do a lookup from somewhere like spring context or app
 object...;
  return object;
  }
  }
 
  public MyPage extends Page {
  public transient SomeService service;
 
  public SomeService getService() {
  if (service==null) {
  service=getApplication().lookup(SomeService.class.getName());
  }
  return service;
  }
 
  I know its not quiete as elegant as ioc but it has none of the
 performance
  hits an automatic injection would cause if it would be done on
  deserialization of every component. Also its a lazy lookup so you dont
 do it
  until its needed, and its only done once per page (until it gets
  deserialized).
 
  -Igor
 

 But this was exactly what I was suggesting to avoid ;-). Lookups and
 factories are not ioc/di.

 ./alex
 --
 .w( the_mindstorm )p.



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


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

AW: Re: Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread sven

Hi Igor,

here is something i threw together that solves the deserialization andability 
to use the new operator to create pages.
 
thanks for your work on this.

Regretfully it's still a solution I wouldn't like to use:
IMHO dependency injection should not be done by the object which has the 
dependency. Yes, you've hidden the lookup in a base class, but nevertheless I 
still think that this is the wrong way around.

Regarding what Eelco has written:
 And... for this whole discussion: if you like one approach... go
 implement it now! Create your own component factory, annotations
 processor, aop, and please contribute when you've got something nice
 working. Or let us know when you need specific changes to Wicket to
 support your needs. We'll most probably honor such requests if they
 are reasonable as we've done in the past.

This is exactly what I'm talking about. Wicket should provide enough hooks for 
everybody to do *their* preferred approach - nothing more and nothing less.

It's just that I'm missing a required hook, but perhaps I've just missed it.
beforeCallComponent() was a step in the right direction, but I'd prefer to hook 
into such a notification outside of stateful code (i.e. a Page).

If it is the Session, PageMap or RequestCycle, if it's on deserializing or 
before calling a method doesn't matter to me - it just should happen outside of 
the pages.

Sven


On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:here is something i threw 
together that solves the deserialization andability to use the new operator to 
create pages. atleast i think itdoesits really late here and all i really 
know so far is that itcompiles :)

the idea is pretty simple, do the injection in the default constructor,and then 
do it anytime the object is deserialized. you use [EMAIL PROTECTED] annotation 
to denote the dependency. it can either be usedon a field or on a setter. If 
you specify the bean name it will be usedto find the bean, if you dont then the 
field's type or the settersargument type will be used for the lookup.

-Igor



On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:and you have to have the 
pages defined as beans in the application context? with their properties 
specified?

-Igor




On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:but how does the above 
handle deserealization of pages? there is nothing to reinject the dependencies.

-Igor




On 11/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:IMHO pages are standing 
on the borderline between a stateful GUI and the rest of the application in 
form of stateless services.
DIshould be done by the IoC container, creating the pages can better bedone the 
standard Wicket way (e.g. with PageParameters).

As described before I'm using a custom page factory that cooperates with a 
wrapped page factory and the containing bean factory:

public class SpringInjectingPageFactory implements IPageFactory, 
BeanFactoryAware {

 private AutowireCapableBeanFactory beanFactory;
 private IPageFactory pageFactory;

 public void setPageFactory(IPageFactory pageFactory) {
  this.pageFactory = pageFactory;
 }

 public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
  this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
 }

 public Page newPage(Class pageClass) {
  Page page = this.pageFactory.newPage(pageClass);

  injectDependencies(page, pageClass.getName());

  return page;
 }

 public Page newPage(Class pageClass, PageParameters parameters) {
  Page page = this.pageFactory.newPage(pageClass, parameters);

  injectDependencies(page, pageClass.getName());

  return page;
 }

 private void injectDependencies(Page page, String beanName) {
  if (this.beanFactory.containsBean(beanName)) {
this.beanFactory.applyBeanPropertyValues(page, beanName);
  }
 }
}

Note that if you don't specify a name or id attribute for beans, they will be 
registered under their classname in Spring.
AndNO, I don't use autowiring: applyBeanPropertyValues() does not 
autowirealthough it is located in AutowireCapableBeanFactory.

Sven

you are right, this is not ioc. but are pages/components managed by an ioc
container?
-Igor


On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:

 #: Igor Vaynberg changed the world a bit at a time by saying on 11/6/2005
 7:06 PM :#
  Or how about a simple solution:
 
  public MyApplication extends WebApplication {
  public Object lookup(String name) {
  Object=...do a lookup from somewhere like spring context or app
 object...;
  return object;
  }
  }
 
  public MyPage extends Page {
  public transient SomeService service;
 
  public SomeService getService() {
  if (service==null) {
  service=getApplication().lookup(SomeService.class.getName());
  }
  return service;
  }
 
  I know its not quiete as elegant as ioc but it has none of the
 performance
  hits an automatic injection would cause if it would be done on
  deserialization of every component. Also its a lazy lookup so you dont
 do it
  until its needed, and

Re: Re: Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread Juergen Donnerstag

Maybe RequestCycle.onBegin/EndRequest is what you are looking for?

Juergen

On 11/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Hi Igor,

 here is something i threw together that solves the deserialization 
 andability to use the new operator to create pages.

 thanks for your work on this.

 Regretfully it's still a solution I wouldn't like to use:
 IMHO dependency injection should not be done by the object which has the 
 dependency. Yes, you've hidden the lookup in a base class, but nevertheless I 
 still think that this is the wrong way around.

 Regarding what Eelco has written:
  And... for this whole discussion: if you like one approach... go
  implement it now! Create your own component factory, annotations
  processor, aop, and please contribute when you've got something nice
  working. Or let us know when you need specific changes to Wicket to
  support your needs. We'll most probably honor such requests if they
  are reasonable as we've done in the past.

 This is exactly what I'm talking about. Wicket should provide enough hooks 
 for everybody to do *their* preferred approach - nothing more and nothing 
 less.

 It's just that I'm missing a required hook, but perhaps I've just missed it.
 beforeCallComponent() was a step in the right direction, but I'd prefer to 
 hook into such a notification outside of stateful code (i.e. a Page).

 If it is the Session, PageMap or RequestCycle, if it's on deserializing or 
 before calling a method doesn't matter to me - it just should happen outside 
 of the pages.

 Sven


 On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:here is something i threw 
 together that solves the deserialization andability to use the new operator 
 to create pages. atleast i think itdoesits really late here and all i 
 really know so far is that itcompiles :)

 the idea is pretty simple, do the injection in the default constructor,and 
 then do it anytime the object is deserialized. you use [EMAIL PROTECTED] 
 annotation to denote the dependency. it can either be usedon a field or on a 
 setter. If you specify the bean name it will be usedto find the bean, if you 
 dont then the field's type or the settersargument type will be used for the 
 lookup.

 -Igor



 On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:and you have to have the 
 pages defined as beans in the application context? with their properties 
 specified?

 -Igor




 On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:but how does the above 
 handle deserealization of pages? there is nothing to reinject the 
 dependencies.

 -Igor




 On 11/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:IMHO pages are 
 standing on the borderline between a stateful GUI and the rest of the 
 application in form of stateless services.
 DIshould be done by the IoC container, creating the pages can better bedone 
 the standard Wicket way (e.g. with PageParameters).

 As described before I'm using a custom page factory that cooperates with a 
 wrapped page factory and the containing bean factory:

 public class SpringInjectingPageFactory implements IPageFactory, 
 BeanFactoryAware {

  private AutowireCapableBeanFactory beanFactory;
  private IPageFactory pageFactory;

  public void setPageFactory(IPageFactory pageFactory) {
  this.pageFactory = pageFactory;
  }

  public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
  this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
  }

  public Page newPage(Class pageClass) {
  Page page = this.pageFactory.newPage(pageClass);

  injectDependencies(page, pageClass.getName());

  return page;
  }

  public Page newPage(Class pageClass, PageParameters parameters) {
  Page page = this.pageFactory.newPage(pageClass, parameters);

  injectDependencies(page, pageClass.getName());

  return page;
  }

  private void injectDependencies(Page page, String beanName) {
  if (this.beanFactory.containsBean(beanName)) {
this.beanFactory.applyBeanPropertyValues(page, beanName);
  }
  }
 }

 Note that if you don't specify a name or id attribute for beans, they will be 
 registered under their classname in Spring.
 AndNO, I don't use autowiring: applyBeanPropertyValues() does not 
 autowirealthough it is located in AutowireCapableBeanFactory.

 Sven

 you are right, this is not ioc. but are pages/components managed by an ioc
 container?
 -Igor
 
 
 On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
 
  #: Igor Vaynberg changed the world a bit at a time by saying on 11/6/2005
  7:06 PM :#
   Or how about a simple solution:
  
   public MyApplication extends WebApplication {
   public Object lookup(String name) {
   Object=...do a lookup from somewhere like spring context or app
  object...;
   return object;
   }
   }
  
   public MyPage extends Page {
   public transient SomeService service;
  
   public SomeService getService() {
   if (service==null) {
   service=getApplication().lookup(SomeService.class.getName());
   }
   return service;
   }
  
   I know its

Re: Re: [Wicket-user] My take on Spring integration

On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner [EMAIL PROTECTED] 
wrote:



And there is also a thing like XML Serialization
Which also doesn't use the java read/write object at all.



Does this mean that the readObject is guaranteed to be called on Page 
because it is serialized through the PageMap and is not a direct session 
attribute?


I don't get realy clear with 'Serializable closure' in the spec:

Developers are not guaranteed that containers will call readObject and 
writeObject methods on
session attributes if they implement them, but are guaranteed that the 
Serializable closure of their attributes will be preserved.


And if readObject() gets called on Pages can I than acess somehow the 
ApplicationContext to get to the BeanContext?


Please help.

Thanks,
Christian



On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:


Hi Igor,

I looked through your code. Thanks for implementing it. I am not sure
wheter readObject() is the right place to do the (re)injection. 
According

to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be
called on session-attributes. (Instead session attributes which 
implement
HttpSessionActiviationListeners are informed on deserialization). Even 
if

readObject is called I am not sure wheter there is an ApplicationContext
to get to the BeanContext.

I don't know wheter wicket has a mean to propogate these 
HttpSessionEvents

on deserialization or a similar callback? If so I guess you could do the
(re)injection there.

Christian

On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg 
[EMAIL PROTECTED]

wrote:

 here is something i threw together that solves the deserialization and
 ability to use the new operator to create pages. atleast i think it
 doesits really late here and all i really know so far is that it
 compiles :)

 the idea is pretty simple, do the injection in the default 
constructor,

 and
 then do it anytime the object is deserialized. you use a @SpringBean
 annotation to denote the dependency. it can either be used on a field 
or

 on
 a setter. If you specify the bean name it will be used to find the 
bean,

 if
 you dont then the field's type or the setters argument type will be 
used

 for
 the lookup.

 -Igor


 On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:

 and you have to have the pages defined as beans in the application
 context? with their properties specified?

 -Igor


 On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
  but how does the above handle deserealization of pages? there is
 nothing
  to reinject the dependencies.
 
  -Igor
 
 
  On 11/7/05, [EMAIL PROTECTED]  [EMAIL PROTECTED] wrote:
  
   IMHO pages are standing on the borderline between a stateful GUI
and
   the rest of the application in form of stateless services.
   DI should be done by the IoC container, creating the pages can
 better
   be done the standard Wicket way (e.g. with PageParameters).
  
   As described before I'm using a custom page factory that 
cooperates

   with a wrapped page factory and the containing bean factory:
  
   public class SpringInjectingPageFactory implements IPageFactory,
   BeanFactoryAware {
  
   private AutowireCapableBeanFactory beanFactory;
   private IPageFactory pageFactory;
  
   public void setPageFactory(IPageFactory pageFactory) {
   this.pageFactory = pageFactory;
   }
  
   public void setBeanFactory(BeanFactory beanFactory) throws
   BeansException {
   this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
   }
  
   public Page newPage(Class pageClass) {
   Page page = this.pageFactory.newPage(pageClass);
  
   injectDependencies(page, pageClass.getName ());
  
   return page;
   }
  
   public Page newPage(Class pageClass, PageParameters parameters) {
   Page page = this.pageFactory.newPage(pageClass, parameters);
  
   injectDependencies(page, pageClass.getName ());
  
   return page;
   }
  
   private void injectDependencies(Page page, String beanName) {
   if (this.beanFactory.containsBean(beanName)) {
   this.beanFactory.applyBeanPropertyValues(page, beanName);
   }
   }
   }
  
   Note that if you don't specify a name or id attribute for beans,
 they
   will be registered under their classname in Spring.
   And NO, I don't use autowiring: applyBeanPropertyValues() does 
not

   autowire although it is located in AutowireCapableBeanFactory.
  
   Sven
  
   you are right, this is not ioc. but are pages/components managed
by
   an ioc
   container?
   -Igor
   
   
   On 11/6/05, Alexandru Popescu 
 [EMAIL PROTECTED]
   wrote:
   
#: Igor Vaynberg changed the world a bit at a time by saying 
on

   11/6/2005
7:06 PM :#
 Or how about a simple solution:

 public MyApplication extends WebApplication {
 public Object lookup(String name) {
 Object=...do a lookup from somewhere like spring context or
app
object...;
 return object;
 }
 }

 public MyPage extends Page {
 public transient SomeService service;

 public SomeService

Re: Re: [Wicket-user] My take on Spring integration

I think with xml sereialization getobject is never called so there we
still have a problem. But i think when the pagemap will deserialize the
page if normal serialization is used then the readobject will be called
on the page.

The serialization closure, i think, reffers to the fact that container
will still serialize all serializable children of the attribute even if
it is using something like xml serialization where read/writeobject are
never called.

To get the bean context i simply make my applicationbean implement
applicationcontextaware and then i use
((MyApplication)Application.get()).getBeanContext() static lookup which
works because application object is always present.

-Igor
On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner [EMAIL PROTECTED]wrote: And there is also a thing like XML Serialization Which also doesn't use the java read/write object at all.
Does this mean that the readObject is guaranteed to be called on Pagebecause it is serialized through the PageMap and is not a direct sessionattribute?I don't get realy clear with 'Serializable closure' in the spec:
Developers are not guaranteed that containers will call readObject andwriteObject methods onsession attributes if they implement them, but are guaranteed that theSerializable closure of their attributes will be preserved.
And if readObject() gets called on Pages can I than acess somehow theApplicationContext to get to the BeanContext?Please help.Thanks,Christian On 11/7/05, Christian Essl 
[EMAIL PROTECTED] wrote: Hi Igor, I looked through your code. Thanks for implementing it. I am not sure wheter readObject() is the right place to do the (re)injection.
 According to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be called on session-attributes. (Instead session attributes which implement HttpSessionActiviationListeners are informed on deserialization). Even
 if readObject is called I am not sure wheter there is an ApplicationContext to get to the BeanContext. I don't know wheter wicket has a mean to propogate these
 HttpSessionEvents on deserialization or a similar callback? If so I guess you could do the (re)injection there. Christian On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg
 [EMAIL PROTECTED] wrote:  here is something i threw together that solves the deserialization and  ability to use the new operator to create pages. atleast i think it
  doesits really late here and all i really know so far is that it  compiles :)   the idea is pretty simple, do the injection in the default constructor,
  and  then do it anytime the object is deserialized. you use a @SpringBean  annotation to denote the dependency. it can either be used on a field or  on
  a setter. If you specify the bean name it will be used to find the bean,  if  you dont then the field's type or the setters argument type will be used
  for  the lookup.   -IgorOn 11/7/05, Igor Vaynberg [EMAIL PROTECTED]
 wrote:   and you have to have the pages defined as beans in the application  context? with their properties specified?   -Igor
On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote: but how does the above handle deserealization of pages? there is
  nothing   to reinject the dependencies. -Igor   On 11/7/05, 
[EMAIL PROTECTED]  [EMAIL PROTECTED] wrote:   IMHO pages are standing on the borderline between a stateful GUI
 andthe rest of the application in form of stateless services.DI should be done by the IoC container, creating the pages can  better
be done the standard Wicket way (e.g. with PageParameters).   As described before I'm using a custom page factory that cooperates
with a wrapped page factory and the containing bean factory:   public class SpringInjectingPageFactory implements IPageFactory,
BeanFactoryAware {   private AutowireCapableBeanFactory beanFactory;private IPageFactory pageFactory;
   public void setPageFactory(IPageFactory pageFactory) {this.pageFactory = pageFactory;}   
public void setBeanFactory(BeanFactory beanFactory) throwsBeansException {this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
}   public Page newPage(Class pageClass) {Page page = this.pageFactory.newPage(pageClass);   
injectDependencies(page, pageClass.getName ());   return page;}   
public Page newPage(Class pageClass, PageParameters parameters) {Page page = this.pageFactory.newPage(pageClass, parameters);   injectDependencies(page, 
pageClass.getName ());   return page;}   private void injectDependencies(Page page, String beanName) {
if (this.beanFactory.containsBean(beanName)) {this.beanFactory.applyBeanPropertyValues(page, beanName);}}
}   Note that if you don't specify a name or id attribute for beans,  theywill be registered under their classname in Spring.
And NO, I don't use autowiring: applyBeanPropertyValues() does notautowire

Re: Re: [Wicket-user] My take on Spring integration

Thanks for the clarification and sorry for the confusion. So readObject() 
as you have it in your code is fine.



To get the bean context i simply make my applicationbean implement
applicationcontextaware and then i use
((MyApplication)Application.get()).getBeanContext() static lookup which
works because application object is always present.


Still one question. The threadlocal used in Application.get() is set at 
the beginning of a request - on the request thread. I do not know but 
maybe the deserialization of the session could happen outside of a request 
- even in a totally different thread?


Maybe in readObject() a dynamic proxy could be injected which triggers on 
first access the onInject() method.


Christian



-Igor


On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:


On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner 
[EMAIL PROTECTED]

wrote:

 And there is also a thing like XML Serialization
 Which also doesn't use the java read/write object at all.


Does this mean that the readObject is guaranteed to be called on Page
because it is serialized through the PageMap and is not a direct session
attribute?

I don't get realy clear with 'Serializable closure' in the spec:

Developers are not guaranteed that containers will call readObject and
writeObject methods on
session attributes if they implement them, but are guaranteed that the
Serializable closure of their attributes will be preserved.

And if readObject() gets called on Pages can I than acess somehow the
ApplicationContext to get to the BeanContext?

Please help.

Thanks,
Christian


 On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:

 Hi Igor,

 I looked through your code. Thanks for implementing it. I am not sure
 wheter readObject() is the right place to do the (re)injection.
 According
 to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be
 called on session-attributes. (Instead session attributes which
 implement
 HttpSessionActiviationListeners are informed on deserialization). 
Even

 if
 readObject is called I am not sure wheter there is an
ApplicationContext
 to get to the BeanContext.

 I don't know wheter wicket has a mean to propogate these
 HttpSessionEvents
 on deserialization or a similar callback? If so I guess you could do
the
 (re)injection there.

 Christian

 On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg
 [EMAIL PROTECTED]
 wrote:

  here is something i threw together that solves the deserialization
and
  ability to use the new operator to create pages. atleast i think it
  doesits really late here and all i really know so far is that 
it

  compiles :)
 
  the idea is pretty simple, do the injection in the default
 constructor,
  and
  then do it anytime the object is deserialized. you use a 
@SpringBean
  annotation to denote the dependency. it can either be used on a 
field

 or
  on
  a setter. If you specify the bean name it will be used to find the
 bean,
  if
  you dont then the field's type or the setters argument type will be
 used
  for
  the lookup.
 
  -Igor
 
 
  On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
 
  and you have to have the pages defined as beans in the application
  context? with their properties specified?
 
  -Igor
 
 
  On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   but how does the above handle deserealization of pages? there is
  nothing
   to reinject the dependencies.
  
   -Igor
  
  
   On 11/7/05, [EMAIL PROTECTED]  [EMAIL PROTECTED] wrote:
   
IMHO pages are standing on the borderline between a stateful 
GUI

 and
the rest of the application in form of stateless services.
DI should be done by the IoC container, creating the pages can
  better
be done the standard Wicket way (e.g. with PageParameters).
   
As described before I'm using a custom page factory that
 cooperates
with a wrapped page factory and the containing bean factory:
   
public class SpringInjectingPageFactory implements 
IPageFactory,

BeanFactoryAware {
   
private AutowireCapableBeanFactory beanFactory;
private IPageFactory pageFactory;
   
public void setPageFactory(IPageFactory pageFactory) {
this.pageFactory = pageFactory;
}
   
public void setBeanFactory(BeanFactory beanFactory) throws
BeansException {
this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
}
   
public Page newPage(Class pageClass) {
Page page = this.pageFactory.newPage(pageClass);
   
injectDependencies(page, pageClass.getName ());
   
return page;
}
   
public Page newPage(Class pageClass, PageParameters 
parameters)

{
Page page = this.pageFactory.newPage(pageClass, parameters);
   
injectDependencies(page, pageClass.getName ());
   
return page;
}
   
private void injectDependencies(Page page, String beanName) {
if (this.beanFactory.containsBean(beanName)) {
this.beanFactory.applyBeanPropertyValues(page, beanName);
}
}
}
   
Note that if you don't specify

Re: Re: [Wicket-user] My take on Spring integration

what interface would you use for the proxy though?
-Igor
On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
Thanks for the clarification and sorry for the confusion. So readObject()as you have it in your code is fine. To get the bean context i simply make my applicationbean implement applicationcontextaware and then i use
 ((MyApplication)Application.get()).getBeanContext() static lookup which works because application object is always present.Still one question. The threadlocal used in Application.get() is set at
the beginning of a request - on the request thread. I do not know butmaybe the deserialization of the session could happen outside of a request- even in a totally different thread?Maybe in readObject() a dynamic proxy could be injected which triggers on
first access the onInject() method.Christian -Igor On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
 On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner [EMAIL PROTECTED] wrote:  And there is also a thing like XML Serialization
  Which also doesn't use the java read/write object at all.  Does this mean that the readObject is guaranteed to be called on Page because it is serialized through the PageMap and is not a direct session
 attribute? I don't get realy clear with 'Serializable closure' in the spec: Developers are not guaranteed that containers will call readObject and writeObject methods on
 session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved. And if readObject() gets called on Pages can I than acess somehow the
 ApplicationContext to get to the BeanContext? Please help. Thanks, Christian   On 11/7/05, Christian Essl 
[EMAIL PROTECTED] wrote:   Hi Igor,   I looked through your code. Thanks for implementing it. I am not sure
  wheter readObject() is the right place to do the (re)injection.  According  to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be  called on session-attributes. (Instead session attributes which
  implement  HttpSessionActiviationListeners are informed on deserialization). Even  if  readObject is called I am not sure wheter there is an
 ApplicationContext  to get to the BeanContext.   I don't know wheter wicket has a mean to propogate these  HttpSessionEvents
  on deserialization or a similar callback? If so I guess you could do the  (re)injection there.   Christian 
  On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg  [EMAIL PROTECTED]  wrote:here is something i threw together that solves the deserialization
 and   ability to use the new operator to create pages. atleast i think it   doesits really late here and all i really know so far is that it
   compiles :) the idea is pretty simple, do the injection in the default  constructor,   and   then do it anytime the object is deserialized. you use a
 @SpringBean   annotation to denote the dependency. it can either be used on a field  or   on   a setter. If you specify the bean name it will be used to find the
  bean,   if   you dont then the field's type or the setters argument type will be  used   for   the lookup.
 -Igor   On 11/7/05, Igor Vaynberg [EMAIL PROTECTED]
 wrote: and you have to have the pages defined as beans in the application   context? with their properties specified?  
   -Igor   On 11/7/05, Igor Vaynberg [EMAIL PROTECTED]
 wrote:   but how does the above handle deserealization of pages? there is   nothingto reinject the dependencies.
   -Igor  On 11/7/05, 
[EMAIL PROTECTED]  [EMAIL PROTECTED] wrote: IMHO pages are standing on the borderline between a stateful
 GUI  and the rest of the application in form of stateless services. DI should be done by the IoC container, creating the pages can
   better be done the standard Wicket way (e.g. with PageParameters). As described before I'm using a custom page factory that
  cooperates with a wrapped page factory and the containing bean factory: public class SpringInjectingPageFactory implements
 IPageFactory, BeanFactoryAware { private AutowireCapableBeanFactory beanFactory; private IPageFactory pageFactory;
 public void setPageFactory(IPageFactory pageFactory) { this.pageFactory = pageFactory; }
 public void setBeanFactory(BeanFactory beanFactory) throws BeansException { 
this.beanFactory = (AutowireCapableBeanFactory)beanFactory; } public Page newPage(Class pageClass) {
 Page page = this.pageFactory.newPage(pageClass); injectDependencies(page, pageClass.getName ());
 return page; } public Page newPage(Class pageClass, PageParameters
 parameters) { Page page = this.pageFactory.newPage(pageClass, parameters); injectDependencies(page, 
pageClass.getName ()); return page; } private void injectDependencies(Page page, String beanName) {
 if (this.beanFactory.containsBean(beanName)) {

Re: Re: [Wicket-user] My take on Spring integration

The interface of the setter parameter or of the field type. Of course a 
restriction. If you want more you could use cglib (or spring aop). Don't 
know.




On Mon, 7 Nov 2005 11:27:28 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



what interface would you use for the proxy though?
-Igor


On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:


Thanks for the clarification and sorry for the confusion. So 
readObject()

as you have it in your code is fine.

 To get the bean context i simply make my applicationbean implement
 applicationcontextaware and then i use
 ((MyApplication)Application.get()).getBeanContext() static lookup 
which

 works because application object is always present.

Still one question. The threadlocal used in Application.get() is set at
the beginning of a request - on the request thread. I do not know but
maybe the deserialization of the session could happen outside of a 
request

- even in a totally different thread?

Maybe in readObject() a dynamic proxy could be injected which triggers 
on

first access the onInject() method.

Christian


 -Igor


 On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:

 On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner
 [EMAIL PROTECTED]
 wrote:

  And there is also a thing like XML Serialization
  Which also doesn't use the java read/write object at all.
 

 Does this mean that the readObject is guaranteed to be called on Page
 because it is serialized through the PageMap and is not a direct
session
 attribute?

 I don't get realy clear with 'Serializable closure' in the spec:

 Developers are not guaranteed that containers will call readObject 
and

 writeObject methods on
 session attributes if they implement them, but are guaranteed that 
the

 Serializable closure of their attributes will be preserved.

 And if readObject() gets called on Pages can I than acess somehow the
 ApplicationContext to get to the BeanContext?

 Please help.

 Thanks,
 Christian

 
  On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
 
  Hi Igor,
 
  I looked through your code. Thanks for implementing it. I am not
sure
  wheter readObject() is the right place to do the (re)injection.
  According
  to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to
be
  called on session-attributes. (Instead session attributes which
  implement
  HttpSessionActiviationListeners are informed on deserialization).
 Even
  if
  readObject is called I am not sure wheter there is an
 ApplicationContext
  to get to the BeanContext.
 
  I don't know wheter wicket has a mean to propogate these
  HttpSessionEvents
  on deserialization or a similar callback? If so I guess you could 
do

 the
  (re)injection there.
 
  Christian
 
  On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg
  [EMAIL PROTECTED]
  wrote:
 
   here is something i threw together that solves the 
deserialization

 and
   ability to use the new operator to create pages. atleast i think
it
   doesits really late here and all i really know so far is 
that

 it
   compiles :)
  
   the idea is pretty simple, do the injection in the default
  constructor,
   and
   then do it anytime the object is deserialized. you use a
 @SpringBean
   annotation to denote the dependency. it can either be used on a
 field
  or
   on
   a setter. If you specify the bean name it will be used to find 
the

  bean,
   if
   you dont then the field's type or the setters argument type will
be
  used
   for
   the lookup.
  
   -Igor
  
  
   On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
  
   and you have to have the pages defined as beans in the
application
   context? with their properties specified?
  
   -Igor
  
  
   On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
   
but how does the above handle deserealization of pages? there
is
   nothing
to reinject the dependencies.
   
-Igor
   
   
On 11/7/05, [EMAIL PROTECTED]  [EMAIL PROTECTED] wrote:

 IMHO pages are standing on the borderline between a 
stateful

 GUI
  and
 the rest of the application in form of stateless services.
 DI should be done by the IoC container, creating the pages
can
   better
 be done the standard Wicket way (e.g. with PageParameters).

 As described before I'm using a custom page factory that
  cooperates
 with a wrapped page factory and the containing bean 
factory:


 public class SpringInjectingPageFactory implements
 IPageFactory,
 BeanFactoryAware {

 private AutowireCapableBeanFactory beanFactory;
 private IPageFactory pageFactory;

 public void setPageFactory(IPageFactory pageFactory) {
 this.pageFactory = pageFactory;
 }

 public void setBeanFactory(BeanFactory beanFactory) throws
 BeansException {
 this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
 }

 public Page newPage(Class pageClass) {
 Page page = this.pageFactory.newPage(pageClass);

 injectDependencies(page, pageClass.getName ());

Re: Re: [Wicket-user] My take on Spring integration

yeah, i was thinking cglib and extract at runtime
never used cglib before though

that way you just wrap the page with the proxy after you create it and
there is no need to worry about serialization/deserialiation garbage

-Igor
On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
The interface of the setter parameter or of the field type. Of course arestriction. If you want more you could use cglib (or spring aop). Don'tknow.On Mon, 7 Nov 2005 11:27:28 -0800, Igor Vaynberg 
[EMAIL PROTECTED]wrote: what interface would you use for the proxy though? -Igor On 11/7/05, Christian Essl 
[EMAIL PROTECTED] wrote: Thanks for the clarification and sorry for the confusion. So readObject() as you have it in your code is fine.  To get the bean context i simply make my applicationbean implement
  applicationcontextaware and then i use  ((MyApplication)Application.get()).getBeanContext() static lookup which  works because application object is always present.
 Still one question. The threadlocal used in Application.get() is set at the beginning of a request - on the request thread. I do not know but maybe the deserialization of the session could happen outside of a
 request - even in a totally different thread? Maybe in readObject() a dynamic proxy could be injected which triggers on first access the onInject() method.
 Christian   -IgorOn 11/7/05, Christian Essl [EMAIL PROTECTED]
 wrote:   On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner  [EMAIL PROTECTED]  wrote:
And there is also a thing like XML Serialization   Which also doesn't use the java read/write object at all.   
  Does this mean that the readObject is guaranteed to be called on Page  because it is serialized through the PageMap and is not a direct session  attribute?
   I don't get realy clear with 'Serializable closure' in the spec:   Developers are not guaranteed that containers will call readObject
 and  writeObject methods on  session attributes if they implement them, but are guaranteed that the  Serializable closure of their attributes will be preserved.
   And if readObject() gets called on Pages can I than acess somehow the  ApplicationContext to get to the BeanContext?   Please help.
   Thanks,  Christian  On 11/7/05, Christian Essl 
[EMAIL PROTECTED] wrote: Hi Igor, I looked through your code. Thanks for implementing it. I am not
 sure   wheter readObject() is the right place to do the (re)injection.   According   to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to
 be   called on session-attributes. (Instead session attributes which   implement   HttpSessionActiviationListeners are informed on deserialization).
  Even   if   readObject is called I am not sure wheter there is an  ApplicationContext   to get to the BeanContext.
 I don't know wheter wicket has a mean to propogate these   HttpSessionEvents   on deserialization or a similar callback? If so I guess you could
 do  the   (re)injection there. Christian On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg
   [EMAIL PROTECTED]   wrote:  here is something i threw together that solves the
 deserialization  andability to use the new operator to create pages. atleast i think itdoesits really late here and all i really know so far is
 that  itcompiles :)   the idea is pretty simple, do the injection in the default
   constructor,andthen do it anytime the object is deserialized. you use a  @SpringBeanannotation to denote the dependency. it can either be used on a
  field   orona setter. If you specify the bean name it will be used to find the   bean,
ifyou dont then the field's type or the setters argument type will be   usedfor
the lookup.   -Igor  On 11/7/05, Igor Vaynberg 
[EMAIL PROTECTED] wrote:   and you have to have the pages defined as beans in the application
context? with their properties specified?   -Igor  
On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote: but how does the above handle deserealization of pages? there
 isnothing to reinject the dependencies. -Igor
 On 11/7/05, [EMAIL PROTECTED]  
[EMAIL PROTECTED] wrote:   IMHO pages are standing on the borderline between a stateful  GUI
   and  the rest of the application in form of stateless services.  DI should be done by the IoC container, creating the pages
 canbetter  be done the standard Wicket way (e.g. with PageParameters). 
  As described before I'm using a custom page factory that   cooperates  with a wrapped page factory and the containing bean
 factory:   public class SpringInjectingPageFactory implements  IPageFactory,  BeanFactoryAware {
   private AutowireCapableBeanFactory beanFactory;  private IPageFactory pageFactory;
   public void setPageFactory(IPageFactory pageFactory) {  this.pageFactory = pageFactory;
  }   public void setBeanFactory(BeanFactory beanFactory)

Re: Re: [Wicket-user] My take on Spring integration


Do you mean when you construct the page you do something like

MyPage page = (MyPage) wrapInProxy(new MyPage(..));

and wrapInProxy does create the Proxy and does all the injection?


On Mon, 7 Nov 2005 11:56:23 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



yeah, i was thinking cglib and extract at runtime
never used cglib before though

that way you just wrap the page with the proxy after you create it and 
there

is no need to worry about serialization/deserialiation garbage

-Igor


On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:


The interface of the setter parameter or of the field type. Of course a
restriction. If you want more you could use cglib (or spring aop). Don't
know.



On Mon, 7 Nov 2005 11:27:28 -0800, Igor Vaynberg 
[EMAIL PROTECTED]

wrote:

 what interface would you use for the proxy though?
 -Igor


 On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:

 Thanks for the clarification and sorry for the confusion. So
 readObject()
 as you have it in your code is fine.

  To get the bean context i simply make my applicationbean implement
  applicationcontextaware and then i use
  ((MyApplication)Application.get()).getBeanContext() static lookup
 which
  works because application object is always present.

 Still one question. The threadlocal used in Application.get() is set 
at

 the beginning of a request - on the request thread. I do not know but
 maybe the deserialization of the session could happen outside of a
 request
 - even in a totally different thread?

 Maybe in readObject() a dynamic proxy could be injected which 
triggers

 on
 first access the onInject() method.

 Christian

 
  -Igor
 
 
  On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
 
  On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner
  [EMAIL PROTECTED]
  wrote:
 
   And there is also a thing like XML Serialization
   Which also doesn't use the java read/write object at all.
  
 
  Does this mean that the readObject is guaranteed to be called on
Page
  because it is serialized through the PageMap and is not a direct
 session
  attribute?
 
  I don't get realy clear with 'Serializable closure' in the spec:
 
  Developers are not guaranteed that containers will call 
readObject

 and
  writeObject methods on
  session attributes if they implement them, but are guaranteed that
 the
  Serializable closure of their attributes will be preserved.
 
  And if readObject() gets called on Pages can I than acess somehow
the
  ApplicationContext to get to the BeanContext?
 
  Please help.
 
  Thanks,
  Christian
 
  
   On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
  
   Hi Igor,
  
   I looked through your code. Thanks for implementing it. I am 
not

 sure
   wheter readObject() is the right place to do the (re)injection.
   According
   to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed
to
 be
   called on session-attributes. (Instead session attributes which
   implement
   HttpSessionActiviationListeners are informed on 
deserialization).

  Even
   if
   readObject is called I am not sure wheter there is an
  ApplicationContext
   to get to the BeanContext.
  
   I don't know wheter wicket has a mean to propogate these
   HttpSessionEvents
   on deserialization or a similar callback? If so I guess you 
could

 do
  the
   (re)injection there.
  
   Christian
  
   On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg
   [EMAIL PROTECTED]
   wrote:
  
here is something i threw together that solves the
 deserialization
  and
ability to use the new operator to create pages. atleast i
think
 it
doesits really late here and all i really know so far is
 that
  it
compiles :)
   
the idea is pretty simple, do the injection in the default
   constructor,
and
then do it anytime the object is deserialized. you use a
  @SpringBean
annotation to denote the dependency. it can either be used 
on a

  field
   or
on
a setter. If you specify the bean name it will be used to 
find

 the
   bean,
if
you dont then the field's type or the setters argument type
will
 be
   used
for
the lookup.
   
-Igor
   
   
On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
   
and you have to have the pages defined as beans in the
 application
context? with their properties specified?
   
-Igor
   
   
On 11/7/05, Igor Vaynberg [EMAIL PROTECTED] wrote:

 but how does the above handle deserealization of pages?
there
 is
nothing
 to reinject the dependencies.

 -Igor


 On 11/7/05, [EMAIL PROTECTED]  [EMAIL PROTECTED] wrote:
 
  IMHO pages are standing on the borderline between a
 stateful
  GUI
   and
  the rest of the application in form of stateless 
services.
  DI should be done by the IoC container, creating the 
pages

 can
better
  be done the standard Wicket way (e.g. with
PageParameters).
 
  As described before I'm using a custom page factory that
   cooperates
  with a

Re: Re: [Wicket-user] My take on Spring integration

yes. but instead of doing the injection right away the proxy would do injection-on-first-access.
that way you get lazy injection and strongly typed pages.

so you would annotate getter functions with the @SpringBean annot, and
the proxy would first call the getter ... if the getter returns null
the proxy would then look for the setter and invoke the setter with the
dependency, and then forward the call to the getter again.

sound like a good idea?

its not as elegant as being able to simply create the page and go, but
it does give us the benefit of lazy dependency lookups and solves
deserialization issues.

i guess of course if you want to use aop you can intercept new operator
on a subclass of WebPage and do the wrapping automatically.

Or make the constructors of the page protected and create public static
factory methods. MyPage page=MyPage.construct(user, securitycontext);

-Igor
On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
Do you mean when you construct the page you do something likeMyPage page = (MyPage) wrapInProxy(new MyPage(..));and wrapInProxy does create the Proxy and does all the injection?On Mon, 7 Nov 2005 11:56:23 -0800, Igor Vaynberg
[EMAIL PROTECTED]wrote: yeah, i was thinking cglib and extract at runtime never used cglib before though that way you just wrap the page with the proxy after you create it and
there is no need to worry about serialization/deserialiation garbage -Igor On 11/7/05, Christian Essl [EMAIL PROTECTED]
wrote: The interface of the setter parameter or of the field type. Of course a restriction. If you want more you could use cglib (or spring aop). Don't know.
On Mon, 7 Nov 2005 11:27:28 -0800, Igor Vaynberg [EMAIL PROTECTED] wrote: what interface would you use for the proxy though?
-IgorOn 11/7/05, Christian Essl [EMAIL PROTECTED] wrote: Thanks for the clarification and sorry for the confusion. So
readObject() as you have it in your code is fine.To get the bean context i simply make my applicationbean implement applicationcontextaware and then i use
((MyApplication)Application.get()).getBeanContext() static lookup which works because application object is always present.
Still one question. The threadlocal used in Application.get() is set at the beginning of a request - on the request thread. I do not know but maybe the deserialization of the session could happen outside of a
request - even in a totally different thread? Maybe in readObject() a dynamic proxy could be injected which triggers on
first access the onInject() method. Christian -Igor
On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote: On Mon, 7 Nov 2005 15:25:29 +0100, Johan Compagner
[EMAIL PROTECTED] wrote: And there is also a thing like XML Serialization
Which also doesn't use the java read/write object at all.Does this mean that the readObject is guaranteed to be called on
Page because it is serialized through the PageMap and is not a direct session attribute? I don't get realy clear with 'Serializable closure' in the spec:
Developers are not guaranteed that containers will call readObject and writeObject methods on
session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved.
And if readObject() gets called on Pages can I than acess somehow the ApplicationContext to get to the BeanContext?
Please help. Thanks, Christian On 11/7/05, Christian Essl
[EMAIL PROTECTED] wrote: Hi Igor, I looked through your code. Thanks for implementing it. I am
not surewheter readObject() is the right place to do the (re)injection.Accordingto the servlet-spec in SVR
7.7.2 readObject() is not guaranteed to becalled on session-attributes. (Instead session attributes whichimplement
HttpSessionActiviationListeners are informed on deserialization). EvenifreadObject is called I am not sure wheter there is an
ApplicationContextto get to the BeanContext. I don't know wheter wicket has a mean to propogate these
HttpSessionEventson deserialization or a similar callback? If so I guess you could do the
(re)injection there. Christian On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg
[EMAIL PROTECTED]wrote:here is something i threw together that solves the
deserialization and ability to use the new operator to create pages. atleast i think it doesits really late here and all i really know so far is
that it compiles :) the idea is pretty simple, do the injection in the default
constructor, and then do it anytime the object is deserialized. you use a @SpringBean
annotation to denote the dependency. it can either be used on a fieldor on
a setter. If you specify the bean name it will be used to find thebean, if
you dont then the field's type or the setters

Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread Sven Meier


Hello Igor,

I must object to your statement that my proposed page factory is not IoC:

Nobody says that a Spring context is the only valid container in an 
application. The page factory just becomes part of the this logical 
container, it is aware of and cooperates with the Sprint context.


When using IoC you always have to device which components are aware of 
IoC and which not. IMHO this awareness is acceptable for page factories 
and wicket applications, but not pages.
Spring is able to handle prototypes, the only unusual thing is that 
pages get serialized. But with 're-injection' this is easily solved. AND 
you can use strongly typed constructors too.


What I don't understand why we should talk about 'magic' solutions as 
readObject() or dynamic proxies.

As Eelco wrote it:


I'd like to state very clear that we are not looking for Wicket to
become a plumbing framework; we just want to develiver a good
framework for developing web applications with enough elegant hooks
for integrating with other frameworks yourself.


IMHO to satisfy all possible requirements, these hooks shouldn't be 
located on the pages.
It is easier to call from stateless code into stateful code (i.e. 
RequestCycle - Page) than the other way around.


Sven

Igor Vaynberg wrote:


Yes, it is not ioc, i never claimed it was. Sven's page factory is not ioc
either because the container does not manage the lifecycle of the page.

Does an ioc page make sense? I dont think so. I like to use the new operator
to instantiate pages myself, I also really like to have strongly typed
constructors for my pages. I dont think ioc containers are meant to be used
with these kinds of volatile objects. ioc containers are meant for more
static objects which are 90% of the time singletons. Sure there are factory
beans in spring and prototype beans, but they do not give you the freedom of
constructors. Also ioc managed objects are not meant to be serialized
outside of their container, in the webworld that is unavoidable. Dont get me
wrong, i love ioc, but i dont think its the right tool here.

I looked into the HttpSessionActivationListener. Didnt know about that
little nasty spot int he spec :) I think we can solve the problem by letting
pagemaps implement the listener interface and cascading it down to pages.
But i dont think that is a good idea because there will be a big performance
hit. Why do resolution on all the pages in the pagemap if we are only going
to use at most one of them.

Maybe the method that pulls a page out of the pagemap can call a hook on the
page, like Page.reinitialize(), and we can use that to reinject the
dependencies. Of course, this wont work for pages that store references to
other pages unless the owning page cascades down the reinitialize() call. I
just dont see an elegant solution.

Another idea which is a bit nasty but i think would work ok is to use a bit
of runtime magic. We can extract a page's interface at runtime and create a
dynamic proxy that can lazy-lookup dependencies whenever a getter is called.
So creating a page becomes a two part step, create the page and wrap the
proxy around it. The proxy should be able to serialize with the page and
deserialize fine.


-Igor



On 11/7/05, Eduardo Rocha [EMAIL PROTECTED] wrote:
 


Igor, the class you have implemented is exactly the way I was
thinking. However Sven pointed out correctly that this is not really
IoC, since the component itself is looking for its dependencies
(Alexandru said that even before...).
   






But even if it is not IoC, I think this is a nice approach. The client
 


code it would look exactly like a really IoC implementation (if
getSpringContext() is implemented in another way). And if I can live
with the Page constructor automatically attaching itself to the
Session, I could live with Pages doing serialization as well.

That said, a really IoC approach seems to be achieved either using AOP
or doing something with onBeginRequest/onBeginResponse, as Sven,
Juergen and Johan said before.

2005/11/7, Johan Compagner [EMAIL PROTECTED]:
   


And there is also a thing like XML Serialization
Which also doesn't use the java read/write object at all.



On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
 


Hi Igor,

I looked through your code. Thanks for implementing it. I am not sure
wheter readObject() is the right place to do the (re)injection.
   


According
   


to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be
called on session-attributes. (Instead session attributes which
   


implement
   


HttpSessionActiviationListeners are informed on deserialization). Even
   


if
   


readObject is called I am not sure wheter there is an
   


ApplicationContext
   


to get to the BeanContext.

I don't know wheter wicket has a mean to propogate these
   


HttpSessionEvents
   


on deserialization or a similar callback? If so I guess you could do
   


the
   


(re)injection there.

Christian

Re: [Wicket-user] My take on Spring integration

2005-11-07 Thread Eelco Hillenius

That kind of hooks exist. One of our goals for 1.2 is to further
formalize this, and also have better pluggable support for url
handling and state handling. We are getting some ideas on how this
could look, but it is stuff you really have to think through well.

Eelco


On 11/7/05, Sven Meier [EMAIL PROTECTED] wrote:
 Hello Igor,

 I must object to your statement that my proposed page factory is not IoC:

 Nobody says that a Spring context is the only valid container in an
 application. The page factory just becomes part of the this logical
 container, it is aware of and cooperates with the Sprint context.

 When using IoC you always have to device which components are aware of
 IoC and which not. IMHO this awareness is acceptable for page factories
 and wicket applications, but not pages.
 Spring is able to handle prototypes, the only unusual thing is that
 pages get serialized. But with 're-injection' this is easily solved. AND
 you can use strongly typed constructors too.

 What I don't understand why we should talk about 'magic' solutions as
 readObject() or dynamic proxies.
 As Eelco wrote it:

 I'd like to state very clear that we are not looking for Wicket to
 become a plumbing framework; we just want to develiver a good
 framework for developing web applications with enough elegant hooks
 for integrating with other frameworks yourself.

 IMHO to satisfy all possible requirements, these hooks shouldn't be
 located on the pages.
 It is easier to call from stateless code into stateful code (i.e.
 RequestCycle - Page) than the other way around.

 Sven

 Igor Vaynberg wrote:

 Yes, it is not ioc, i never claimed it was. Sven's page factory is not ioc
 either because the container does not manage the lifecycle of the page.
 
 Does an ioc page make sense? I dont think so. I like to use the new operator
 to instantiate pages myself, I also really like to have strongly typed
 constructors for my pages. I dont think ioc containers are meant to be used
 with these kinds of volatile objects. ioc containers are meant for more
 static objects which are 90% of the time singletons. Sure there are factory
 beans in spring and prototype beans, but they do not give you the freedom of
 constructors. Also ioc managed objects are not meant to be serialized
 outside of their container, in the webworld that is unavoidable. Dont get me
 wrong, i love ioc, but i dont think its the right tool here.
 
 I looked into the HttpSessionActivationListener. Didnt know about that
 little nasty spot int he spec :) I think we can solve the problem by letting
 pagemaps implement the listener interface and cascading it down to pages.
 But i dont think that is a good idea because there will be a big performance
 hit. Why do resolution on all the pages in the pagemap if we are only going
 to use at most one of them.
 
 Maybe the method that pulls a page out of the pagemap can call a hook on the
 page, like Page.reinitialize(), and we can use that to reinject the
 dependencies. Of course, this wont work for pages that store references to
 other pages unless the owning page cascades down the reinitialize() call. I
 just dont see an elegant solution.
 
 Another idea which is a bit nasty but i think would work ok is to use a bit
 of runtime magic. We can extract a page's interface at runtime and create a
 dynamic proxy that can lazy-lookup dependencies whenever a getter is called.
 So creating a page becomes a two part step, create the page and wrap the
 proxy around it. The proxy should be able to serialize with the page and
 deserialize fine.
 
 
 -Igor
 
 
 
 On 11/7/05, Eduardo Rocha [EMAIL PROTECTED] wrote:
 
 
 Igor, the class you have implemented is exactly the way I was
 thinking. However Sven pointed out correctly that this is not really
 IoC, since the component itself is looking for its dependencies
 (Alexandru said that even before...).
 
 
 
 
 
 
 But even if it is not IoC, I think this is a nice approach. The client
 
 
 code it would look exactly like a really IoC implementation (if
 getSpringContext() is implemented in another way). And if I can live
 with the Page constructor automatically attaching itself to the
 Session, I could live with Pages doing serialization as well.
 
 That said, a really IoC approach seems to be achieved either using AOP
 or doing something with onBeginRequest/onBeginResponse, as Sven,
 Juergen and Johan said before.
 
 2005/11/7, Johan Compagner [EMAIL PROTECTED]:
 
 
 And there is also a thing like XML Serialization
 Which also doesn't use the java read/write object at all.
 
 
 
 On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:
 
 
 Hi Igor,
 
 I looked through your code. Thanks for implementing it. I am not sure
 wheter readObject() is the right place to do the (re)injection.
 
 
 According
 
 
 to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be
 called on session-attributes. (Instead session attributes which
 
 
 implement
 
 
 HttpSessionActiviationListeners are informed

Re: [Wicket-user] My take on Spring integration

On 11/7/05, Sven Meier [EMAIL PROTECTED] wrote:
Hello Igor,I must object to your statement that my proposed page factory is not IoC:Nobody says that a Spring context is the only valid container in anapplication. The page factory just becomes part of the this logical
container, it is aware of and cooperates with the Sprint context.
But your page factory is not a container - it is a factory. After it
creates the object it is no longer aware of its existence. If i then
create a page with a dependency on the previous page created will that
dependency be resolved? no. If you say that the page factory is
an ioc container, then i can argue that any class with a factory method
is an ioc container.

Is this class its own ioc container?

SomeClass c=SomeClass.createInstance(a,b,c);

 IMHO to satisfy all possible requirements, these hooks shouldn't belocated on the pages.
It is easier to call from stateless code into stateful code (i.e.RequestCycle - Page) than the other way around.
Wicket is an unmanaged framework, so the pages do not have a lifecycle
that wicket maintains - they are pojos. So how can you expect wicket to
provide callbacks for pages when certain events that are outside of
wicket's control occur?

-Igor

Re: Re: [Wicket-user] My take on Spring integration

I agree. This is how the project im working on right now works. We have
an iwebapplicationfactory that lets spring create the application
object and pulls in all the services in with it. Then a getter in the
page looks something like this:

UserService getUserService() { MyApplication.getInstance().getUserService(); }

very clean and simple. Sure the application object now has A LOT of dependencies, but so what?

but people are saying this isnt good enough, they want to declare
dependencies on the page level and not the application level. so im
just trying to help them find a clean simple solution for that.
something that is elegant enough to be maintained as a wicket-stuff
project and become a standard way which is what people want.

-Igor
On 11/7/05, Gustavo Hexsel [EMAIL PROTECTED] wrote:
I don't have an answer for the problem, so I'll just give my Free Rant (sorry, can't charge 2 cents for it :)One
of the reasons why Spring (and IoC in general) is so elegant, is
because it usually doesn't add a new dependency to your
classes.Only a couple of root application classes need to
know that Spring is there at all.If for any reason you find
out that Spring configuration XML is rotten for projects over 100
configured objects(i.e. for performance or
maintainability), you just pull out the root object and redo the
configuration in code or using another library.Adding a
coupling to spring in each class is much less flexible.It
might sound far-fetched, but I've done exactly that... IoC ruled but
the spring configuration xml was a royal pain in the butt as it
grew.IDEA (or any other IDE AFAIK) can't refactor into it,
so all changes to object interfaces have to be done by hand.[]s Gus-- Início da mensagem original ---De: [EMAIL PROTECTED]
Para: wicket-user@lists.sourceforge.netCc:Data: Mon, 7 Nov 2005 13:56:39 -0200 Assunto: Re: Re: [Wicket-user] My take on Spring integration
PS.: Someone responded this thread in a way that gmail (only gmail?) could not find it associated with previous messages, I hope people continue to discuss and keep this, and not open a new thread with (AW:
Re: Re: My take on Spring integration). Igor, the class you have implemented is exactly the way I was thinking. However Sven pointed out correctly that this is not really IoC, since the component itself is looking for its dependencies
(Alexandru said that even before...). But even if it is not IoC, I think this is a nice approach. The client code it would look exactly like a really IoC implementation (if getSpringContext() is implemented in another way). And if I can live
with the Page constructor automatically attaching itself to the Session, I could live with Pages doing serialization as well. That said, a really IoC approach seems to be achieved either using AOP
or doing something with onBeginRequest/onBeginResponse, as Sven, Juergen and Johan said before. 2005/11/7, Johan Compagner [EMAIL PROTECTED]
: And there is also a thing like XML Serialization Which also doesn't use the java read/write object at all. On 11/7/05, Christian Essl
[EMAIL PROTECTED] wrote: Hi Igor, I looked through your code. Thanks for implementing it. I am not sure wheter readObject() is the right place to do the (re)injection. According
to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be called on session-attributes. (Insteadsession attributes which implement HttpSessionActiviationListeners are informed on deserialization). Even if
readObject is called I am not sure wheter there is an ApplicationContext to get to the BeanContext. I don't know wheter wicket has a mean to propogate these HttpSessionEvents
on deserialization or a similar callback? If so I guess you could do the (re)injection there. Christian On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote: here is something i threw together that solves the deserialization andability to use the new operator to create pages. atleast i think it
doesits really late here and all i really know so far is that itcompiles :) the idea is pretty simple, do the injection in the default constructor,
andthen do it anytime the object is deserialized. you use a @SpringBeanannotation to denote the dependency. it can either be used on a field oron
a setter. If you specify the bean name it will be used to find the bean,ifyou dont then the field's type or the setters argument type will be used
forthe lookup. -Igor On 11/7/05, Igor Vaynberg
[EMAIL PROTECTED] wrote: and you have to have the pages defined as beans in the applicationcontext? with their properties specified?
-Igor On 11/7/05, Igor Vaynberg [EMAIL PROTECTED]
wrote: but how does the above handle deserealization of pages? there isnothing to reinject the dependencies.
-Igor On 11/7/05, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote

Re: Re: [Wicket-user] My take on Spring integration

That's right. That's propably the cleanest way and you can use it on each 
component.


The problem why I came up with the constructor aproach initially was that 
generally all the subcomponents are created and setup in the constructor. 
And it would than be IMO more wicket like if you can also inject the 
services directly in the constructor, witout breaking up the setup of the 
subcomponents between the constructor and some setters.


IMO this is a general problem with setter based DI and hierarchical 
structures.


Christian

On Mon, 7 Nov 2005 15:16:53 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:


but why not replace every references thats annotated as a bean with a 
proxy

that only initializes itself as opposed to the entire class? that way you
dont even need the doinjection() method in the class and its a lot safer.

I would even put this decoration into a separate factory so that the 
page
stays a simple dumb pojo with some annotations on it.That way you can 
have a

factory that pulls dependencies out of spring, or out of our builtin
metadata system, or out of somewhere else.

code would look something like this:

MyPage page=SpringDecorator.decorate(new MyPage(a,b,c));

this would look like this:

SpringDecorator.decorate (Page page) {
for each field with SpringBean annotation in page
set value to a new SpringDepdencyProxy
end
return page;
}

and the SpringDependencyProxy would look like this:

transient targetobject;

if (targetobject is null) {
locate spring context and set targetobject to the lookup
}
forward call to targetobject;


this way the class need not be aware of the fact that its decorated with
proxies or implement anything special. the proxies get serialized and
deserialized normally.

-Igor


On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:


Unfortunately I think this does not work.

Actually cglib creates at runtime a subclass where you can override
methods and as with any java code you can not override final (or 
private)
methods. So when a non overridable method is called on the proxy it is 
not

possible to delegate it and any state changes will only happen in the
proxy and not in the proxied (real) page. On the other hand if the 
proxied
instance calls one of its methods they will only effect its state and 
not

the state of the proxy.

Because of this and because the cglib proxy as a subclass also carries
everything constructed in the cunstructor of the superclass I do not 
realy

like cglib proxies.

But why not make it something like this (pseudo code - not tested):

public class AbstractSpringAwarePage extends WebPage
{
public AbstractSpringAwarePage()
{
super();
doInjection();
}

private final void readObject(java.io.ObjectInputStream in) throws
IOException,
ClassNotFoundException
{
in.defaultReadObject();
//do for fields only now
Class cl = this.getClass();
while(cl != null  !AbstractSpringAwarePage.class.equals(cl)){
Field[] fields = cl.getDeclaredFields();
for(final Field field:fields){
//if field has spring annotation and it has a declaring class as
interface

//create a proxy
InvocationHandler iH = new InvocationHandler(){
private transient Object _target;
public Object invoke(Object proxy, Method method, Object[]
args) throws Throwable
{
if(_target == null){
doInjection();
_target = field.get(AbstractSpringAwarePage.this);
}
return method.invoke(_target, args);
}
};
Class proxyClass = field.getDeclaringClass();
Object serviceProxy = Proxy.newProxyInstance(
Thread.currentThread().getContextClassLoader(),
new Class[]{proxyClass}, iH);
///
//assign serviceProxy to field
}
cl = cl.getSuperclass();
}
}

/**
* Override to load and assign custom beans. WARNING IS CALLED FROM THE
CONSTRUCTOR
* DO NOT DEPEND ON STATE SET IN THE CONSTRUCTOR. DO NOT CALL METHODS
WHICH DEPEND
* ON INSTANCE STATE. DO NOT LET LEAK A REFERNCE TO THIS INSTANCE OUT.
*/
protected void doInjection()
{
// Default implementation as Igor has.
}
}


Sure this is not DI. It also does not provide AOP, livecylcle-management
etc as a container does. It is also not elegant with the constructor
calling the doInjection() method and it's magic.

However it is sugar for lookup. ie:

class MyPage(){
@SpringBean(customerdao)
protected CustomerDAO _customerDao; //no getter/setter

public void someWhere(){
_mydao.getCustomer(id);
}
}

during testing:

MyPage page = new MyPage(){
protected void doInjection(){
_customerDao = new MockDAO();
}
};

And you have the service ready in the constructor in case you want to 
give

it further to a component you construct in the constructor.



On Mon, 7 Nov 2005 12:27:12 -0800, Igor Vaynberg 
[EMAIL PROTECTED]

wrote:

 yes. but instead of doing the injection right away the proxy would do
 injection-on-first-access.
 that way you get lazy injection and strongly typed pages.

 so you would annotate getter functions with the @SpringBean annot, and
 the
 proxy would first call the getter ... if the getter returns null the
 proxy
 would then look for the setter and

Re: Re: [Wicket-user] My take on Spring integration


I think there should be both of your implementations.

IMO the constructor based impl should have the protected doInject method, 
because to me it seems to be the easiest way to inject manually services 
in the constructor without the need to manually proxy them.


Yes with cglib we'll hit the final problem. I think - don't know - we'll 
need also a default constructor. Anyway spring runs into the same problem 
if it uses ie transaction proxies because spring does also use cglib for 
non interface based AOP. Maybe use spring AOP directly, which is well 
tested and performend.


To me it would be fine to only use interfaces, because in the end those 
things are services I want to replace for mocking, remoting or whatsoever. 
So interfaces are a good (recomended) practice.


By the way we could also create an EJBInjection annotation.

Christian



On Mon, 7 Nov 2005 16:22:02 -0800, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



but using that same idea, there is nothing stopping you from creating a
subclass that calls the decorating factory from the constructor.

So some of these init proxies are going to have to be cglib proxies? We 
can
check if the field's type is an interface, and if so we can create a 
regular

proxy, but if its not we try to create a cglib proxy? Do we hit the same
final method drawbacks?

-Igor


On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:


That's right. That's propably the cleanest way and you can use it on 
each

component.

The problem why I came up with the constructor aproach initially was 
that
generally all the subcomponents are created and setup in the 
constructor.

And it would than be IMO more wicket like if you can also inject the
services directly in the constructor, witout breaking up the setup of 
the

subcomponents between the constructor and some setters.

IMO this is a general problem with setter based DI and hierarchical
structures.

Christian

On Mon, 7 Nov 2005 15:16:53 -0800, Igor Vaynberg 
[EMAIL PROTECTED]

wrote:

 but why not replace every references thats annotated as a bean with a
 proxy
 that only initializes itself as opposed to the entire class? that way
you
 dont even need the doinjection() method in the class and its a lot
safer.

 I would even put this decoration into a separate factory so that the
 page
 stays a simple dumb pojo with some annotations on it.That way you can
 have a
 factory that pulls dependencies out of spring, or out of our builtin
 metadata system, or out of somewhere else.

 code would look something like this:

 MyPage page=SpringDecorator.decorate(new MyPage(a,b,c));

 this would look like this:

 SpringDecorator.decorate (Page page) {
 for each field with SpringBean annotation in page
 set value to a new SpringDepdencyProxy
 end
 return page;
 }

 and the SpringDependencyProxy would look like this:

 transient targetobject;

 if (targetobject is null) {
 locate spring context and set targetobject to the lookup
 }
 forward call to targetobject;


 this way the class need not be aware of the fact that its decorated 
with

 proxies or implement anything special. the proxies get serialized and
 deserialized normally.

 -Igor


 On 11/7/05, Christian Essl [EMAIL PROTECTED] wrote:

 Unfortunately I think this does not work.

 Actually cglib creates at runtime a subclass where you can override
 methods and as with any java code you can not override final (or
 private)
 methods. So when a non overridable method is called on the proxy it 
is

 not
 possible to delegate it and any state changes will only happen in the
 proxy and not in the proxied (real) page. On the other hand if the
 proxied
 instance calls one of its methods they will only effect its state and
 not
 the state of the proxy.

 Because of this and because the cglib proxy as a subclass also 
carries

 everything constructed in the cunstructor of the superclass I do not
 realy
 like cglib proxies.

 But why not make it something like this (pseudo code - not tested):

 public class AbstractSpringAwarePage extends WebPage
 {
 public AbstractSpringAwarePage()
 {
 super();
 doInjection();
 }

 private final void readObject(java.io.ObjectInputStream in) throws
 IOException,
 ClassNotFoundException
 {
 in.defaultReadObject();
 //do for fields only now
 Class cl = this.getClass();
 while(cl != null  !AbstractSpringAwarePage.class.equals(cl)){
 Field[] fields = cl.getDeclaredFields();
 for(final Field field:fields){
 //if field has spring annotation and it has a declaring class as
 interface

 //create a proxy
 InvocationHandler iH = new InvocationHandler(){
 private transient Object _target;
 public Object invoke(Object proxy, Method method, Object[]
 args) throws Throwable
 {
 if(_target == null){
 doInjection();
 _target = field.get(AbstractSpringAwarePage.this);
 }
 return method.invoke(_target, args);
 }
 };
 Class proxyClass = field.getDeclaringClass();
 Object serviceProxy = Proxy.newProxyInstance(
 Thread.currentThread().getContextClassLoader(),
 new

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Eduardo Rocha

I think Christian's idea is nice, and I saw at least three comments against it:

1. It is necessary to call injectDependencies on deserialization (Igor)

If a component implements protected Object readResolve() throws
ObjectStreamException, as specified in Serializable class, I think
this could be handled, what do you think?

2. The component itself would do lookups (Alexandru).

Yes, but it would be a base class, and as a user you would never see
as your component doing the lookup. Otherwise, as said in a previous
thread, there could be a phase in the RequestCycle responsible for
injecting things, and that would also solve the issue (1).

3. You should never ever call a overridable method in a constructor (Eelco).

Make it final?

2005/10/27, Christian Essl [EMAIL PROTECTED]:
 On Thu, 27 Oct 2005 16:15:37 -0700, Eelco Hillenius
 [EMAIL PROTECTED] wrote:

  Furthermore, you should never ever call a overridable method in a
  constructor.

 You are right. It must be commented to not be dependent on any state set
 of the constructors below this magic helper class. Apart of this
 overriding is generaly a bit dangerous if you don't read the comment well
 and don't know when it is called.

 Anyway it was just an idea. I like this 'injection' thing just not AOP.

 Christian

 
  Eelco
 
  On 10/27/05, Alexandru Popescu [EMAIL PROTECTED]
  wrote:
  #: Christian Essl changed the world a bit at a time by saying on
  10/28/2005 12:54 AM :#
   Is AOP realy needed for that?
  
   Propably I do not understand the problem but why can't you just write
  a
   special Panel, Page etc which calls an overrideable
  injectDependencies()
   method in the constructor. The default implementation of
   injectDependencies() does basicly read the annotations, lookup the
   services and inject them?
 
  Because in this case the component itself does the lookup. And this is
  not what you really want.
 
  ./alex
  --
  .w( the_mindstorm )p.
 
  I think this way you could on an instance by
   instance basis fine-grain control what gets injected. And during
  testing
   you just inject the mocks in this overriden method.
  
   Just my two cents.
  
   Thanks,
   Christian
  
   On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
   [EMAIL PROTECTED] wrote:
  
  
   On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:
  
   BTW rather than letting panels pull service from the page, I'd
  prefer
   the page to push services into its panels (i.e. the page  injects
   dependencies into its panels).
   I don't want my panels to be dependent on the containing page.
  
   Yup. That is exactly what I do.
  
   But. I just moved the aspect from WebPage to Component and guess
  what,
   the annotation and bean resolving works fine in Panels and
   WebComponents too now :-)
  
   It is still to hackerish to use btw. There are some really nasty
  delays
   for example. I need to find some time to polish this.
  
 S.
  
  
  
   ---
   This SF.Net email is sponsored by the JBoss Inc.
   Get Certified Today * Register for a JBoss Training Course
   Free Certification Exam for All Training Attendees Through End of
  2005
   Visit http://www.jboss.com/services/certification for more
  information
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
 
 
 
  ---
  This SF.Net email is sponsored by the JBoss Inc.
  Get Certified Today * Register for a JBoss Training Course
  Free Certification Exam for All Training Attendees Through End of 2005
  Visit http://www.jboss.com/services/certification for more information
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
  ---
  This SF.Net email is sponsored by the JBoss Inc.
  Get Certified Today * Register for a JBoss Training Course
  Free Certification Exam for All Training Attendees Through End of 2005
  Visit http://www.jboss.com/services/certification for more information
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user



 --
 Christian Essl





 ___
 Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: 
 http://mail.yahoo.de



 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course
 Free Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more information
 ___
 Wicket-user

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Eduardo Rocha

Make it final?

I personally dislike Wicket's final methods, but I would like to read
people's opinion :) - and in this case it is the easiest way.

2005/11/6, Eduardo Rocha [EMAIL PROTECTED]:
 I think Christian's idea is nice, and I saw at least three comments against 
 it:

 1. It is necessary to call injectDependencies on deserialization (Igor)

 If a component implements protected Object readResolve() throws
 ObjectStreamException, as specified in Serializable class, I think
 this could be handled, what do you think?

 2. The component itself would do lookups (Alexandru).

 Yes, but it would be a base class, and as a user you would never see
 as your component doing the lookup. Otherwise, as said in a previous
 thread, there could be a phase in the RequestCycle responsible for
 injecting things, and that would also solve the issue (1).

 3. You should never ever call a overridable method in a constructor (Eelco).

 Make it final?

 2005/10/27, Christian Essl [EMAIL PROTECTED]:
  On Thu, 27 Oct 2005 16:15:37 -0700, Eelco Hillenius
  [EMAIL PROTECTED] wrote:
 
   Furthermore, you should never ever call a overridable method in a
   constructor.
 
  You are right. It must be commented to not be dependent on any state set
  of the constructors below this magic helper class. Apart of this
  overriding is generaly a bit dangerous if you don't read the comment well
  and don't know when it is called.
 
  Anyway it was just an idea. I like this 'injection' thing just not AOP.
 
  Christian
 
  
   Eelco
  
   On 10/27/05, Alexandru Popescu [EMAIL PROTECTED]
   wrote:
   #: Christian Essl changed the world a bit at a time by saying on
   10/28/2005 12:54 AM :#
Is AOP realy needed for that?
   
Propably I do not understand the problem but why can't you just write
   a
special Panel, Page etc which calls an overrideable
   injectDependencies()
method in the constructor. The default implementation of
injectDependencies() does basicly read the annotations, lookup the
services and inject them?
  
   Because in this case the component itself does the lookup. And this is
   not what you really want.
  
   ./alex
   --
   .w( the_mindstorm )p.
  
   I think this way you could on an instance by
instance basis fine-grain control what gets injected. And during
   testing
you just inject the mocks in this overriden method.
   
Just my two cents.
   
Thanks,
Christian
   
On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
[EMAIL PROTECTED] wrote:
   
   
On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:
   
BTW rather than letting panels pull service from the page, I'd
   prefer
the page to push services into its panels (i.e. the page  injects
dependencies into its panels).
I don't want my panels to be dependent on the containing page.
   
Yup. That is exactly what I do.
   
But. I just moved the aspect from WebPage to Component and guess
   what,
the annotation and bean resolving works fine in Panels and
WebComponents too now :-)
   
It is still to hackerish to use btw. There are some really nasty
   delays
for example. I need to find some time to polish this.
   
  S.
   
   
   
---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of
   2005
Visit http://www.jboss.com/services/certification for more
   information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
   
   
   
  
  
  
   ---
   This SF.Net email is sponsored by the JBoss Inc.
   Get Certified Today * Register for a JBoss Training Course
   Free Certification Exam for All Training Attendees Through End of 2005
   Visit http://www.jboss.com/services/certification for more information
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
  
   ---
   This SF.Net email is sponsored by the JBoss Inc.
   Get Certified Today * Register for a JBoss Training Course
   Free Certification Exam for All Training Attendees Through End of 2005
   Visit http://www.jboss.com/services/certification for more information
   ___
   Wicket-user mailing list
   Wicket-user@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
  --
  Christian Essl
 
 
 
 
 
  ___
  Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier 
  anmelden: http://mail.yahoo.de

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Alexandru Popescu

#: Eduardo Rocha changed the world a bit at a time by saying on 11/6/2005 3:51
PM :#

I think Christian's idea is nice, and I saw at least three comments against it:

1. It is necessary to call injectDependencies on deserialization (Igor)

If a component implements protected Object readResolve() throws
ObjectStreamException, as specified in Serializable class, I think
this could be handled, what do you think?

Yes - or at least this is what is supposed to be the correct way to handle it.

2. The component itself would do lookups (Alexandru).

Yes, but it would be a base class, and as a user you would never see
as your component doing the lookup. Otherwise, as said in a previous
thread, there could be a phase in the RequestCycle responsible for
injecting things, and that would also solve the issue (1).

The idea of the RequestCycle doing also injection is one that I like. Unfortunately it will not be
able to solve the page/component injection. Wicket is encouragging the usage of normal Java
constructors for adding pages, components, etc. For having automatic injection on these I really
don't see any good solution other than aop ;-).

./alex
--
.w( the_mindstorm )p.

3. You should never ever call a overridable method in a constructor (Eelco).

Make it final?

2005/10/27, Christian Essl [EMAIL PROTECTED]:

On Thu, 27 Oct 2005 16:15:37 -0700, Eelco Hillenius
[EMAIL PROTECTED] wrote:

Furthermore, you should never ever call a overridable method in a
constructor.

You are right. It must be commented to not be dependent on any state set
of the constructors below this magic helper class. Apart of this
overriding is generaly a bit dangerous if you don't read the comment well
and don't know when it is called.

Anyway it was just an idea. I like this 'injection' thing just not AOP.

Christian

Eelco

On 10/27/05, Alexandru Popescu [EMAIL PROTECTED]
wrote:
#: Christian Essl changed the world a bit at a time by saying on
10/28/2005 12:54 AM :#
Is AOP realy needed for that?

Because in this case the component itself does the lookup. And this is
not what you really want.

./alex
--
.w( the_mindstorm )p.

I think this way you could on an instance by
instance basis fine-grain control what gets injected. And during
testing
you just inject the mocks in this overriden method.

Just my two cents.

Thanks,
Christian

On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
[EMAIL PROTECTED] wrote:

On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:

BTW rather than letting panels pull service from the page, I'd
prefer
the page to push services into its panels (i.e. the page injects
dependencies into its panels).
I don't want my panels to be dependent on the containing page.

Yup. That is exactly what I do.

But. I just moved the aspect from WebPage to Component and guess
what,
the annotation and bean resolving works fine in Panels and
WebComponents too now :-)

It is still to hackerish to use btw. There are some really nasty
delays
for example. I need to find some time to polish this.

--
Christian Essl

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Eduardo Rocha

2005/11/6, Alexandru Popescu [EMAIL PROTECTED]:
 #: Eduardo Rocha changed the world a bit at a time by saying on  11/6/2005 
 3:51 PM :#
  I think Christian's idea is nice, and I saw at least three comments against 
  it:
 
  1. It is necessary to call injectDependencies on deserialization (Igor)
 
  If a component implements protected Object readResolve() throws
  ObjectStreamException, as specified in Serializable class, I think
  this could be handled, what do you think?
 

 Yes - or at least this is what is supposed to be the correct way to handle it.

  2. The component itself would do lookups (Alexandru).
 
  Yes, but it would be a base class, and as a user you would never see
  as your component doing the lookup. Otherwise, as said in a previous
  thread, there could be a phase in the RequestCycle responsible for
  injecting things, and that would also solve the issue (1).
 

 The idea of the RequestCycle doing also injection is one that I like. 
 Unfortunately it will not be
 able to solve the page/component injection. Wicket is encouragging the usage 
 of normal Java
 constructors for adding pages, components, etc. For having automatic 
 injection on these I really
 don't see any good solution other than aop ;-).


It could be a setter injection. Personally I think that using a
service in the constructor is not the way to go, I prefer to delay the
use of a service when is really needed. So the calls to the service
should be in one of onBeginXXX, when the RequestCycle should already
have injected the service.


 ./alex
 --
 .w( the_mindstorm )p.

  3. You should never ever call a overridable method in a constructor (Eelco).
 
  Make it final?
 
  2005/10/27, Christian Essl [EMAIL PROTECTED]:
  On Thu, 27 Oct 2005 16:15:37 -0700, Eelco Hillenius
  [EMAIL PROTECTED] wrote:
 
   Furthermore, you should never ever call a overridable method in a
   constructor.
 
  You are right. It must be commented to not be dependent on any state set
  of the constructors below this magic helper class. Apart of this
  overriding is generaly a bit dangerous if you don't read the comment well
  and don't know when it is called.
 
  Anyway it was just an idea. I like this 'injection' thing just not AOP.
 
  Christian
 
  
   Eelco
  
   On 10/27/05, Alexandru Popescu [EMAIL PROTECTED]
   wrote:
   #: Christian Essl changed the world a bit at a time by saying on
   10/28/2005 12:54 AM :#
Is AOP realy needed for that?
   
Propably I do not understand the problem but why can't you just write
   a
special Panel, Page etc which calls an overrideable
   injectDependencies()
method in the constructor. The default implementation of
injectDependencies() does basicly read the annotations, lookup the
services and inject them?
  
   Because in this case the component itself does the lookup. And this is
   not what you really want.
  
   ./alex
   --
   .w( the_mindstorm )p.
  
   I think this way you could on an instance by
instance basis fine-grain control what gets injected. And during
   testing
you just inject the mocks in this overriden method.
   
Just my two cents.
   
Thanks,
Christian
   
On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
[EMAIL PROTECTED] wrote:
   
   
On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:
   
BTW rather than letting panels pull service from the page, I'd
   prefer
the page to push services into its panels (i.e. the page  injects
dependencies into its panels).
I don't want my panels to be dependent on the containing page.
   
Yup. That is exactly what I do.
   
But. I just moved the aspect from WebPage to Component and guess
   what,
the annotation and bean resolving works fine in Panels and
WebComponents too now :-)
   
It is still to hackerish to use btw. There are some really nasty
   delays
for example. I need to find some time to polish this.
   
  S.
   
 
 
  --
  Christian Essl
 
 



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

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Igor Vaynberg

Or how about a simple solution:

public MyApplication extends WebApplication {
 public Object lookup(String name) {
 Object=...do a lookup from somewhere like spring context or app object...;
 return object;
 }
}

public MyPage extends Page {
 public transient SomeService service;

 public SomeService getService() {
 if (service==null) {
 service=getApplication().lookup(SomeService.class.getName());
 }
 return service;
}

I know its not quiete as elegant as ioc but it has none of the
performance hits an automatic injection would cause if it would be done
on deserialization of every component. Also its a lazy lookup so you
dont do it until its needed, and its only done once per page (until it
gets deserialized).

-Igor

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Igor Vaynberg

you are right, this is not ioc. but are pages/components managed by an ioc container?
-Igor
On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
#: Igor Vaynberg changed the world a bit at a time by saying on11/6/2005 7:06 PM :# Or how about a simple solution: public MyApplication extends WebApplication { public Object lookup(String name) {
 Object=...do a lookup from somewhere like spring context or app object...; return object; } } public MyPage extends Page { public transient SomeService service;
 public SomeService getService() { if (service==null) { service=getApplication().lookup(SomeService.class.getName()); } return service; } I know its not quiete as elegant as ioc but it has none of the performance
 hits an automatic injection would cause if it would be done on deserialization of every component. Also its a lazy lookup so you dont do it until its needed, and its only done once per page (until it gets
 deserialized). -IgorBut this was exactly what I was suggesting to avoid ;-). Lookups and factories are not ioc/di../alex--.w( the_mindstorm )p.---
SF.Net email is sponsored by:Tame your development challenges with Apache's Geronimo App Server. Downloadit for free - -and be entered to win a 42 plasma tv or your very ownSony(tm)PSP.Click here to play: 
http://sourceforge.net/geronimo.php___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Eelco Hillenius

I see absolutely nothing wrong with lookups at that level. It's less
code than you would need for any component configuration and it's more
efficient too. And there are just no disadvantages, are there?

And... for this whole discussion: if you like one approach... go
implement it now! Create your own component factory, annotations
processor, aop, and please contribute when you've got something nice
working. Or let us know when you need specific changes to Wicket to
support your needs. We'll most probably honor such requests if they
are reasonable as we've done in the past.

Eelco


On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
 #: Igor Vaynberg changed the world a bit at a time by saying on  11/6/2005 
 7:06 PM :#
  Or how about a simple solution:
 
  public MyApplication extends WebApplication {
  public Object lookup(String name) {
  Object=...do a lookup from somewhere like spring context or app object...;
  return object;
  }
  }
 
  public MyPage extends Page {
  public transient SomeService service;
 
  public SomeService getService() {
  if (service==null) {
  service=getApplication().lookup(SomeService.class.getName());
  }
  return service;
  }
 
  I know its not quiete as elegant as ioc but it has none of the performance
  hits an automatic injection would cause if it would be done on
  deserialization of every component. Also its a lazy lookup so you dont do it
  until its needed, and its only done once per page (until it gets
  deserialized).
 
  -Igor
 

 But this was exactly what I was suggesting to avoid ;-). Lookups and 
 factories are not ioc/di.

 ./alex
 --
 .w( the_mindstorm )p.



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

Re: [Wicket-user] My take on Spring integration

2005-11-06 Thread Alexandru Popescu


#: Eelco Hillenius changed the world a bit at a time by saying on  11/6/2005 
9:38 PM :#

I see absolutely nothing wrong with lookups at that level. It's less
code than you would need for any component configuration and it's more
efficient too. And there are just no disadvantages, are there?

And... for this whole discussion: if you like one approach... go
implement it now! Create your own component factory, annotations
processor, aop, and please contribute when you've got something nice
working. Or let us know when you need specific changes to Wicket to
support your needs. We'll most probably honor such requests if they
are reasonable as we've done in the past.

Eelco




My single contribution to this discussion was not to proove something is bad, but rather to 
understand others points of view and also to feedback my understanding regarding ioc/di. Considering 
this, I would probably still be able to point you that lookup is not bad per se, but it is not 
ioc/di. Sure, there are a few disadvantages when compairing these 2, and iirc these are presented in 
Spring discussions.


As regards implementing it: when reaching the point where I would need them, if nothing is available 
I will definitely come out with something. As, maybe some of the people here are aware, I am 
involved in oss projects for quite a while, so if this will be the case I will do my best to 
contribute them back to the community.


cheers,

./alex
--
.w( the_mindstorm )p.


On 11/6/05, Alexandru Popescu [EMAIL PROTECTED] wrote:

#: Igor Vaynberg changed the world a bit at a time by saying on  11/6/2005 7:06 
PM :#
 Or how about a simple solution:

 public MyApplication extends WebApplication {
 public Object lookup(String name) {
 Object=...do a lookup from somewhere like spring context or app object...;
 return object;
 }
 }

 public MyPage extends Page {
 public transient SomeService service;

 public SomeService getService() {
 if (service==null) {
 service=getApplication().lookup(SomeService.class.getName());
 }
 return service;
 }

 I know its not quiete as elegant as ioc but it has none of the performance
 hits an automatic injection would cause if it would be done on
 deserialization of every component. Also its a lazy lookup so you dont do it
 until its needed, and its only done once per page (until it gets
 deserialized).

 -Igor


But this was exactly what I was suggesting to avoid ;-). Lookups and factories 
are not ioc/di.

./alex
--
.w( the_mindstorm )p.



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





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

RE: [Wicket-user] My take on Spring integration

2005-10-27 Thread Joni Suominen

On Wed, 2005-10-26 at 10:59 -0700, Igor Vaynberg wrote:
 This is similar to how i do it. My application is a spring bean that
 gets injected by spring on creation and is then used as a service
 locator. I am simply questioning the automatic injection into pages,
 does it really make sense if it only takes you half way there. If in
 my panel i need to do a ((MyPage)getPage()).getService() then i might
 as well do ((MyApp)getApplication).getService().

I agree that it is very bad if Spring integration using IOC can only be
done as a half baked solution. However, I see following problems when
using Spring as a service locator.

1. Unit testing components

It is not feasible to unit test wicket components wired with full blown
backend services. We often manually wire the dependencies, which is very
easy in IOC paradigm:

public class MyTest extends TestCase {
 public void setUp() {
 MyComponent myComponent = new MyComponent();
 myComponent.setFinder(new MockFinder()); 
 }
}

2. How to abstract the service locator?

Lets say I'm creating a reusable Dictionary component. I'd like to
abstract away the actual interface to dictionary behind
DictionaryLookupService.

public class Dictionary extends Panel {
private transient DictionaryLookupService dictionaryLookupService;

public void onClick() {
 dictionaryLookupService.findWord(...);
 ...
}
}

This implementation, which expects the implementation of
DictionaryLookupService be injected, does not depend on any particular
page, wicket application or spring API.

-- 
Joni Suominen [EMAIL PROTECTED]



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

RE: [Wicket-user] My take on Spring integration

2005-10-27 Thread Igor Vaynberg

You can set whatever mocks you need in the webapplication class using the
same setters that spring uses. Chances are you are going to need the
webapplication instance present if you are testing wicket anyways as it is a
very central object.

-Igor

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Joni Suominen
 Sent: Thursday, October 27, 2005 2:01 AM
 To: wicket-user@lists.sourceforge.net
 Subject: RE: [Wicket-user] My take on Spring integration
 
 On Wed, 2005-10-26 at 10:59 -0700, Igor Vaynberg wrote:
  This is similar to how i do it. My application is a spring 
 bean that 
  gets injected by spring on creation and is then used as a service 
  locator. I am simply questioning the automatic injection 
 into pages, 
  does it really make sense if it only takes you half way 
 there. If in 
  my panel i need to do a ((MyPage)getPage()).getService() 
 then i might 
  as well do ((MyApp)getApplication).getService().
 
 I agree that it is very bad if Spring integration using IOC 
 can only be done as a half baked solution. However, I see 
 following problems when using Spring as a service locator.
 
 1. Unit testing components
 
 It is not feasible to unit test wicket components wired with 
 full blown backend services. We often manually wire the 
 dependencies, which is very easy in IOC paradigm:
 
 public class MyTest extends TestCase {
  public void setUp() {
  MyComponent myComponent = new MyComponent();
  myComponent.setFinder(new MockFinder()); 
  }
 }
 
 2. How to abstract the service locator?
 
 Lets say I'm creating a reusable Dictionary component. I'd 
 like to abstract away the actual interface to dictionary 
 behind DictionaryLookupService.
 
 public class Dictionary extends Panel {
 private transient DictionaryLookupService dictionaryLookupService;
 
 public void onClick() {
  dictionaryLookupService.findWord(...);
  ...
 }
 }
 
 This implementation, which expects the implementation of 
 DictionaryLookupService be injected, does not depend on any 
 particular page, wicket application or spring API.
 
 --
 Joni Suominen [EMAIL PROTECTED]
 
 
 
 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course
 Free Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more information
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 




---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Sven Meier


Igor Vaynberg wrote:
I am simply questioning the automatic injection into pages, does it really
make sense if it only takes you half way there. If in my panel i need 
to do a

((MyPage)getPage()).getService()
  then i might as well do
((MyApp)getApplication).getService().

IMHO this makes a great difference. In the first case you'll have
PageA
 getService1()
 getService2()
 getService3()
PageB
 getService4()
 getService5()
...

In the latter case you'll have
ApplicationX
 getService1()
 getService2()
 getService3()
 getService4()
 getService5()
 ...

If you'll do this in a large project, your application class will sooner 
or later turn into a sink of services.


BTW rather than letting panels pull service from the page, I'd prefer 
the page to push services into its panels (i.e. the page injects 
dependencies into its panels).

I don't want my panels to be dependent on the containing page.

Just my two cents

Sven


---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Stefan Arentz



On Oct 27, 2005, at 12:26 PM, Alexandru Popescu wrote:

#: Joni Suominen changed the world a bit at a time by saying on   
10/27/2005 11:00 AM :#



On Wed, 2005-10-26 at 10:59 -0700, Igor Vaynberg wrote:


This is similar to how i do it. My application is a spring bean that
gets injected by spring on creation and is then used as a service
locator. I am simply questioning the automatic injection into pages,
does it really make sense if it only takes you half way there. If in
my panel i need to do a ((MyPage)getPage()).getService() then i  
might

as well do ((MyApp)getApplication).getService().

I agree that it is very bad if Spring integration using IOC can  
only be

done as a half baked solution. However, I see following problems when
using Spring as a service locator.



I would say that using IoC/DI as a service locator is already a  
half-baked solution.


This is becoming a religious discussion that I am not very interested  
in :-)


 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Stefan Arentz



On Oct 27, 2005, at 11:00 AM, Joni Suominen wrote:


On Wed, 2005-10-26 at 10:59 -0700, Igor Vaynberg wrote:


This is similar to how i do it. My application is a spring bean that
gets injected by spring on creation and is then used as a service
locator. I am simply questioning the automatic injection into pages,
does it really make sense if it only takes you half way there. If in
my panel i need to do a ((MyPage)getPage()).getService() then i might
as well do ((MyApp)getApplication).getService().



I agree that it is very bad if Spring integration using IOC can  
only be

done as a half baked solution. However, I see following problems when
using Spring as a service locator.

1. Unit testing components

It is not feasible to unit test wicket components wired with full  
blown
backend services. We often manually wire the dependencies, which is  
very

easy in IOC paradigm:

public class MyTest extends TestCase {
 public void setUp() {
 MyComponent myComponent = new MyComponent();
 myComponent.setFinder(new MockFinder());
 }
}


This is of course no problem. In your test cases, simply don't  
activate the aspect that does the lookup and you will be fine. The  
annotation in the component or web page does nothing by itself.




2. How to abstract the service locator?

Lets say I'm creating a reusable Dictionary component. I'd like to
abstract away the actual interface to dictionary behind
DictionaryLookupService.

public class Dictionary extends Panel {
private transient DictionaryLookupService dictionaryLookupService;

public void onClick() {
 dictionaryLookupService.findWord(...);
 ...
}
}

This implementation, which expects the implementation of
DictionaryLookupService be injected, does not depend on any particular
page, wicket application or spring API.


I don't see the problem here :-)

 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Stefan Arentz



On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:


BTW rather than letting panels pull service from the page, I'd  
prefer the page to push services into its panels (i.e. the page  
injects dependencies into its panels).

I don't want my panels to be dependent on the containing page.


Yup. That is exactly what I do.

But. I just moved the aspect from WebPage to Component and guess  
what, the annotation and bean resolving works fine in Panels and  
WebComponents too now :-)


It is still to hackerish to use btw. There are some really nasty  
delays for example. I need to find some time to polish this.


 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Christian Essl

Is AOP realy needed for that?

Propably I do not understand the problem but why can't you just write a
special Panel, Page etc which calls an overrideable injectDependencies()
method in the constructor. The default implementation of
injectDependencies() does basicly read the annotations, lookup the
services and inject them? I think this way you could on an instance by
instance basis fine-grain control what gets injected. And during testing
you just inject the mocks in this overriden method.

Just my two cents.

Thanks,
Christian

On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
[EMAIL PROTECTED] wrote:

On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:

BTW rather than letting panels pull service from the page, I'd prefer
the page to push services into its panels (i.e. the page injects
dependencies into its panels).

I don't want my panels to be dependent on the containing page.

Yup. That is exactly what I do.

But. I just moved the aspect from WebPage to Component and guess what,
the annotation and bean resolving works fine in Panels and
WebComponents too now :-)

It is still to hackerish to use btw. There are some really nasty delays
for example. I need to find some time to polish this.

---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
Christian Essl

___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

RE: [Wicket-user] My take on Spring integration

2005-10-27 Thread Igor Vaynberg

You would also need to call injectDependencies when a page and components
are deserialized from session - the latter can be tricky.

-Igor


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Christian Essl
 Sent: Thursday, October 27, 2005 3:55 PM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] My take on Spring integration
 
 Is AOP realy needed for that?
 
 Propably I do not understand the problem but why can't you 
 just write a special Panel, Page etc which calls an 
 overrideable injectDependencies() method in the constructor. 
 The default implementation of
 injectDependencies() does basicly read the annotations, 
 lookup the services and inject them? I think this way you 
 could on an instance by instance basis fine-grain control 
 what gets injected. And during testing you just inject the 
 mocks in this overriden method.
 
 Just my two cents.
 
 Thanks,
 Christian
 
 On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz 
 [EMAIL PROTECTED] wrote:
 
 
  On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:
 
  BTW rather than letting panels pull service from the page, I'd  
  prefer the page to push services into its panels (i.e. the page  
  injects dependencies into its panels).
  I don't want my panels to be dependent on the containing page.
 
  Yup. That is exactly what I do.
 
  But. I just moved the aspect from WebPage to Component and guess  
  what, the annotation and bean resolving works fine in Panels and 
  WebComponents too now :-)
 
  It is still to hackerish to use btw. There are some really nasty  
  delays for example. I need to find some time to polish this.
 
S.
 
 
 
  ---
  This SF.Net email is sponsored by the JBoss Inc.
  Get Certified Today * Register for a JBoss Training Course Free 
  Certification Exam for All Training Attendees Through End of 2005 
  Visit http://www.jboss.com/services/certification for more 
 information 
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 
 --
 Christian Essl 
 
   
 
   
   
 ___
 Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - 
 Hier anmelden: http://mail.yahoo.de
 
 
 
 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course
 Free Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more information
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 




---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Alexandru Popescu


#: Christian Essl changed the world a bit at a time by saying on  10/28/2005 
12:54 AM :#

Is AOP realy needed for that?

Propably I do not understand the problem but why can't you just write a 
special Panel, Page etc which calls an overrideable injectDependencies() 
method in the constructor. The default implementation of 
injectDependencies() does basicly read the annotations, lookup the 
services and inject them? 


Because in this case the component itself does the lookup. And this is not what 
you really want.

./alex
--
.w( the_mindstorm )p.

I think this way you could on an instance by
instance basis fine-grain control what gets injected. And during testing 
you just inject the mocks in this overriden method.


Just my two cents.

Thanks,
Christian

On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz 
[EMAIL PROTECTED] wrote:




On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:


BTW rather than letting panels pull service from the page, I'd  prefer 
the page to push services into its panels (i.e. the page  injects 
dependencies into its panels).

I don't want my panels to be dependent on the containing page.


Yup. That is exactly what I do.

But. I just moved the aspect from WebPage to Component and guess  what, 
the annotation and bean resolving works fine in Panels and  
WebComponents too now :-)


It is still to hackerish to use btw. There are some really nasty  delays 
for example. I need to find some time to polish this.


  S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user








---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Eelco Hillenius

Furthermore, you should never ever call a overridable method in a constructor.

Eelco

On 10/27/05, Alexandru Popescu [EMAIL PROTECTED] wrote:
 #: Christian Essl changed the world a bit at a time by saying on  10/28/2005 
 12:54 AM :#
  Is AOP realy needed for that?
 
  Propably I do not understand the problem but why can't you just write a
  special Panel, Page etc which calls an overrideable injectDependencies()
  method in the constructor. The default implementation of
  injectDependencies() does basicly read the annotations, lookup the
  services and inject them?

 Because in this case the component itself does the lookup. And this is not 
 what you really want.

 ./alex
 --
 .w( the_mindstorm )p.

 I think this way you could on an instance by
  instance basis fine-grain control what gets injected. And during testing
  you just inject the mocks in this overriden method.
 
  Just my two cents.
 
  Thanks,
  Christian
 
  On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
  [EMAIL PROTECTED] wrote:
 
 
  On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:
 
  BTW rather than letting panels pull service from the page, I'd  prefer
  the page to push services into its panels (i.e. the page  injects
  dependencies into its panels).
  I don't want my panels to be dependent on the containing page.
 
  Yup. That is exactly what I do.
 
  But. I just moved the aspect from WebPage to Component and guess  what,
  the annotation and bean resolving works fine in Panels and
  WebComponents too now :-)
 
  It is still to hackerish to use btw. There are some really nasty  delays
  for example. I need to find some time to polish this.
 
S.
 
 
 
  ---
  This SF.Net email is sponsored by the JBoss Inc.
  Get Certified Today * Register for a JBoss Training Course
  Free Certification Exam for All Training Attendees Through End of 2005
  Visit http://www.jboss.com/services/certification for more information
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 



 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course
 Free Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more information
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Christian Essl

On Thu, 27 Oct 2005 15:56:03 -0700, Igor Vaynberg [EMAIL PROTECTED] 
wrote:



You would also need to call injectDependencies when a page and components
are deserialized from session - the latter can be tricky.



You are right. Maybe construct on deserialization proxies which on first 
call trigger the injectDependencies() and than forward to the actually 
injected service.


Anyway IMO as long as the bean-name is specified in the using class it is 
lookup which you can turn off for testing - and is of course convinient. 
However some key-strokes more can do this as well.


getServiceXY(){
  return _xy == null ? somewhere.getService(xy) : _xy;
}

Christian



-Igor



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christian Essl
Sent: Thursday, October 27, 2005 3:55 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] My take on Spring integration

Is AOP realy needed for that?

Propably I do not understand the problem but why can't you
just write a special Panel, Page etc which calls an
overrideable injectDependencies() method in the constructor.
The default implementation of
injectDependencies() does basicly read the annotations,
lookup the services and inject them? I think this way you
could on an instance by instance basis fine-grain control
what gets injected. And during testing you just inject the
mocks in this overriden method.

Just my two cents.

Thanks,
Christian

On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
[EMAIL PROTECTED] wrote:


 On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:

 BTW rather than letting panels pull service from the page, I'd
 prefer the page to push services into its panels (i.e. the page
 injects dependencies into its panels).
 I don't want my panels to be dependent on the containing page.

 Yup. That is exactly what I do.

 But. I just moved the aspect from WebPage to Component and guess
 what, the annotation and bean resolving works fine in Panels and
 WebComponents too now :-)

 It is still to hackerish to use btw. There are some really nasty
 delays for example. I need to find some time to polish this.

   S.



 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course Free
 Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more
information
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



--
Christian Essl





___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos -
Hier anmelden: http://mail.yahoo.de



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user








---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user




--
Christian Essl 






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de




---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-27 Thread Christian Essl

On Thu, 27 Oct 2005 16:15:37 -0700, Eelco Hillenius
[EMAIL PROTECTED] wrote:

Furthermore, you should never ever call a overridable method in a
constructor.

Anyway it was just an idea. I like this 'injection' thing just not AOP.

Christian

Eelco

On 10/27/05, Alexandru Popescu [EMAIL PROTECTED]
wrote:
#: Christian Essl changed the world a bit at a time by saying on
10/28/2005 12:54 AM :#

Is AOP realy needed for that?

Propably I do not understand the problem but why can't you just write
a
special Panel, Page etc which calls an overrideable
injectDependencies()

method in the constructor. The default implementation of
injectDependencies() does basicly read the annotations, lookup the
services and inject them?

Because in this case the component itself does the lookup. And this is
not what you really want.

./alex
--
.w( the_mindstorm )p.

I think this way you could on an instance by
instance basis fine-grain control what gets injected. And during
testing

you just inject the mocks in this overriden method.

Just my two cents.

Thanks,
Christian

On Thu, 27 Oct 2005 21:50:02 +0200, Stefan Arentz
[EMAIL PROTECTED] wrote:

On Oct 27, 2005, at 9:21 PM, Sven Meier wrote:

BTW rather than letting panels pull service from the page, I'd
prefer

the page to push services into its panels (i.e. the page injects
dependencies into its panels).
I don't want my panels to be dependent on the containing page.

Yup. That is exactly what I do.

But. I just moved the aspect from WebPage to Component and guess
what,

the annotation and bean resolving works fine in Panels and
WebComponents too now :-)

It is still to hackerish to use btw. There are some really nasty
delays

for example. I need to find some time to polish this.

___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
Christian Essl

___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: [Wicket-user] My take on Spring integration

2005-10-26 Thread Alexandru Popescu


#: Stefan Arentz changed the world a bit at a time by saying on  10/26/2005 
6:44 AM :#

On Oct 26, 2005, at 12:39 AM, Alexandru Popescu wrote:

#: Stefan Arentz changed the world a bit at a time by saying on   
10/25/2005 9:58 PM :#



On Oct 25, 2005, at 10:48 PM, Alexandru Popescu wrote:

#: Stefan Arentz changed the world a bit at a time by saying on
10/25/2005 9:32 PM :#




On Oct 25, 2005, at 10:23 PM, Alexandru Popescu wrote:


Stefan I was wondering why annotating the field? At the first
glance it looks the logical choice, but imo the page is the   
object  depending on the service (so the annotation should be  
on  type level).




What do you mean with type level? The HelloWorldPage?
  S.




yep :-). isn't this the way you name an annotations at a `class´   
level? (java.lang.annotation.ElementType.TYPE)


Yup. But I don't see how this would work. How would you specify  
this  one for example:

bean name=blueImageRenderer class=ImageRendererImpl
   property name=color value=blue/
/bean
bean name=yellowImageRenderer class=ImageRendererImpl
   property name=color value=yellow/
/bean
public class FooPage extends WebPage
{
@SpringBeanReference(blueImageRenderer)
transient private ImageRenderer blueImageRenderer;
public setBlueImageRenderer(ImageRenderer blueImageRenderer) {
this. blueImageRenderer = blueImageRenderer;
}
@SpringBeanReference(yellowImageRenderer)
transient private ImageRenderer yellowImageRenderer;
public setYellowImageRenderer(ImageRenderer  
yellowImageRenderer) {

this. yellowImageRenderer = yellowImageRenderer;
}
}
I know it is a silly example :-)
I'm not sure how you would do this on the class level. The  
annotation  there then would have to get both bean name and  
property names in an  array of pair. Makes no sense to me.

  S.



Fair enough :-). Doing some kind of autodiscovery doesn't make  
sense to me neither.


What I can do is make:

  @SpringBeanReference
  transient Foo blueFoo;

default to a bean named 'blueFoo'. It helps a little bit to stop  
repeating identifier names :-)


  S.




Don't think it's worth the effort, as a renaming refactoring will break the 
application :-).

./alex
--
.w( the_mindstorm )p.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user






---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-26 Thread Johan Compagner

I am not a spring expert/user so i am a bit curious when is it all injected?
for example if i do this:

setResponsePage(new UserPage(user));
and that userpage has some spring beans that also must be instantiated?

And then that userpage is serialized how do you inject those beans again?
Did you overwrite the readObject() ??

johan
On 10/25/05, Stefan Arentz [EMAIL PROTECTED] wrote:
On Oct 25, 2005, at 10:48 PM, Alexandru Popescu wrote: #: Stefan Arentz changed the world a bit at a time by saying on 10/25/2005 9:32 PM :# On Oct 25, 2005, at 10:23 PM, Alexandru Popescu wrote:
 Stefan I was wondering why annotating the field? At the first glance it looks the logical choice, but imo the page is the objectdepending on the service (so the annotation should be on
 type level). What do you mean with type level? The HelloWorldPage? S. yep :-). isn't this the way you name an annotations at a `class´
 level? (java.lang.annotation.ElementType.TYPE)Yup. But I don't see how this would work. How would you specify thisone for example:bean name=blueImageRenderer class=ImageRendererImpl
 property name=color value=blue//beanbean name=yellowImageRenderer class=ImageRendererImpl property name=color value=yellow/
/beanpublic class FooPage extends WebPage{@SpringBeanReference(blueImageRenderer)transient private ImageRenderer blueImageRenderer;public setBlueImageRenderer(ImageRenderer blueImageRenderer) {
this. blueImageRenderer = blueImageRenderer;}@SpringBeanReference(yellowImageRenderer)transient private ImageRenderer yellowImageRenderer;public setYellowImageRenderer(ImageRenderer yellowImageRenderer) {
this. yellowImageRenderer = yellowImageRenderer;}}I know it is a silly example :-)I'm not sure how you would do this on the class level. The annotationthere then would have to get both bean name and property names in an
array of pair. Makes no sense to me.S.---This SF.Net email is sponsored by the JBoss Inc.Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005Visit http://www.jboss.com/services/certification for more information___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-26 Thread Alexandru Popescu


#: Johan Compagner changed the world a bit at a time by saying on  10/26/2005 
10:54 AM :#

I am not a spring expert/user so i am a bit curious when is it all injected?
for example if i do this:

setResponsePage(new UserPage(user));
and that userpage has some spring beans that also must be instantiated?

And then that userpage is serialized how do you inject those beans again?
Did you overwrite the readObject() ??

johan




As Stefan explained I guess he is doing a little AOP to inject dependencies: 
something like:

after(UserPage page) returning(): call(UserPage.new(..))  target(page) {
// wire dependencies here
}

Also he said he solved the serialization problem. I assume that the above piece of advice may work 
the same way against a deserialization.


I haven't seen his code yet (I am waiting for it), but this is what I am imagining from watching the 
thread.


hth,

./alex
--
.w( the_mindstorm )p.



On 10/25/05, Stefan Arentz [EMAIL PROTECTED] wrote:



On Oct 25, 2005, at 10:48 PM, Alexandru Popescu wrote:

 #: Stefan Arentz changed the world a bit at a time by saying on
 10/25/2005 9:32 PM :#

 On Oct 25, 2005, at 10:23 PM, Alexandru Popescu wrote:

 Stefan I was wondering why annotating the field? At the first
 glance it looks the logical choice, but imo the page is the
 object depending on the service (so the annotation should be on
 type level).

 What do you mean with type level? The HelloWorldPage?
 S.


 yep :-). isn't this the way you name an annotations at a `class´
 level? (java.lang.annotation.ElementType.TYPE)

Yup. But I don't see how this would work. How would you specify this
one for example:

bean name=blueImageRenderer class=ImageRendererImpl
property name=color value=blue/
/bean

bean name=yellowImageRenderer class=ImageRendererImpl
property name=color value=yellow/
/bean

public class FooPage extends WebPage
{
@SpringBeanReference(blueImageRenderer)
transient private ImageRenderer blueImageRenderer;

public setBlueImageRenderer(ImageRenderer blueImageRenderer) {
this. blueImageRenderer = blueImageRenderer;
}

@SpringBeanReference(yellowImageRenderer)
transient private ImageRenderer yellowImageRenderer;

public setYellowImageRenderer(ImageRenderer yellowImageRenderer) {
this. yellowImageRenderer = yellowImageRenderer;
}
}

I know it is a silly example :-)

I'm not sure how you would do this on the class level. The annotation
there then would have to get both bean name and property names in an
array of pair. Makes no sense to me.

S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user








---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-26 Thread Joni Suominen

On Tue, 2005-10-25 at 18:41 +0200, Stefan Arentz wrote:
 Better idea! Add some AOP and annotation magic to the mix!
 
   public class HelloWorldWebPage extends WebPage
   {
   @SpringBeanReference(dutchHelloWorldService)
   private transient HelloWorldService helloWorldService;
 
   public void setHelloWorldService(HelloWorldService  
 helloWorldService)
   {
   this.helloWorldService = helloWorldService;
   }
 
   public HelloWorldWebPage()
   {
   add(new Label(message, this.helloWorldService.getMessage 
 ()));
   }
   }
 
 I'm using all standard Wicket classes. No weird mixing of Spring  
 specific classes into the hierarchy.

This is very cool stuff! This is IMO just the way how spring integration
should be done (transient fields, IOC + reinjection at proper places). I
have one question though. Is it still possible to instantiate these
components normally so that there's no AOP magic behind? When writing
unit tests there's normally no spring context available. The service
mocks are manually wired instead.

-- 
Joni Suominen [EMAIL PROTECTED]



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-26 Thread Ryan Sonnek

My take on spring integration is that it should only work if you use
the web page factory.  If you instantiate the pages directly using a
custom constructor, you should be expected to pass in the needed
service.  This follows the Good Citizen Pattern
(http://www.picocontainer.org/Good+Citizen) and reduces the magic
involved.

The spring integration should also handle serialization/deserialization...

On 10/26/05, Joni Suominen [EMAIL PROTECTED] wrote:
 On Tue, 2005-10-25 at 18:41 +0200, Stefan Arentz wrote:
  Better idea! Add some AOP and annotation magic to the mix!
 
public class HelloWorldWebPage extends WebPage
{
@SpringBeanReference(dutchHelloWorldService)
private transient HelloWorldService helloWorldService;
 
public void setHelloWorldService(HelloWorldService
  helloWorldService)
{
this.helloWorldService = helloWorldService;
}
 
public HelloWorldWebPage()
{
add(new Label(message, this.helloWorldService.getMessage
  ()));
}
}
 
  I'm using all standard Wicket classes. No weird mixing of Spring
  specific classes into the hierarchy.

 This is very cool stuff! This is IMO just the way how spring integration
 should be done (transient fields, IOC + reinjection at proper places). I
 have one question though. Is it still possible to instantiate these
 components normally so that there's no AOP magic behind? When writing
 unit tests there's normally no spring context available. The service
 mocks are manually wired instead.

 --
 Joni Suominen [EMAIL PROTECTED]



 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course
 Free Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more information
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

RE: [Wicket-user] My take on Spring integration

2005-10-26 Thread Igor Vaynberg

So where does the automatic injection stop? What if I have a panel that
needs a reference to a service? Or a subclass of a component?

-Igor
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Stefan Arentz
 Sent: Wednesday, October 26, 2005 9:56 AM
 To: wicket-user@lists.sourceforge.net
 Subject: Re: [Wicket-user] My take on Spring integration
 
 
 On Oct 26, 2005, at 10:54 AM, Johan Compagner wrote:
 
  I am not a spring expert/user so i am a bit curious when is it all 
  injected?
  for example if i do this:
 
  setResponsePage(new UserPage(user));
  and that userpage has some spring beans that also must be 
  instantiated?
 
 That works. I am doing this right before the constructor of 
 the page is executed.
 
 
  And then that userpage is serialized how do you inject those beans  
  again?
  Did you overwrite the readObject() ??
 
 Yes. But this needs better testing. I think it works but I'm 
 not sure  
 if I hit all the persistence cases. Eelco send me hints about 
 forcing  
 serialization through  
 log4j.logger.wicket.protocol.http.WebSession=DEBUG.
 
 It is on the agenda for tonight :-)
 
   S.
 
 
 
 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course
 Free Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more information
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 




---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-26 Thread Nick Heudecker

My Application class has access to the bean factory. If a Panel
or a Link needs something, I just get it from there. This might
not be the best way to do it within Wicket, but ignorance is
bliss. 
On 10/26/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
So where does the automatic injection stop? What if I have a panel thatneeds a reference to a service? Or a subclass of a component?-Igor

Re: [Wicket-user] My take on Spring integration

2005-10-26 Thread Stefan Arentz



On Oct 26, 2005, at 7:49 PM, Igor Vaynberg wrote:

So where does the automatic injection stop? What if I have a panel  
that

needs a reference to a service? Or a subclass of a component?


Good question. I think I'm going with this:

* Pages are application specific and thus can have references to an  
application specific bean factory.


* Components should be generic and not directly tied to a specific  
application. So instead of the static configuration using annotations  
the component should have dynamic/programmatic configuration from  
within the page that uses it.


I know it is not perfect. But for me the current setup works ok.

 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

AW: Re: Re: [Wicket-user] My take on Spring integration

2005-10-25 Thread sven

An EditUserPage for example cannot be bookmarkable
because it needs to know which user to edit.

IMHO an EditUserPage parameterized with a userId is a perfect match for a 
bookmarkable URL.

I didn't say, I'd never use setResponsePage(..).
If I have large transactional state to be transferred to another page, I'd use 
setResponsePage(..) too. But I have no problem in this case to delegate the 
construction of the page to a factory.

Sven

Furthermore, it is an excellent way of passing models/ other state to pages.

Eelco

On 10/24/05, Johan Compagner [EMAIL PROTECTED] wrote:
 i completely agree with igor.
  I use setResponsePage(new XxxPage(yy)) all over the place.
  I find this kind of code the most readable what you can get.
  No magic. A person can directly see what really happens.

  johan



 On 10/24/05, Igor Vaynberg [EMAIL PROTECTED] wrote:
2) to use the page factory your pages can only have the default or
PageParameter constructors. This prevents you from doing
   things like
setResponsePage(new EditUserPage(userId));
  
   That is the price to pay for IoC: you have to let the factory
   create the beans.
   BTW I don't think setResponsePage(new ...Page()) is so much
   useful afterall, since AFAIK it prevents bookmarkable links.
 
  Yes, it prevents bookmarkable pages, but do you need every page to be a
  bookmarkable page? An EditUserPage for example cannot be bookmarkable
  because it needs to know which user to edit. If you start putting
  information like the userId into PageParameters you are creating
  soft-dependencies just like urls. A constructor EditUserPage(long userId)
 is
  much more understandable instead of EditUserPage(PageParameters p);
 
  -Igor
 
 
 
 
  ---
  This SF.Net email is sponsored by the JBoss Inc.
  Get Certified Today * Register for a JBoss Training Course
  Free Certification Exam for All Training Attendees Through End of 2005
  Visit http://www.jboss.com/services/certification for
 more information
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 




---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: Re: Re: [Wicket-user] My take on Spring integration

2005-10-25 Thread Johan Compagner

if you want to create youre own page factory. And use PagePArameters
for everything to supply params back and forth you are ofcourse free to
do that right now.
On 10/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
An EditUserPage for example cannot be bookmarkablebecause it needs to know which user to edit.IMHO an EditUserPage parameterized with a userId is a perfect match for a bookmarkable URL.
I didn't say, I'd never use setResponsePage(..).If
I have large transactional state to be transferred to another page, I'd
use setResponsePage(..) too. But I have no problem in this case to
delegate the construction of the page to a factory.SvenFurthermore, it is an excellent way of passing models/ other state to pages.EelcoOn 10/24/05, Johan Compagner 
[EMAIL PROTECTED] wrote: i completely agree with igor.I use setResponsePage(new XxxPage(yy)) all over the place.I find this kind of code the most readable what you can get.
No magic. A person can directly see what really happens.johan On 10/24/05, Igor Vaynberg 
[EMAIL PROTECTED] wrote:2) to use the page factory your pages can only have the default orPageParameter constructors. This prevents you from doing
   things likesetResponsePage(new EditUserPage(userId)); That is the price to pay for IoC: you have to let the factory   create the beans.
   BTW I don't think setResponsePage(new ...Page()) is so much   useful afterall, since AFAIK it prevents bookmarkable links.   Yes, it prevents bookmarkable pages, but do you need every page to be a
  bookmarkable page? An EditUserPage for example cannot be bookmarkable  because it needs to know which user to edit. If you start putting  information like the userId into PageParameters you are creating
  soft-dependencies just like urls. A constructor EditUserPage(long userId) is  much more understandable instead of EditUserPage(PageParameters p);   -Igor
  ---  This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today * Register for a JBoss Training Course
  Free Certification Exam for All Training Attendees Through End of 2005  Visit http://www.jboss.com/services/certification for
 more information  ___  Wicket-user mailing list  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user ---
This SF.Net email is sponsored by the JBoss Inc.Get Certified Today * Register for a JBoss Training CourseFree Certification Exam for All Training Attendees Through End of 2005Visit 
http://www.jboss.com/services/certification for more information___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user---This SF.Net
 email is sponsored by the JBoss Inc.Get Certified Today * Register for a JBoss Training CourseFree Certification Exam for All Training Attendees Through End of 2005Visit 
http://www.jboss.com/services/certification for more information___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration



On Oct 25, 2005, at 11:58 AM, Johan Compagner wrote:

if you want to create youre own page factory. And use  
PagePArameters for everything to supply params back and forth you  
are ofcourse free to do that right now.


Better idea! Add some AOP and annotation magic to the mix!

 public class HelloWorldWebPage extends WebPage
 {
 @SpringBeanReference(dutchHelloWorldService)
 private transient HelloWorldService helloWorldService;

 public void setHelloWorldService(HelloWorldService  
helloWorldService)

 {
 this.helloWorldService = helloWorldService;
 }

 public HelloWorldWebPage()
 {
 add(new Label(message, this.helloWorldService.getMessage 
()));

 }
 }

I'm using all standard Wicket classes. No weird mixing of Spring  
specific classes into the hierarchy.


I think my integration is complete now :-)

The code is a complex mess though. I'll clean this up and put it  
online so that others can look at it or play with it.


 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-25 Thread Ryan Sonnek

Is the annotation really necessary?  can't you use spring's injection
by type?  There will only be one HelloWorldService defined in the
spring configuration.

On 10/25/05, Stefan Arentz [EMAIL PROTECTED] wrote:

 On Oct 25, 2005, at 11:58 AM, Johan Compagner wrote:

  if you want to create youre own page factory. And use
  PagePArameters for everything to supply params back and forth you
  are ofcourse free to do that right now.

 Better idea! Add some AOP and annotation magic to the mix!

   public class HelloWorldWebPage extends WebPage
   {
   @SpringBeanReference(dutchHelloWorldService)
   private transient HelloWorldService helloWorldService;

   public void setHelloWorldService(HelloWorldService
 helloWorldService)
   {
   this.helloWorldService = helloWorldService;
   }

   public HelloWorldWebPage()
   {
   add(new Label(message, this.helloWorldService.getMessage
 ()));
   }
   }

 I'm using all standard Wicket classes. No weird mixing of Spring
 specific classes into the hierarchy.

 I think my integration is complete now :-)

 The code is a complex mess though. I'll clean this up and put it
 online so that others can look at it or play with it.

   S.



 ---
 This SF.Net email is sponsored by the JBoss Inc.
 Get Certified Today * Register for a JBoss Training Course
 Free Certification Exam for All Training Attendees Through End of 2005
 Visit http://www.jboss.com/services/certification for more information
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration



On Oct 25, 2005, at 7:50 PM, Ryan Sonnek wrote:


Is the annotation really necessary?  can't you use spring's injection
by type?  There will only be one HelloWorldService defined in the
spring configuration.


That is a false assumption. As a concrete example, I have two  
'PayPalButtonBuilder' beans in my context. And depending on the page  
that I am on I want to use one of them.


But, you mean Spring's autowiring, right? I'm not sure if it is even  
possible because this integration works the other way around. Spring  
has no idea that these Wicket pages are being created. I have an  
aspect on WebPage's constructor that looks wether one of the callee's  
fields has an annotation. Which is then looked up in the current bean  
context.


My setup is particular, but it works for me. Anyway, I'll share it  
asap :-)


 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration



On Oct 25, 2005, at 8:03 PM, Eduardo Rocha wrote:


Supose the page get serialized, have you already implemented bean
reinjection in deserialization?


Yup.

 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-25 Thread Alexandru Popescu


#: Stefan Arentz changed the world a bit at a time by saying on  10/25/2005 
6:41 PM :#

On Oct 25, 2005, at 11:58 AM, Johan Compagner wrote:

if you want to create youre own page factory. And use  
PagePArameters for everything to supply params back and forth you  
are ofcourse free to do that right now.


Better idea! Add some AOP and annotation magic to the mix!

  public class HelloWorldWebPage extends WebPage
  {
  @SpringBeanReference(dutchHelloWorldService)
  private transient HelloWorldService helloWorldService;

  public void setHelloWorldService(HelloWorldService  
helloWorldService)

  {
  this.helloWorldService = helloWorldService;
  }

  public HelloWorldWebPage()
  {
  add(new Label(message, this.helloWorldService.getMessage 
()));

  }
  }

I'm using all standard Wicket classes. No weird mixing of Spring  
specific classes into the hierarchy.


I think my integration is complete now :-)

The code is a complex mess though. I'll clean this up and put it  
online so that others can look at it or play with it.


  S.





Stefan I was wondering why annotating the field? At the first glance it looks the logical choice, 
but imo the page is the object depending on the service (so the annotation should be on type level).


./alex
--
.w( the_mindstorm )p.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user





---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration



On Oct 25, 2005, at 10:23 PM, Alexandru Popescu wrote:

Stefan I was wondering why annotating the field? At the first  
glance it looks the logical choice, but imo the page is the object  
depending on the service (so the annotation should be on type level).


What do you mean with type level? The HelloWorldPage?

 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-25 Thread Alexandru Popescu


#: Stefan Arentz changed the world a bit at a time by saying on  10/25/2005 
9:32 PM :#

On Oct 25, 2005, at 10:23 PM, Alexandru Popescu wrote:

Stefan I was wondering why annotating the field? At the first  
glance it looks the logical choice, but imo the page is the object  
depending on the service (so the annotation should be on type level).


What do you mean with type level? The HelloWorldPage?

  S.


yep :-). isn't this the way you name an annotations at a `class´ level? 
(java.lang.annotation.ElementType.TYPE)


./alex
--
.w( the_mindstorm )p.




---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration



On Oct 25, 2005, at 10:48 PM, Alexandru Popescu wrote:

#: Stefan Arentz changed the world a bit at a time by saying on   
10/25/2005 9:32 PM :#



On Oct 25, 2005, at 10:23 PM, Alexandru Popescu wrote:

Stefan I was wondering why annotating the field? At the first   
glance it looks the logical choice, but imo the page is the  
object  depending on the service (so the annotation should be on  
type level).



What do you mean with type level? The HelloWorldPage?
  S.



yep :-). isn't this the way you name an annotations at a `class´  
level? (java.lang.annotation.ElementType.TYPE)


Yup. But I don't see how this would work. How would you specify this  
one for example:


bean name=blueImageRenderer class=ImageRendererImpl
  property name=color value=blue/
/bean

bean name=yellowImageRenderer class=ImageRendererImpl
  property name=color value=yellow/
/bean

public class FooPage extends WebPage
{
   @SpringBeanReference(blueImageRenderer)
   transient private ImageRenderer blueImageRenderer;

   public setBlueImageRenderer(ImageRenderer blueImageRenderer) {
   this. blueImageRenderer = blueImageRenderer;
   }

   @SpringBeanReference(yellowImageRenderer)
   transient private ImageRenderer yellowImageRenderer;

   public setYellowImageRenderer(ImageRenderer yellowImageRenderer) {
   this. yellowImageRenderer = yellowImageRenderer;
   }
}

I know it is a silly example :-)

I'm not sure how you would do this on the class level. The annotation  
there then would have to get both bean name and property names in an  
array of pair. Makes no sense to me.


 S.



---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration

2005-10-25 Thread Alexandru Popescu


#: Stefan Arentz changed the world a bit at a time by saying on  10/25/2005 
9:58 PM :#

On Oct 25, 2005, at 10:48 PM, Alexandru Popescu wrote:

#: Stefan Arentz changed the world a bit at a time by saying on   
10/25/2005 9:32 PM :#



On Oct 25, 2005, at 10:23 PM, Alexandru Popescu wrote:

Stefan I was wondering why annotating the field? At the first   
glance it looks the logical choice, but imo the page is the  
object  depending on the service (so the annotation should be on  
type level).



What do you mean with type level? The HelloWorldPage?
  S.



yep :-). isn't this the way you name an annotations at a `class´  
level? (java.lang.annotation.ElementType.TYPE)


Yup. But I don't see how this would work. How would you specify this  
one for example:


bean name=blueImageRenderer class=ImageRendererImpl
   property name=color value=blue/
/bean

bean name=yellowImageRenderer class=ImageRendererImpl
   property name=color value=yellow/
/bean

public class FooPage extends WebPage
{
@SpringBeanReference(blueImageRenderer)
transient private ImageRenderer blueImageRenderer;

public setBlueImageRenderer(ImageRenderer blueImageRenderer) {
this. blueImageRenderer = blueImageRenderer;
}

@SpringBeanReference(yellowImageRenderer)
transient private ImageRenderer yellowImageRenderer;

public setYellowImageRenderer(ImageRenderer yellowImageRenderer) {
this. yellowImageRenderer = yellowImageRenderer;
}
}

I know it is a silly example :-)

I'm not sure how you would do this on the class level. The annotation  
there then would have to get both bean name and property names in an  
array of pair. Makes no sense to me.


  S.


Fair enough :-). Doing some kind of autodiscovery doesn't make sense to me 
neither.

I am waiting with interest to see your whole stuff online.

./alex
--
.w( the_mindstorm )p.




---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] My take on Spring integration