Hello Lars,
What do you mean by transient and magic? The attributes are not transient. A
> proxy is generated that is serialized. At runtime the real dependency is
> retrieved from the spring container.
The problem with that "magic", as I already expressed in this list some time
ago, is a formal issue. When you use the @SpringBean annotation you end with
something like this:
@SpringBean
MyService myService;
The problem here is that, in a Serializable class (the page), you are
declaring a non-serializable attribute (the service). Service interfaces are
not serializable (normally), and thus they should be declared as "transient"
here, and provide a way to recover the object after page serialization.
Of course, the SpringBean annotation does this for you... because it injects
a Serializable proxy in between the page and the service. Here comes the
magic. So, it works perfectly... but it is formally incorrect. A
non-serializable attribute of a serializable class, made serializable
under-the-scenes by a proxy... my IDE would not like that ;)
>
> I wouldn't use the approach you suggest for the following reasons:
>
> - Scatters your Application class all over your code. Any Component
> (Pages,
> Components) that need a Spring dependency need to the make the verbose
> method call ((MyApplication)Application).get().getService().
I don't really see a problem in that, but Sergio and I have discussed about
the possibility of having getXXXService() methods in a base page from which
the rest of your pages inherit, if that is more convenient for you.
And anyway, we include a static get() method in our application beans which
does the cast from Application.get(), so in fact it is:
"MyApplication.get().getService()"
....much more elegant (IMHO, of course).
>
> - All your dependencies need to be in the Application class which can lead
> to a gigantic Application class if you use a lot of spring beans in your
> application.
As I see it, 90% or even 99% of the "spring beans" you should need to use
from your wicket pages (at least with our architecture) are only services...
and we don't usually have more than 10 or 15 services. Maybe 30 in a really
really big application... and these methods are only setters. Many
persistent beans are far bigger than that.
> - Risk of serializing your spring beans: Since the Annotaion Based
> approach
> generates proxies for your spring beans they can be safely serialized. The
> approach you suggest just returns the spring beans. This increases the
> change of accidentally serializing a spring bean if you do for instance:
>
> public class MyPage {
> private Service service;
> public MyPage() {
> this.service = Application.get().getService();
> }
> }
Well... yes, this can happen. But this can happen with any of your
non-serializable objects. It's just a matter of being careful ;)
Regards,
Daniel.
>
>
> On Mon, Apr 28, 2008 at 10:39 AM, Sergio García <[EMAIL PROTECTED]>
> wrote:
>
> >
> > This posts is about the vision that my colleague Daniel Fernández and me
> > have
> > about how should be the integration between Wicket and Spring, using the
> > new
> > annotation functionalities provided by Spring 2.5. The @SpringBean
> > approach
> > is very useful, but its magic about a transient attribute that is not
> > transient make us fell uncomfortable.
> >
> > Four main steps are needed in this approach:
> >
> > 1) Change applicationClassname web.xml parameter to:
> >
> > <init-param>
> > <param-name>applicationFactoryClassName</param-name>
> > <param-value>
> > org.apache.wicket.spring.SpringWebApplicationFactory
> > </param-value>
> > </init-param>
> >
> > 2) Declare the application class as a Spring bean (Spring 2.5 way)
> >
> > @Component
> > public class MyApplication extends WebApplication
> >
> > 3) Declare into the application class the services with the correct
> Spring
> > 2.5 annotations
> >
> > @Autowired
> > private AaaService aaaService;
> >
> > 4) Add getters for the services
> > public AaaService getAaaService(){
> > return this.aaaService;
> > }
> >
> > For convenience, you can add a static get() method to retrieve the
> casted
> > application class
> >
> > public static MyApplication get() {
> > return (MyApplication) Application.get();
> > }
> >
> > So you can retrieve the service from any page with a simple
> > MyApplication.get().getAaaService()
> >
> >
> >
> >
> > As the applications class is not serializable, there are no need to make
> > transient magic.
> >
> > What do you think about this approach?
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://www.nabble.com/Spring-2.5-and-Wicket%2C-our-vision-about-integration-tp16930960p16930960.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
