Re: Is tapestry plastic incompatible with JEE specs? SADLY YES, BUT HERE IS A WORKAROUND
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" > To: "Tapestry users" > 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" > >> To: "Tapestry Users" > >> 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) > >
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" To: "Tapestry Users" 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 solut
Re: Is tapestry plastic incompatible with JEE specs? SADLY YES, BUT HERE IS A WORKAROUND
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" > To: "Tapestry Users" > 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
