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 <[EMAIL PROTECTED]> 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
