we have to be sure we do not use any static fields anywhere in the
code...it's not just the singletons that break this use case. eg we do not
want caches to be shared across applications because it's not performant
and can result in cross application object leakage.

-igor

On Tuesday, June 12, 2012, Martin Grigorov wrote:

> Hi,
>
> Wicket uses ThreadLocal for the Application, Session and RequestCycle.
> There are no JVM singletons.
>
> Some people are against putting jars in the shared lib folder. I
> personally see the benefit and I'd do it if I need to
> If you use shared jars then make sure that none of the applications
> provide these jars or another version of them because in this case you
> will see some ClassLoader related problems, e.g.: ClassCastException:
> o.a.w.Session class is not o.a.w.Session.
>
> On Tue, Jun 12, 2012 at 11:04 PM, Martin Sachs 
> <[email protected]<javascript:;>>
> wrote:
> > Hello,
> >
> > i think that is in general not a good idea. If you deploy the wicket-lib
> > outside the war and run multiple Wicket-Applications, then you could not
> use
> > all applications, because wicket stores (as far as i know) e.g. the
> > application instance in a static field. There is one application per
> > WAR-deployment with wicket, but if you use the libs from ear/lib or
> modules
> > there will be only one application.
> >
> > best
> > Martin
> >
> > Илья Нарыжный schrieb:
> >
> >> Hello,
> >>
> >> I have several projects which use wicket and various wicket sun-modules.
> >> Every project (*.ear file) took about 10Mb and about 8Mb is for wicket
> >> libraries.
> >> Recently I have move my projects to Jboss AS 7 and now I'm thinking
> >> about putting all wicket related jars to <JBOSS_HOME>/modules.
> >>
> >> Have anyone tried that? Do you have some suggestions for Jboss module
> >> structure for this?
> >> It will be great to have
> >>
> >> IMPLICIT(
> https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments
> )
> >> deploy of wicket related jars to the project.
> >>
> >> Thanks,
> >>
> >> Ilia
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]<javascript:;>
> >> For additional commands, e-mail: [email protected]<javascript:;>
> >>
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]<javascript:;>
> > For additional commands, e-mail: [email protected]<javascript:;>
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] <javascript:;>
> For additional commands, e-mail: [email protected]<javascript:;>
>
>

Reply via email to