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

Reply via email to