You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Kenny MacLeod <ke...@kizoom.com> on 2009/11/10 12:55:08 UTC
wicket-spring enhancements
Hi there,
I've been looking at the wicket-spring integration stuff, and I've come
up with a couple of enhancements which I've found useful, and would be
happy to contribute:
1) An enhanced SpringWebApplicationFactory which has the capability of
creating and initializing its own Spring appcontext, rather than using
the root webabb context. This allows multiple Wicket apps within the
same webapp, each with its own private spring context.
2) A modified AnnotProxyFieldValueFactory which gives the option of
not creating CGLIB proxies for the injected Spring beans. In deployment
environments where session serialization is not enabled, it seems an
unnecessary restriction to require that these proxies be created, given
that not all target beans can be proxied in this way. By allowing this
restriction to be relaxed, a wider set of scenarious can be catered for.
The new flag is passed in from a modified SpringComponentInjector.
I've made these local changes against the current svn trunk. I can keep
them private to my own environment, but I think these are useful and
general enough to warrant contributing, if someone's interested in
taking them on.
kenny
Re: wicket-spring enhancements
Posted by Kenny MacLeod <ke...@kizoom.com>.
Jeremy Thomerson wrote:
> File a JIRA and attach the patch. At least that way they won't get lost.
https://issues.apache.org/jira/browse/WICKET-2572
https://issues.apache.org/jira/browse/WICKET-2573
kenny
Re: Re: wicket-spring enhancements
Posted by br...@gmail.com.
Kenny, if you need some help, let me know.
Afterall I wan't to get myself back on the Wicket track. :-)
Cheers,
Bruno
PS: Jeremy, how's the flip-flops? :-D
Re: wicket-spring enhancements
Posted by Jeremy Thomerson <je...@wickettraining.com>.
File a JIRA and attach the patch. At least that way they won't get lost.
--
Jeremy Thomerson
http://www.wickettraining.com
On Tue, Nov 10, 2009 at 5:55 AM, Kenny MacLeod <ke...@kizoom.com>wrote:
> Hi there,
>
> I've been looking at the wicket-spring integration stuff, and I've come up
> with a couple of enhancements which I've found useful, and would be happy to
> contribute:
>
> 1) An enhanced SpringWebApplicationFactory which has the capability of
> creating and initializing its own Spring appcontext, rather than using the
> root webabb context. This allows multiple Wicket apps within the same
> webapp, each with its own private spring context.
>
> 2) A modified AnnotProxyFieldValueFactory which gives the option of not
> creating CGLIB proxies for the injected Spring beans. In deployment
> environments where session serialization is not enabled, it seems an
> unnecessary restriction to require that these proxies be created, given that
> not all target beans can be proxied in this way. By allowing this
> restriction to be relaxed, a wider set of scenarious can be catered for. The
> new flag is passed in from a modified SpringComponentInjector.
>
> I've made these local changes against the current svn trunk. I can keep
> them private to my own environment, but I think these are useful and general
> enough to warrant contributing, if someone's interested in taking them on.
>
> kenny
>
Re: wicket-spring enhancements
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Nov 10, 2009 at 9:00 AM, Kenny MacLeod <ke...@kizoom.com> wrote:
> Igor Vaynberg wrote:
>>
>> On Tue, Nov 10, 2009 at 3:55 AM, Kenny MacLeod <ke...@kizoom.com>
>> wrote:
>>>
>>> Hi there,
>>>
>>> 2) A modified AnnotProxyFieldValueFactory which gives the option of not
>>> creating CGLIB proxies for the injected Spring beans. In deployment
>>> environments where session serialization is not enabled, it seems an
>>> unnecessary restriction to require that these proxies be created, given
>>> that
>>> not all target beans can be proxied in this way. By allowing this
>>> restriction to be relaxed, a wider set of scenarious can be catered for.
>>> The
>>> new flag is passed in from a modified SpringComponentInjector.
>>
>> this is highly dangerous. while this may work for a quick
>> dev-give-it-a-try test it will fail in most production environments.
>> wicket is not the only thing that serializes pages. the servlet spec
>> says that anything you put into a session *must* be serializable.
>>
>> a) containers will sometimes swap inactive sessions to disk in order
>> to free up some memory - they do this via serialization.
>>
>> b) container serialize sessions when clustering.
>
> I agree that it should be no means be the default setting, but in some cases
> you *know* your production environment does not serialize sessions.
>
> For example, we run in a JBoss cluster with Tomcat session replication
> disabled. Our sessions are full of legacy objects that are not serializable,
> and it causes no problem whatsoever. There's no replication, and no session
> passivation.
>
> All I'm suggesting is that the option is made available, with suitable
> health warnings.
fair enough.
-igor
>
>
> kenny
>
Re: wicket-spring enhancements
Posted by Kenny MacLeod <ke...@kizoom.com>.
James Carman wrote:
> On Tue, Nov 10, 2009 at 12:00 PM, Kenny MacLeod
> <ke...@kizoom.com> wrote:
>> I agree that it should be no means be the default setting, but in some cases
>> you *know* your production environment does not serialize sessions.
>>
>> For example, we run in a JBoss cluster with Tomcat session replication
>> disabled. Our sessions are full of legacy objects that are not serializable,
>> and it causes no problem whatsoever. There's no replication, and no session
>> passivation.
>>
>> All I'm suggesting is that the option is made available, with suitable
>> health warnings.
>
> How much are you really saving here anyway? Is it really that much of
> a performance penalty to go through a proxy (compared to the rest of
> what goes on during a request cycle)? This sounds like a premature
> optimization to me.
It's not an issue of performance - that would indeed be pointless. The
issue is that not all classes are CGLIB-proxiable. The applications I'm
working with have many legacy Spring objects that I want to use in
Wicket which cannot be proxied. I could, in theory, wrap them with
something that *can* be proxied, but the framework should bend in the
direction I need it to go.
kenny
Re: wicket-spring enhancements
Posted by James Carman <jc...@carmanconsulting.com>.
On Tue, Nov 10, 2009 at 12:00 PM, Kenny MacLeod
<ke...@kizoom.com> wrote:
> I agree that it should be no means be the default setting, but in some cases
> you *know* your production environment does not serialize sessions.
>
> For example, we run in a JBoss cluster with Tomcat session replication
> disabled. Our sessions are full of legacy objects that are not serializable,
> and it causes no problem whatsoever. There's no replication, and no session
> passivation.
>
> All I'm suggesting is that the option is made available, with suitable
> health warnings.
How much are you really saving here anyway? Is it really that much of
a performance penalty to go through a proxy (compared to the rest of
what goes on during a request cycle)? This sounds like a premature
optimization to me.
Re: wicket-spring enhancements
Posted by Kenny MacLeod <ke...@kizoom.com>.
Igor Vaynberg wrote:
> On Tue, Nov 10, 2009 at 3:55 AM, Kenny MacLeod <ke...@kizoom.com> wrote:
>> Hi there,
>>
>> 2) A modified AnnotProxyFieldValueFactory which gives the option of not
>> creating CGLIB proxies for the injected Spring beans. In deployment
>> environments where session serialization is not enabled, it seems an
>> unnecessary restriction to require that these proxies be created, given that
>> not all target beans can be proxied in this way. By allowing this
>> restriction to be relaxed, a wider set of scenarious can be catered for. The
>> new flag is passed in from a modified SpringComponentInjector.
>
> this is highly dangerous. while this may work for a quick
> dev-give-it-a-try test it will fail in most production environments.
> wicket is not the only thing that serializes pages. the servlet spec
> says that anything you put into a session *must* be serializable.
>
> a) containers will sometimes swap inactive sessions to disk in order
> to free up some memory - they do this via serialization.
>
> b) container serialize sessions when clustering.
I agree that it should be no means be the default setting, but in some
cases you *know* your production environment does not serialize sessions.
For example, we run in a JBoss cluster with Tomcat session replication
disabled. Our sessions are full of legacy objects that are not
serializable, and it causes no problem whatsoever. There's no
replication, and no session passivation.
All I'm suggesting is that the option is made available, with suitable
health warnings.
kenny
Re: Re: wicket-spring enhancements
Posted by br...@gmail.com.
I think this option can be applied if it deployment environment is checked.
--
Bruno
Re: wicket-spring enhancements
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Nov 10, 2009 at 3:55 AM, Kenny MacLeod <ke...@kizoom.com> wrote:
> Hi there,
>
> I've been looking at the wicket-spring integration stuff, and I've come up
> with a couple of enhancements which I've found useful, and would be happy to
> contribute:
>
> 1) An enhanced SpringWebApplicationFactory which has the capability of
> creating and initializing its own Spring appcontext, rather than using the
> root webabb context. This allows multiple Wicket apps within the same
> webapp, each with its own private spring context.
>
> 2) A modified AnnotProxyFieldValueFactory which gives the option of not
> creating CGLIB proxies for the injected Spring beans. In deployment
> environments where session serialization is not enabled, it seems an
> unnecessary restriction to require that these proxies be created, given that
> not all target beans can be proxied in this way. By allowing this
> restriction to be relaxed, a wider set of scenarious can be catered for. The
> new flag is passed in from a modified SpringComponentInjector.
this is highly dangerous. while this may work for a quick
dev-give-it-a-try test it will fail in most production environments.
wicket is not the only thing that serializes pages. the servlet spec
says that anything you put into a session *must* be serializable.
a) containers will sometimes swap inactive sessions to disk in order
to free up some memory - they do this via serialization.
b) container serialize sessions when clustering.
-igor
>
> I've made these local changes against the current svn trunk. I can keep them
> private to my own environment, but I think these are useful and general
> enough to warrant contributing, if someone's interested in taking them on.
>
> kenny
>