Understood. Than I would try to declare the scope of your core dependencies as "provided" in the war's pom.xml. This is to me similar to a tomcat having shared jars in the lib folder like jdbc drivers but not including them into the war itself.
Jens Von meinem iPhone gesendet > Am 12.12.2015 um 15:08 schrieb Luca Arzeni <l.arz...@iname.com>: > > Hi Jens, > core module contains some EJBs: I'm using JPA for the persistence and SLSB as > facade to achieve a transactional demarcation strategy. So I could roughly > say that the core module contains the persistence layer and the business > logic, which is used by different client application, few of them are > webapps, while other are desktop apps. > > I use this strategy in the web app and in a desktop GUI app: > - the web apps use the SLSB approach, looking up the beans in the webapp > module, and allowing them to be injected the pages ad T5 services; > - the desktop and command line apps use directly the IOC of T5 to inject > services when I need them > > So, an EAR usually contains three or more war module and a EJB module, while > desktop and command line apps are usually a GUI around some services. > > As you can undestand, the real app is more complex than the simple project > that I used for test, and replicating EJB and T5 jars every where could make > my EAR to explode for size and complexity. > > Anyway the testcase, that I used to pinpoint the problem, should be simple > enough to demonstrate the issue. > > I often see that people is deploy t5 as war inside tomcat or jetty. > > I'm wondering if there is someone around that is usually deploying EARs with > jboss and glassfish that has found similar issues... > > Thanks, > Luca > > > >> Sent: Saturday, December 12, 2015 at 2:02 PM >> From: "mailingl...@j-b-s.de" <mailingl...@j-b-s.de> >> To: "Tapestry users" <users@tapestry.apache.org> >> Subject: Re: Is tapestry plastic incompatible with JEE specs? >> >> What is in your core Module? Services using T5 IOC? Why is the core Module >> not part of the war? >> To me it looks more like a structural / serup problem than a real Tapestry >> issue, to be honest. But I can be entirely wrong because I do not know the >> requirements of your project and why it is structured this way. >> >> If you need these libs in different classloaders not belonging to same >> hiererchy, you can't share them. The same class loaded from different >> classloaders will cause trouble anyway, too. Maybe you only need it on >> compile time and "maven provided" on your war pom.xml is the solution? >> >> Jens >> >> Von meinem iPhone gesendet >> >>> Am 11.12.2015 um 22:20 schrieb Luca Arzeni <l.arz...@iname.com>: >>> >>> Hi Jens, >>> the point is that I need them in the lib since I use them also in the core >>> module. >>> >>> I can place them in the lib AND in the war, but I cannot place them ONLY in >>> the war. >>> >>> Also, I ask about compatibility because if I have properly spotted the >>> issue, some kind of problem could arise also in the core (read: ejb.jar) >>> module. >>> >>> The real showstopper is the pervasive usage that I'm doing of tapestry IOC. >>> >>> I like it, but if these problems cannot be solved, it may be better for me >>> to migrate to Guice or Spring. >>> >>> Thanks, >>> larzeni >>> >>> >>>> Sent: Friday, December 11, 2015 at 8:00 PM >>>> From: "mailingl...@j-b-s.de" <mailingl...@j-b-s.de> >>>> To: "Tapestry users" <users@tapestry.apache.org> >>>> Subject: Re: Is tapestry plastic incompatible with JEE specs? >>>> >>>> Hi! >>>> >>>> IWhy not having all T5 related jars in your war? Any particular reason why >>>> they are located in your ear? >>>> >>>> Jens >>>> >>>> >>>> >>>> Von meinem iPhone gesendet >>>> >>>>> Am 11.12.2015 um 19:05 schrieb Luca Arzeni <l.arz...@iname.com>: >>>>> >>>>> Hi there, >>>>> my environment is: >>>>> JBoss 7.2+ (actually 6.1.1.GA) or Wildfly 8.0 Final >>>>> Tapestry5 5.3.7 >>>>> >>>>> I'm developing a little ear, which has the following structure >>>>> >>>>> myear.ear >>>>> | core-1.1.jar >>>>> | webclient-1.1.war >>>>> | lib/ >>>>> | plastic-5.3.7.jar >>>>> | tapestry5-annotations-5.3.7.jar >>>>> | tapestry-core-5.3.7.jar >>>>> | tapestry-func-5.3.7.jar >>>>> | tapestry-ioc-5.3.7.jar >>>>> | tapestry-json-5.3.7.jar >>>>> | tapestry-upload-5.3.7.jar >>>>> | ... omissis ... >>>>> >>>>> the core-1.1.jar module contains few EJBs, >>>>> the webclient-1.1.war module contains my t5 app (pages, components and so >>>>> on) >>>>> >>>>> I routinely use and appreciate t5 IOC, so I used it also in the core >>>>> module; at this point I need to have the t5 jars available to the core >>>>> AND to the webclient, so I put them in the shared "lib" folder of the EAR. >>>>> >>>>> So far, so good: the app worked and I had no problem. >>>>> >>>>> Today I was needing to place an object (a simple bean with 3 strings >>>>> attributes and their getters and setters) and serialize/deserialize it >>>>> into a file. >>>>> >>>>> The bean is needed only in the webclient (I need to place it in session), >>>>> so I placed it in the webclient.war. >>>>> >>>>> Now my webapp crashed when I try to instantiate a page that refers to the >>>>> bean. >>>>> >>>>> Looking at the problem, it seems to be caused by plastic that tries to >>>>> reach the class by using the jboss classloader. >>>>> >>>>> This is the relevant part of the stack: >>>>> >>>>> --- >>>>> org.apache.tapestry5.internal.plastic.asm.ClassWriter.getCommonSuperClass(ClassWriter.java:1588) >>>>> org.apache.tapestry5.internal.plastic.asm.ClassWriter.getMergedType(ClassWriter.java:1559) >>>>> org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1406) >>>>> org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1308) >>>>> org.apache.tapestry5.internal.plastic.asm.MethodWriter.visitMaxs(MethodWriter.java:1353) >>>>> org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:635) >>>>> org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:557) >>>>> org.apache.tapestry5.internal.plastic.asm.tree.ClassNode.accept(ClassNode.java:361) >>>>> org.apache.tapestry5.internal.plastic.PlasticClassPool.toBytecode(PlasticClassPool.java:187) >>>>> org.apache.tapestry5.internal.plastic.PlasticClassPool.realize(PlasticClassPool.java:140) >>>>> org.apache.tapestry5.internal.plastic.PlasticClassPool.realizeTransformedClass(PlasticClassPool.java:122) >>>>> org.apache.tapestry5.internal.plastic.PlasticClassImpl.createInstantiator(PlasticClassImpl.java:358) >>>>> org.apache.tapestry5.internal.plastic.PlasticClassPool.loadAndTransformClass(PlasticClassPool.java:350) >>>>> org.apache.tapestry5.internal.plastic.PlasticClassLoader.loadClass(PlasticClassLoader.java:38) >>>>> java.lang.ClassLoader.loadClass(ClassLoader.java:358) >>>>> java.lang.Class.getDeclaredFields0(Native Method) >>>>> java.lang.Class.privateGetDeclaredFields(Class.java:2509) >>>>> java.lang.Class.getDeclaredField(Class.java:1959) >>>>> --- >>>>> >>>>> In the JEE spec it is written that the war classloader must be isolated >>>>> from the EAR classloader. >>>>> >>>>> In my understanding this means that t5 plastic (which lives in the EAR >>>>> classloader) cannot reach the classes that are in the war (separate >>>>> classloader). >>>>> >>>>> I could place the jars in the war/lib folder, but at this point the core >>>>> module cannot see them. >>>>> >>>>> The only viable solution that I found is to place the bean classes in the >>>>> shared lib folder, by extracting them from the war, but this is only a >>>>> temporary patch. >>>>> >>>>> In the past I developed another ear and I had a similar issue trying to >>>>> instantiate a page from another page. I solved it by avoiding the link >>>>> between the two pages; but now I'm starting to think that it was another >>>>> "face" of the same problem. >>>>> >>>>> Now, since these issues are becoming too frequent to work around them, >>>>> and I'm wandering if there is a real solution or there's a real >>>>> compatibility issue between T5 and JEE specs. >>>>> >>>>> Is there anyone that can help me? >>>>> >>>>> Thanks, >>>>> larzeni >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
