Re: wicket-spring classpath issue
Hello, Your point is interesting , but I really think theres more to this than simple convenience. I am really interested in this because I think its a bug. Its you choice if you want to have a big fat war (~5MB) and deploy that over scp - i guess the fast deploy cycles go out the window, or try to keep things small and easy , go with a common lib folder for all the apps on the server and have ~300KB wars. In the end I think that should be the developer's decision, and not be constrained by an eventual bug in the framework. Apparently, the spring beans get somehow shared by apps that have nothing in common, and thats not good. Thanks, Alex On Tue, Feb 24, 2009 at 6:32 PM, John Krasnay wrote: > 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 > >
Re: wicket-spring classpath issue
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
wicket-spring classpath issue
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. As an example : I can define a bean with the id 'simpleService' in the first application. But when I try to define another bean in the second application with the same id - still 'simpleService' but a different interface- I get the following error: GET, protocol = HTTP/1.1, requestURL = http://localhost:8080/, contentType = null, contentLength = -1, contextPath = , pathInfo = null, requestURI = /, servletPath = /, pathTranslated = null] 2009-02-24 15:08:04,803 ERROR org.apache.wicket.RequestCycle - Can't instantiate page using constructor public com.asf.test2.web.Index() org.apache.wicket.WicketRuntimeException: Can't instantiate page using constructor public com.asf.test2.web.Index() at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:172) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:299) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1192) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1271) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1370) at org.apache.wicket.RequestCycle.request(RequestCycle.java:501) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:455) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:288) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:865) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:538) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:153) ... 28 more Caused by: java.lang.RuntimeException: error while injecting object [[Page class = com.asf.test2.web.Index, id = 0, version = 0]] of type [com.asf.test2.web.Index] at org.apache.wicket.injection.Injector.inject(Injector.java:118) at org.apache.wicket.injection.ConfigurableInjector.inject(Configura
