You're running into a problem with with the way classloaders work in an application server. You might be able to make this work by putting the tapestry jars + dependencies in the shared lib for jetty, they would then be loaded from the same classloader. I haven't tried this and I'm not sure it's going to work, but it's where I would start.
http://docs.codehaus.org/display/JETTY/Classloading On Thu, Dec 13, 2012 at 9:54 AM, Martin Nagl <mn...@mtbiker.sk> wrote: > Hi all, > > I am considering my options for building a combo of T5 web application + > Jersey REST interface for this application. I am thinking about: > > Step 1: Implementing a T5 application with my business logic (DB access, > computations) placed in Tapestry IOC services, because I like how the IOC > and JPA support plays together out-of-the-box. > Step 2: Implementing a Jersey web aplication which will reuse my Tapestry > IOC services and expose the REST interface > > I tried 2 approaches. Approach 1 works, approach 2 fails (I think I am > missing somethig basic here). > > Approach 1: Everything in one WAR, share Registry via ServletContext: > - /myapp/web/ > - /myapp/rest/ > - Make Tapestry 5 application run in folder "web", by providing > configuration SymbolConstants.APPLICATION_FOLDER in AppModule > - In web.xml: map the TapestryFilter to /web/*, > - In web.xml: add a Jersey Servlet and map it to /rest/* > - In Jersey resource: access the Registry instance stored in > ServletContext > and access my service like this: > Registry registry = > (Registry)context.getAttribute(TapestryFilter.REGISTRY_CONTEXT_NAME); > EmployeeService service = registry.getService(EmployeeService.class); > > Approach 1 works, because TapestryFilter and JerseyServlet share the > ServletContext (are part of same webapp). However, I would like to have > separate WARs for the Jersey and for the T5 app. I may need this to > configure different auth-method in <login-config> in web.xml for Jersey app > than for T5 app. > > Approach 2: Separate WARs, share Registry via JNDI. > - /myapp-web/ > - /myapp-rest/ > - In T5 app, after Registry startup, store the Registry instance in JNDI > somehow > InitialContext ic = new InitialContext(); > ic.rebind("java:registry", registry); > - In Jersey app, access the Registry through JNDI and access my service: > InitialContext ic = new InitialContext(); > Object object = ic.lookup("java:registry"); > Registry registry = (Registry)object; > EmployeeService service = > registry.getService(EmployeeService.class); > > Approach 2 fails with ClassCastException in this line: > Registry registry = (Registry)object; > ClassCastException: org.apache.tapestry5.ioc.internal.RegistryWrapper > cannot be cast to org.apache.tapestry5.ioc.Registry. > > I am using Jetty. I debuged it and found that object from lookup() has a > class from a different classloader than class I cast it to, because they > come from different contexts (each context has a separate classloader). I > have little experience with storing objects in JNDI, I think I am missing > something basic here, maybe JNDI is not even meant to be used like this.... > Is it even feasible to share Registry through JNDI? > > Please share your thoughts, is there any other way to share my the Tapestry > IOC Service from running T5 app to another web application, deployed in the > same container? Is this even a good idea? Or should I keep all in 1 WAR? > > For the record, I also considered: business logic in a separate EJB layer, > shared by both apps, both apps deployed to Glassfish. This environment is > somewhat hard to configure for me, for example because tapestry-jpa > conflicts with AS-managed persistence context. I would like to keep the dev > environment simple and make use of live class reloading. I use Eclipse + > maven + jetty. > Thanks for any ideas. > > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Sharing-the-Registry-instance-between-web-applications-deployed-in-the-same-container-tp5718686.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
