Hi Jens, to build the ear you should be in the root folder (tmp) and run the following task;
gradle ear You will find the ear in the ./build/libs/Troubleshooting-1.0.ear To deploy under jboss you should copy the ear in the standalone/deploments folder. Thanks for you help, Luca > Sent: Tuesday, December 15, 2015 at 12:54 PM > From: "Jens Breitenstein" <mailingl...@j-b-s.de> > To: "Tapestry users" <users@tapestry.apache.org> > Subject: Re: Is tapestry plastic incompatible with JEE specs? SADLY YES, BUT > HERE IS A WORKAROUND > > Hi Larzeni, > > The project you provided as download only builds a WAR not EAR. As the > WAR declares all dependencies as "provided" it won't run anyway. Can you > provide the EAR gradle project? I downloaded Wildfly, Graddle but I need > your full "environment" to test it. > Can you update it, please? I have to admit I never used Gradle before, > so maybe it's my fault, but at least my Intellij does not bring up an > EAR artifact either... > > Jens > > > Am 15/12/15 um 11:00 schrieb Luca Arzeni: > > After struggling for a couple of week I have to admit my defeat. > > > > I've found no way to make the project to work. > > > > And NO, there is NO WAY to circument this issue using > > jboss-deployment-structure.xml, "Dependencies" iin manifest entries, or > > placing tapestry jars inside the jboss modules folder and folks like them. > > > > BUT, if some poor soul like me should face this issue, this is the > > workaround that I've found: > > > > 1) individuate the classes that causes you app to crash > > 2) leave these classes in war/classes folder (not sure if this is needed, > > but I have no time to debunk also this point) > > 3) generate an additional jar (say "classLoaderFucker.jar") which contains > > ONLY the classes that causes you app to crash > > 4) place this jar in the ear/lib folder. > > > > This way plastic will find the classes that he needs in the ear lib folder > > (in it's same classloader), and will no more cause classloader issues. > > > > I fully understand that THIS IS NOT A SOLUTION, but simply a cumbersome > > workaround, and the procedure is a trial and error attempt to patch the > > issue, but at least my app is (for now...) working. > > > > (sadly) Thanks to all, > > larzeni > > > > > >> Sent: Friday, December 11, 2015 at 7:05 PM > >> From: "Luca Arzeni" <l.arz...@iname.com> > >> To: "Tapestry Users" <users@tapestry.apache.org> > >> Subject: Is tapestry plastic incompatible with JEE specs? > >> > >> 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