IMHO sharing JARs across J2EE apps is not worth the trouble. - it messes up some JARs (commons-logging is a classic example)
- it forces you to keep your dependent JAR versions in sync across applications. This is particularly important in an enterprise environment where changing a dependent JAR version may force an additional QA cycle. - it complicates deployment, since you have to remember to put any new dependent JARs in the app-server's lib directory instead of just dropping the WAR in place. If you're like me, the memory allocated to the JVM is in the hundreds of megs, so an additional few megs in the WARs is simply not worth the effort. jk On Tue, Feb 24, 2009 at 04:00:58PM +0200, Alex Parvulescu wrote: > Hello, > > I have a problem with the wicket - spring integration in wicket 1.4 rc2 , i > think its similar to https://issues.apache.org/jira/browse/WICKET-1848 > > The use case is like this : > > I have 2 simple applications running in a jetty server. > > To keep things simple , i added the spring and wicket libs to the common > classpath (so the following libs: cglib-nodep-2.1_3.jar, > commons-logging-1.1.jar , log4j-1.2.13.jar , slf4j-api-1.5.0.jar , > slf4j-log4j12-1.5.0.jar , spring-2.5.6.jar , wicket-1.4-rc2.jar , > wicket-ioc-1.4-rc2.jar , wicket-spring-1.4-rc2.jar go into > $JETTY_HOME/lib/ext/extra-libs ) > That helps me keep the size of the wars lower. > > I think the problem is that by using this common classpath , the wicket > applications share -some- context.More to the point , I don't think that > LazyInitProxyFactory is thread safe , or maybe application safe. It appears > that bean ids from one application are visible in another application thats > deployed on the same server. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
