You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Gwyn Evans <gw...@gmail.com> on 2006/10/12 19:02:47 UTC
ClassLoading issues with DefaultClassResolver
Hi,
I'm not sure how much of an edge case this is, but I'm running a few
(currently 3) Wicket web-apps in an EAR under WebLogic, which means
that there's a class-loading hiearachy of:
EAR (EJBs) at 'Level 1', with WAR1, WAR2 & WAR3 all at their own 'Level 2's.
Level 2 classes can see Level 1 files, but not the reverse.
As the EAR's rather large & I need to upload it over ADSL :-), I've
been trying to see if I can move some of the duplicated jars into the
EAR's APP-INF/lib, which puts them up at 'Level 1'. I've managed to
get a few biggies there, e.g. spring, xercesImpl & log4j, but have hit
issues with Wicket itself!
The problem seems to be that as the DefaultClassResolver() is doing
a DefaultClassResolver.class.getClassLoader(), it's only able to see
the 'Level 1' classes, so while it can load the HomePage, as soon as
it needs to try & find any other pages, it all stops, as they're down
in 'Level 2'!
Anyway, while it looks as if I could create my own resolver & do
something like use my 'Application' class as the base, I wondered if
anyone else has come across this sort of issue or had alternative
solution suggestions?
/Gwyn
--
Download Wicket 1.2.2 now! - http://wicketframework.org
Re: ClassLoading issues with DefaultClassResolver
Posted by Gwyn Evans <gw...@gmail.com>.
Hmm, my custom one would have been in the 'Level 2' (pre-webapp level)
whereas the standard Spring one would have been at the 'Level 1'
(common level), but on the other hand, I think they'd both have been
delegating off to the same SpringLocator class? (I think I tried
loading wicket-spring & wicket-spring-annot jars both as common and
local to the web-app, with no noticable change).
For the moment, I'm running with shared Spring & xercesImpl jars,
which saves me ~4MB, and have got some odd IE behaviour (see posts to
Wicket-User) to work out, so I've put this to the side for the moment!
/Gwyn
On 14/10/06, Johan Compagner <jc...@gmail.com> wrote:
> where did the 2 application classes come from?
> What kind of classloaders?
>
> johan
>
>
> On 10/13/06, Gwyn Evans <gw...@gmail.com> wrote:
> >
> > That's what I ended up doing and my one webapp seemed to work fine but
> > I then had some issues with the Wicket SpringLocator in my other
> > webapps, which were using different authentication/application
> > strategies.
> >
> > They were all using Spring, but the two that failed were based on
> > AnnotatedSpringWebApplication, whereas the one that worked was based
> > on a custom AuthenticatedSpringWebApp, but fundamentally should have
> > been the same! Anyway, I'm not up-to-speed on Spring enough to know
> > what the issue was, which combined with the time taken to redeploy &
> > try things, meant I've had to back out of sharing the Wicket jars (for
> > the moment, at least).
> >
> > /Gwyn
> > On 13/10/06, Johan Compagner <jc...@gmail.com> wrote:
> > > yes if you share the wicket.jar on a different level.
> > > Then you will have a problem with the defaultclass resolver.
> > > Maybe we should do Application.get().getClass().getClassLoader() or
> > > something
> > > Then we always use by default the classloader of the application class
> > > (which should be the lowest)
> > >
> > > johan
> > >
> > >
> > > On 10/12/06, Gwyn Evans <gw...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > > I'm not sure how much of an edge case this is, but I'm running a few
> > > > (currently 3) Wicket web-apps in an EAR under WebLogic, which means
> > > > that there's a class-loading hiearachy of:
> > > > EAR (EJBs) at 'Level 1', with WAR1, WAR2 & WAR3 all at their own
> > 'Level
> > > > 2's.
> > > >
> > > > Level 2 classes can see Level 1 files, but not the reverse.
> > > >
> > > > As the EAR's rather large & I need to upload it over ADSL :-), I've
> > > > been trying to see if I can move some of the duplicated jars into the
> > > > EAR's APP-INF/lib, which puts them up at 'Level 1'. I've managed to
> > > > get a few biggies there, e.g. spring, xercesImpl & log4j, but have hit
> > > > issues with Wicket itself!
> > > >
> > > > The problem seems to be that as the DefaultClassResolver() is doing
> > > > a DefaultClassResolver.class.getClassLoader(), it's only able to see
> > > > the 'Level 1' classes, so while it can load the HomePage, as soon as
> > > > it needs to try & find any other pages, it all stops, as they're down
> > > > in 'Level 2'!
> > > >
> > > > Anyway, while it looks as if I could create my own resolver & do
> > > > something like use my 'Application' class as the base, I wondered if
> > > > anyone else has come across this sort of issue or had alternative
> > > > solution suggestions?
> > > >
> > > > /Gwyn
> > > > --
> > > > Download Wicket 1.2.2 now! - http://wicketframework.org
> > > >
> > >
> > >
> >
> >
> > --
> > Download Wicket 1.2.2 now! - http://wicketframework.org
> >
>
>
--
Download Wicket 1.2.2 now! - http://wicketframework.org
Re: ClassLoading issues with DefaultClassResolver
Posted by Johan Compagner <jc...@gmail.com>.
where did the 2 application classes come from?
What kind of classloaders?
johan
On 10/13/06, Gwyn Evans <gw...@gmail.com> wrote:
>
> That's what I ended up doing and my one webapp seemed to work fine but
> I then had some issues with the Wicket SpringLocator in my other
> webapps, which were using different authentication/application
> strategies.
>
> They were all using Spring, but the two that failed were based on
> AnnotatedSpringWebApplication, whereas the one that worked was based
> on a custom AuthenticatedSpringWebApp, but fundamentally should have
> been the same! Anyway, I'm not up-to-speed on Spring enough to know
> what the issue was, which combined with the time taken to redeploy &
> try things, meant I've had to back out of sharing the Wicket jars (for
> the moment, at least).
>
> /Gwyn
> On 13/10/06, Johan Compagner <jc...@gmail.com> wrote:
> > yes if you share the wicket.jar on a different level.
> > Then you will have a problem with the defaultclass resolver.
> > Maybe we should do Application.get().getClass().getClassLoader() or
> > something
> > Then we always use by default the classloader of the application class
> > (which should be the lowest)
> >
> > johan
> >
> >
> > On 10/12/06, Gwyn Evans <gw...@gmail.com> wrote:
> > >
> > > Hi,
> > > I'm not sure how much of an edge case this is, but I'm running a few
> > > (currently 3) Wicket web-apps in an EAR under WebLogic, which means
> > > that there's a class-loading hiearachy of:
> > > EAR (EJBs) at 'Level 1', with WAR1, WAR2 & WAR3 all at their own
> 'Level
> > > 2's.
> > >
> > > Level 2 classes can see Level 1 files, but not the reverse.
> > >
> > > As the EAR's rather large & I need to upload it over ADSL :-), I've
> > > been trying to see if I can move some of the duplicated jars into the
> > > EAR's APP-INF/lib, which puts them up at 'Level 1'. I've managed to
> > > get a few biggies there, e.g. spring, xercesImpl & log4j, but have hit
> > > issues with Wicket itself!
> > >
> > > The problem seems to be that as the DefaultClassResolver() is doing
> > > a DefaultClassResolver.class.getClassLoader(), it's only able to see
> > > the 'Level 1' classes, so while it can load the HomePage, as soon as
> > > it needs to try & find any other pages, it all stops, as they're down
> > > in 'Level 2'!
> > >
> > > Anyway, while it looks as if I could create my own resolver & do
> > > something like use my 'Application' class as the base, I wondered if
> > > anyone else has come across this sort of issue or had alternative
> > > solution suggestions?
> > >
> > > /Gwyn
> > > --
> > > Download Wicket 1.2.2 now! - http://wicketframework.org
> > >
> >
> >
>
>
> --
> Download Wicket 1.2.2 now! - http://wicketframework.org
>
Re: ClassLoading issues with DefaultClassResolver
Posted by Gwyn Evans <gw...@gmail.com>.
That's what I ended up doing and my one webapp seemed to work fine but
I then had some issues with the Wicket SpringLocator in my other
webapps, which were using different authentication/application
strategies.
They were all using Spring, but the two that failed were based on
AnnotatedSpringWebApplication, whereas the one that worked was based
on a custom AuthenticatedSpringWebApp, but fundamentally should have
been the same! Anyway, I'm not up-to-speed on Spring enough to know
what the issue was, which combined with the time taken to redeploy &
try things, meant I've had to back out of sharing the Wicket jars (for
the moment, at least).
/Gwyn
On 13/10/06, Johan Compagner <jc...@gmail.com> wrote:
> yes if you share the wicket.jar on a different level.
> Then you will have a problem with the defaultclass resolver.
> Maybe we should do Application.get().getClass().getClassLoader() or
> something
> Then we always use by default the classloader of the application class
> (which should be the lowest)
>
> johan
>
>
> On 10/12/06, Gwyn Evans <gw...@gmail.com> wrote:
> >
> > Hi,
> > I'm not sure how much of an edge case this is, but I'm running a few
> > (currently 3) Wicket web-apps in an EAR under WebLogic, which means
> > that there's a class-loading hiearachy of:
> > EAR (EJBs) at 'Level 1', with WAR1, WAR2 & WAR3 all at their own 'Level
> > 2's.
> >
> > Level 2 classes can see Level 1 files, but not the reverse.
> >
> > As the EAR's rather large & I need to upload it over ADSL :-), I've
> > been trying to see if I can move some of the duplicated jars into the
> > EAR's APP-INF/lib, which puts them up at 'Level 1'. I've managed to
> > get a few biggies there, e.g. spring, xercesImpl & log4j, but have hit
> > issues with Wicket itself!
> >
> > The problem seems to be that as the DefaultClassResolver() is doing
> > a DefaultClassResolver.class.getClassLoader(), it's only able to see
> > the 'Level 1' classes, so while it can load the HomePage, as soon as
> > it needs to try & find any other pages, it all stops, as they're down
> > in 'Level 2'!
> >
> > Anyway, while it looks as if I could create my own resolver & do
> > something like use my 'Application' class as the base, I wondered if
> > anyone else has come across this sort of issue or had alternative
> > solution suggestions?
> >
> > /Gwyn
> > --
> > Download Wicket 1.2.2 now! - http://wicketframework.org
> >
>
>
--
Download Wicket 1.2.2 now! - http://wicketframework.org
Re: ClassLoading issues with DefaultClassResolver
Posted by Johan Compagner <jc...@gmail.com>.
yes if you share the wicket.jar on a different level.
Then you will have a problem with the defaultclass resolver.
Maybe we should do Application.get().getClass().getClassLoader() or
something
Then we always use by default the classloader of the application class
(which should be the lowest)
johan
On 10/12/06, Gwyn Evans <gw...@gmail.com> wrote:
>
> Hi,
> I'm not sure how much of an edge case this is, but I'm running a few
> (currently 3) Wicket web-apps in an EAR under WebLogic, which means
> that there's a class-loading hiearachy of:
> EAR (EJBs) at 'Level 1', with WAR1, WAR2 & WAR3 all at their own 'Level
> 2's.
>
> Level 2 classes can see Level 1 files, but not the reverse.
>
> As the EAR's rather large & I need to upload it over ADSL :-), I've
> been trying to see if I can move some of the duplicated jars into the
> EAR's APP-INF/lib, which puts them up at 'Level 1'. I've managed to
> get a few biggies there, e.g. spring, xercesImpl & log4j, but have hit
> issues with Wicket itself!
>
> The problem seems to be that as the DefaultClassResolver() is doing
> a DefaultClassResolver.class.getClassLoader(), it's only able to see
> the 'Level 1' classes, so while it can load the HomePage, as soon as
> it needs to try & find any other pages, it all stops, as they're down
> in 'Level 2'!
>
> Anyway, while it looks as if I could create my own resolver & do
> something like use my 'Application' class as the base, I wondered if
> anyone else has come across this sort of issue or had alternative
> solution suggestions?
>
> /Gwyn
> --
> Download Wicket 1.2.2 now! - http://wicketframework.org
>