Is tapestry plastic incompatible with JEE specs?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Is tapestry plastic incompatible with JEE specs?

larzeni
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

Jens Breitenstein
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 <[hidden email]>:
>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

larzeni
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: "[hidden email]" <[hidden email]>
> To: "Tapestry users" <[hidden email]>
> 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 <[hidden email]>:
> >
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

Thiago H de Paula Figueiredo
On Fri, 11 Dec 2015 19:20:14 -0200, Luca Arzeni <[hidden email]> wrote:

> Hi Jens,

Hi!

> I like it, but if these problems cannot be solved, it may be better for  
> me to migrate to Guice or Spring.

Common, you don't need or want to do that. Have you checked that the  
incredibly useful Tapestry JumpStart runs on JBoss?  
http://jumpstart.doublenegative.com.au/jumpstart6.0/servers_jboss_7.html.  
Or this? https://wiki.apache.org/tapestry/HowToRunTapestry5OnJBoss7Dot1

By the way, please post the full stack trace. The important part of it got  
left out when you copied it.

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

larzeni
Hi Thiago,

I know fairly well jboss (I'm working with it since 3.2 :-) ) and I already checked the jumpstart. As I said, the app worked and works fine until I insert the bean.

The real point here seems to be that, deploying an EAR, JBoss isolates the classes within the WAR from the EAR, even if I set isolated deployment to false.

Please read this link for more details:
http://www.mastertheboss.com/jboss-server/jboss-as-7/jboss-as-7-classloading

And refer to this page for the issue with the war
https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/Disable_Subdeployment_Class_Loader_Isolation_Within_a_EAR.html

"Even when subdeployment class loader isolation is disabled it is NOT POSSIBLE to add a WAR deployment as a dependency."

I understand this as:
- a class that resides in the lib folder cannot have access a class that resides in the WAR WEB-INF/classes folder; and
- plastic cannot generate/sintetize accessor for properties for a class that is outside the lib folder or
- the plastic-generated class cannot replace/overwrite the class in the WAR

I can also see that, if I place the war classes in the shared folder I solve the issues, so it seems reasonable to suppose that this is an isolation issue of jboss.

I will try to reproduce the issue with glassfish4 to see if this is a spec-related question or it is a jboss misimplementation of the specs.

I will post the full stack trace and also set up a minimum deploy ear to allow you to reproduce the issue.

Thanks again,
larzeni


I will setup a simple application to show the issue.

> Sent: Friday, December 11, 2015 at 11:16 PM
> From: "Thiago H de Paula Figueiredo" <[hidden email]>
> To: "Tapestry users" <[hidden email]>
> Subject: Re: Is tapestry plastic incompatible with JEE specs?
>
> On Fri, 11 Dec 2015 19:20:14 -0200, Luca Arzeni <[hidden email]> wrote:
>
> > Hi Jens,
>
> Hi!
>
> > I like it, but if these problems cannot be solved, it may be better for  
> > me to migrate to Guice or Spring.
>
> Common, you don't need or want to do that. Have you checked that the  
> incredibly useful Tapestry JumpStart runs on JBoss?  
> http://jumpstart.doublenegative.com.au/jumpstart6.0/servers_jboss_7.html.  
> Or this? https://wiki.apache.org/tapestry/HowToRunTapestry5OnJBoss7Dot1
>
> By the way, please post the full stack trace. The important part of it got  
> left out when you copied it.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

Jens Breitenstein
In reply to this post by larzeni
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 <[hidden email]>:
>
> 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: "[hidden email]" <[hidden email]>
>> To: "Tapestry users" <[hidden email]>
>> 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 <[hidden email]>:
>>>
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

larzeni
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: "[hidden email]" <[hidden email]>
> To: "Tapestry users" <[hidden email]>
> 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 <[hidden email]>:
> >
> > 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: "[hidden email]" <[hidden email]>
> >> To: "Tapestry users" <[hidden email]>
> >> 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 <[hidden email]>:
> >>>
> >>> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

Jens Breitenstein
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 <[hidden email]>:
>
> 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: "[hidden email]" <[hidden email]>
>> To: "Tapestry users" <[hidden email]>
>> 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 <[hidden email]>:
>>>
>>> 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: "[hidden email]" <[hidden email]>
>>>> To: "Tapestry users" <[hidden email]>
>>>> 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 <[hidden email]>:
>>>>>
>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

larzeni
In reply to this post by Thiago H de Paula Figueiredo
Here you are: this is a test case that shows the issue.

In the linked file, you'll find a simple working/crashing example, with a gradle script to build it (in ts really simple, but just to play it safe). You can download it at:

https://app.box.com/s/eoie31up2z8djdwja77136649c8vogv0

There is also a readme.txt that explains the issue and the test that I've done.

After the deployment, you can reach the app at the URL:

http://localhost:8080/webclient/

I packed into the tar.gz also the application exception page, from which you can read the full stack trace.

Anyway, if you prefer, here is the full stack trace.

Thanks for your help,
larzeni


18:02:53,903 ERROR [Registry] java.lang.ClassNotFoundException: com.amadego.cast.webclient.data.LocalitaData from [Module "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
18:02:53,903 ERROR [Registry] Operations trace:
18:02:53,903 ERROR [Registry] [ 1] Constructing instance of page class com.amadego.cast.webclient.pages.Start
18:02:53,904 ERROR [Registry] [ 2] Creating ComponentAssembler for com.amadego.cast.webclient.pages.Start
18:02:53,904 ERROR [Registry] [ 3] Creating instantiator for component class com.amadego.cast.webclient.pages.Start
18:02:53,904 ERROR [RequestExceptionHandler] Processing of request failed with uncaught exception: java.lang.ClassNotFoundException: com.amadego.cast.webclient.data.LocalitaData from [Module "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]: org.apache.tapestry5.ioc.internal.OperationException: java.lang.ClassNotFoundException: com.amadego.cast.webclient.data.LocalitaData from [Module "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
        at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl.createInstantiatorForClass(ComponentInstantiatorSourceImpl.java:227) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl.getInstantiator(ComponentInstantiatorSourceImpl.java:217) [tapestry-core-5.3.7.jar:]
        at $ComponentInstantiatorSource_5ee3f5f438c.getInstantiator(Unknown Source) at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:225) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:222) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.internal.pageload.PageLoaderImpl.createAssembler(PageLoaderImpl.java:221) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.pageload.PageLoaderImpl.getAssembler(PageLoaderImpl.java:211) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.pageload.PageLoaderImpl$3.invoke(PageLoaderImpl.java:183) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.pageload.PageLoaderImpl$3.invoke(PageLoaderImpl.java:178) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:177) [tapestry-core-5.3.7.jar:]
        at $PageLoader_5ee3f5f4373.loadPage(Unknown Source) at org.apache.tapestry5.internal.services.PageSourceImpl.getPage(PageSourceImpl.java:104) [tapestry-core-5.3.7.jar:]
        at $PageSource_5ee3f5f4370.getPage(Unknown Source) at org.apache.tapestry5.internal.services.NonPoolingRequestPageCacheImpl.get(NonPoolingRequestPageCacheImpl.java:82) [tapestry-core-5.3.7.jar:]
        at $RequestPageCache_5ee3f5f436f.get(Unknown Source) at $RequestPageCache_5ee3f5f4369.get(Unknown Source) at org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:55) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.services.TapestryModule$38.handle(TapestryModule.java:2222) [tapestry-core-5.3.7.jar:]
        at $PageRenderRequestHandler_5ee3f5f436d.handle(Unknown Source) at $PageRenderRequestHandler_5ee3f5f4366.handle(Unknown Source) at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.services.InitializeActivePageName.handlePageRender(InitializeActivePageName.java:47) [tapestry-core-5.3.7.jar:]
        at $ComponentRequestHandler_5ee3f5f4367.handlePageRender(Unknown Source) at $ComponentRequestHandler_5ee3f5f435f.handlePageRender(Unknown Source) at org.apache.tapestry5.internal.services.RootPathDispatcher.dispatch(RootPathDispatcher.java:66) [tapestry-core-5.3.7.jar:]
        at $Dispatcher_5ee3f5f4362.dispatch(Unknown Source) at $Dispatcher_5ee3f5f435c.dispatch(Unknown Source) at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:302) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) [tapestry-core-5.3.7.jar:]
        at $RequestHandler_5ee3f5f435d.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:902) [tapestry-core-5.3.7.jar:]
        at $RequestHandler_5ee3f5f435d.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:892) [tapestry-core-5.3.7.jar:]
        at $RequestHandler_5ee3f5f435d.service(Unknown Source) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:90) [tapestry-core-5.3.7.jar:]
        at $RequestHandler_5ee3f5f435d.service(Unknown Source) at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:105) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:95) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85) [tapestry-ioc-5.3.7.jar:]
        at org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:119) [tapestry-core-5.3.7.jar:]
        at $RequestHandler_5ee3f5f435d.service(Unknown Source) at $RequestHandler_5ee3f5f4351.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:253) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:53) [tapestry-core-5.3.7.jar:]
        at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source) at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) [tapestry-core-5.3.7.jar:]
        at $HttpServletRequestFilter_5ee3f5f434f.service(Unknown Source) at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852) [tapestry-core-5.3.7.jar:]
        at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source) at $HttpServletRequestHandler_5ee3f5f434e.service(Unknown Source) at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171) [tapestry-core-5.3.7.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.amadego.cast.webclient.data.LocalitaData from [Module "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
        at org.apache.tapestry5.internal.plastic.asm.ClassWriter.getCommonSuperClass(ClassWriter.java:1588) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.asm.ClassWriter.getMergedType(ClassWriter.java:1559) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1406) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1308) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.asm.MethodWriter.visitMaxs(MethodWriter.java:1353) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:635) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:557) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.asm.tree.ClassNode.accept(ClassNode.java:361) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.PlasticClassPool.toBytecode(PlasticClassPool.java:187) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.PlasticClassPool.realize(PlasticClassPool.java:140) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.PlasticClassPool.realizeTransformedClass(PlasticClassPool.java:122) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.PlasticClassImpl.createInstantiator(PlasticClassImpl.java:358) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.PlasticClassPool.loadAndTransformClass(PlasticClassPool.java:350) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.plastic.PlasticClassLoader.loadClass(PlasticClassLoader.java:38) [plastic-5.3.7.jar:]
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [rt.jar:1.6.0_45]
        at org.apache.tapestry5.internal.plastic.PlasticClassPool.getClassInstantiator(PlasticClassPool.java:516) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.plastic.PlasticManager.getClassInstantiator(PlasticManager.java:189) [plastic-5.3.7.jar:]
        at org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl$2.invoke(ComponentInstantiatorSourceImpl.java:235) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl$2.invoke(ComponentInstantiatorSourceImpl.java:229) [tapestry-core-5.3.7.jar:]
        at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) [tapestry-ioc-5.3.7.jar:]
        ... 73 more





> Sent: Friday, December 11, 2015 at 11:16 PM
> From: "Thiago H de Paula Figueiredo" <[hidden email]>
> To: "Tapestry users" <[hidden email]>
> Subject: Re: Is tapestry plastic incompatible with JEE specs?
>
> On Fri, 11 Dec 2015 19:20:14 -0200, Luca Arzeni <[hidden email]> wrote:
>
> > Hi Jens,
>
> Hi!
>
> > I like it, but if these problems cannot be solved, it may be better for  
> > me to migrate to Guice or Spring.
>
> Common, you don't need or want to do that. Have you checked that the  
> incredibly useful Tapestry JumpStart runs on JBoss?  
> http://jumpstart.doublenegative.com.au/jumpstart6.0/servers_jboss_7.html.  
> Or this? https://wiki.apache.org/tapestry/HowToRunTapestry5OnJBoss7Dot1
>
> By the way, please post the full stack trace. The important part of it got  
> left out when you copied it.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

Dimitris Zenios
HI Luca Arzeni

Just for testing could you try with Tapestry 5.4-rc-1?

Tapestry 5.4 bundles a newer asm version. Don't forget that tapestry
plastic is a wrapper around asm

Dimitris Zenios



On Sat, Dec 12, 2015 at 7:06 PM, Luca Arzeni <[hidden email]> wrote:

> Here you are: this is a test case that shows the issue.
>
> In the linked file, you'll find a simple working/crashing example, with a
> gradle script to build it (in ts really simple, but just to play it safe).
> You can download it at:
>
> https://app.box.com/s/eoie31up2z8djdwja77136649c8vogv0
>
> There is also a readme.txt that explains the issue and the test that I've
> done.
>
> After the deployment, you can reach the app at the URL:
>
> http://localhost:8080/webclient/
>
> I packed into the tar.gz also the application exception page, from which
> you can read the full stack trace.
>
> Anyway, if you prefer, here is the full stack trace.
>
> Thanks for your help,
> larzeni
>
>
> 18:02:53,903 ERROR [Registry] java.lang.ClassNotFoundException:
> com.amadego.cast.webclient.data.LocalitaData from [Module
> "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
> 18:02:53,903 ERROR [Registry] Operations trace:
> 18:02:53,903 ERROR [Registry] [ 1] Constructing instance of page class
> com.amadego.cast.webclient.pages.Start
> 18:02:53,904 ERROR [Registry] [ 2] Creating ComponentAssembler for
> com.amadego.cast.webclient.pages.Start
> 18:02:53,904 ERROR [Registry] [ 3] Creating instantiator for component
> class com.amadego.cast.webclient.pages.Start
> 18:02:53,904 ERROR [RequestExceptionHandler] Processing of request failed
> with uncaught exception: java.lang.ClassNotFoundException:
> com.amadego.cast.webclient.data.LocalitaData from [Module
> "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]:
> org.apache.tapestry5.ioc.internal.OperationException:
> java.lang.ClassNotFoundException:
> com.amadego.cast.webclient.data.LocalitaData from [Module
> "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
>         at
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl.createInstantiatorForClass(ComponentInstantiatorSourceImpl.java:227)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl.getInstantiator(ComponentInstantiatorSourceImpl.java:217)
> [tapestry-core-5.3.7.jar:]
>         at
> $ComponentInstantiatorSource_5ee3f5f438c.getInstantiator(Unknown Source)
>  at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:225)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:222)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl.createAssembler(PageLoaderImpl.java:221)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl.getAssembler(PageLoaderImpl.java:211)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$3.invoke(PageLoaderImpl.java:183)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$3.invoke(PageLoaderImpl.java:178)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:177)
> [tapestry-core-5.3.7.jar:]
>         at $PageLoader_5ee3f5f4373.loadPage(Unknown Source)     at
> org.apache.tapestry5.internal.services.PageSourceImpl.getPage(PageSourceImpl.java:104)
> [tapestry-core-5.3.7.jar:]
>         at $PageSource_5ee3f5f4370.getPage(Unknown Source)      at
> org.apache.tapestry5.internal.services.NonPoolingRequestPageCacheImpl.get(NonPoolingRequestPageCacheImpl.java:82)
> [tapestry-core-5.3.7.jar:]
>         at $RequestPageCache_5ee3f5f436f.get(Unknown Source)    at
> $RequestPageCache_5ee3f5f4369.get(Unknown Source)    at
> org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:55)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.services.TapestryModule$38.handle(TapestryModule.java:2222)
> [tapestry-core-5.3.7.jar:]
>         at $PageRenderRequestHandler_5ee3f5f436d.handle(Unknown Source) at
> $PageRenderRequestHandler_5ee3f5f4366.handle(Unknown Source) at
> org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.services.InitializeActivePageName.handlePageRender(InitializeActivePageName.java:47)
> [tapestry-core-5.3.7.jar:]
>         at $ComponentRequestHandler_5ee3f5f4367.handlePageRender(Unknown
> Source)        at
> $ComponentRequestHandler_5ee3f5f435f.handlePageRender(Unknown Source)
>   at
> org.apache.tapestry5.internal.services.RootPathDispatcher.dispatch(RootPathDispatcher.java:66)
> [tapestry-core-5.3.7.jar:]
>         at $Dispatcher_5ee3f5f4362.dispatch(Unknown Source)     at
> $Dispatcher_5ee3f5f435c.dispatch(Unknown Source)     at
> org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:302)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
> [tapestry-core-5.3.7.jar:]
>         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:902)
> [tapestry-core-5.3.7.jar:]
>         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:892)
> [tapestry-core-5.3.7.jar:]
>         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:90)
> [tapestry-core-5.3.7.jar:]
>         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:105)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:95)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
> [tapestry-ioc-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:119)
> [tapestry-core-5.3.7.jar:]
>         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> $RequestHandler_5ee3f5f4351.service(Unknown Source)  at
> org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:253)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:53)
> [tapestry-core-5.3.7.jar:]
>         at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source)
>      at
> org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
> [tapestry-core-5.3.7.jar:]
>         at $HttpServletRequestFilter_5ee3f5f434f.service(Unknown Source)
>       at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source)
>    at
> org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
> [tapestry-core-5.3.7.jar:]
>         at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source)
>      at $HttpServletRequestHandler_5ee3f5f434e.service(Unknown Source)
>  at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
>         at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920)
> [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException:
> com.amadego.cast.webclient.data.LocalitaData from [Module
> "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
>         at
> org.apache.tapestry5.internal.plastic.asm.ClassWriter.getCommonSuperClass(ClassWriter.java:1588)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.asm.ClassWriter.getMergedType(ClassWriter.java:1559)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1406)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1308)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.asm.MethodWriter.visitMaxs(MethodWriter.java:1353)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:635)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:557)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.asm.tree.ClassNode.accept(ClassNode.java:361)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.PlasticClassPool.toBytecode(PlasticClassPool.java:187)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.PlasticClassPool.realize(PlasticClassPool.java:140)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.PlasticClassPool.realizeTransformedClass(PlasticClassPool.java:122)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.PlasticClassImpl.createInstantiator(PlasticClassImpl.java:358)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.PlasticClassPool.loadAndTransformClass(PlasticClassPool.java:350)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.plastic.PlasticClassLoader.loadClass(PlasticClassLoader.java:38)
> [plastic-5.3.7.jar:]
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> [rt.jar:1.6.0_45]
>         at
> org.apache.tapestry5.internal.plastic.PlasticClassPool.getClassInstantiator(PlasticClassPool.java:516)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.plastic.PlasticManager.getClassInstantiator(PlasticManager.java:189)
> [plastic-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl$2.invoke(ComponentInstantiatorSourceImpl.java:235)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl$2.invoke(ComponentInstantiatorSourceImpl.java:229)
> [tapestry-core-5.3.7.jar:]
>         at
> org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
> [tapestry-ioc-5.3.7.jar:]
>         ... 73 more
>
>
>
>
>
> > Sent: Friday, December 11, 2015 at 11:16 PM
> > From: "Thiago H de Paula Figueiredo" <[hidden email]>
> > To: "Tapestry users" <[hidden email]>
> > Subject: Re: Is tapestry plastic incompatible with JEE specs?
> >
> > On Fri, 11 Dec 2015 19:20:14 -0200, Luca Arzeni <[hidden email]>
> wrote:
> >
> > > Hi Jens,
> >
> > Hi!
> >
> > > I like it, but if these problems cannot be solved, it may be better for
> > > me to migrate to Guice or Spring.
> >
> > Common, you don't need or want to do that. Have you checked that the
> > incredibly useful Tapestry JumpStart runs on JBoss?
> > http://jumpstart.doublenegative.com.au/jumpstart6.0/servers_jboss_7.html
> .
> > Or this? https://wiki.apache.org/tapestry/HowToRunTapestry5OnJBoss7Dot1
> >
> > By the way, please post the full stack trace. The important part of it
> got
> > left out when you copied it.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

larzeni
Hi Dimitris,

NO WAY: I've checked with tapestry 5.3.8 and also with 5.4-rc1 but found no difference, the issue is always there.

By the way, kudos to the development team for the error page of t5.4, it's fairly well structured.

Still looking for a solution.

See you!


> Sent: Saturday, December 12, 2015 at 7:14 PM
> From: "Dimitris Zenios" <[hidden email]>
> To: "Tapestry users" <[hidden email]>
> Subject: Re: Is tapestry plastic incompatible with JEE specs?
>
> HI Luca Arzeni
>
> Just for testing could you try with Tapestry 5.4-rc-1?
>
> Tapestry 5.4 bundles a newer asm version. Don't forget that tapestry
> plastic is a wrapper around asm
>
> Dimitris Zenios
>
>
>
> On Sat, Dec 12, 2015 at 7:06 PM, Luca Arzeni <[hidden email]> wrote:
>
> > Here you are: this is a test case that shows the issue.
> >
> > In the linked file, you'll find a simple working/crashing example, with a
> > gradle script to build it (in ts really simple, but just to play it safe).
> > You can download it at:
> >
> > https://app.box.com/s/eoie31up2z8djdwja77136649c8vogv0
> >
> > There is also a readme.txt that explains the issue and the test that I've
> > done.
> >
> > After the deployment, you can reach the app at the URL:
> >
> > http://localhost:8080/webclient/
> >
> > I packed into the tar.gz also the application exception page, from which
> > you can read the full stack trace.
> >
> > Anyway, if you prefer, here is the full stack trace.
> >
> > Thanks for your help,
> > larzeni
> >
> >
> > 18:02:53,903 ERROR [Registry] java.lang.ClassNotFoundException:
> > com.amadego.cast.webclient.data.LocalitaData from [Module
> > "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
> > 18:02:53,903 ERROR [Registry] Operations trace:
> > 18:02:53,903 ERROR [Registry] [ 1] Constructing instance of page class
> > com.amadego.cast.webclient.pages.Start
> > 18:02:53,904 ERROR [Registry] [ 2] Creating ComponentAssembler for
> > com.amadego.cast.webclient.pages.Start
> > 18:02:53,904 ERROR [Registry] [ 3] Creating instantiator for component
> > class com.amadego.cast.webclient.pages.Start
> > 18:02:53,904 ERROR [RequestExceptionHandler] Processing of request failed
> > with uncaught exception: java.lang.ClassNotFoundException:
> > com.amadego.cast.webclient.data.LocalitaData from [Module
> > "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]:
> > org.apache.tapestry5.ioc.internal.OperationException:
> > java.lang.ClassNotFoundException:
> > com.amadego.cast.webclient.data.LocalitaData from [Module
> > "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
> >         at
> > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl.createInstantiatorForClass(ComponentInstantiatorSourceImpl.java:227)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl.getInstantiator(ComponentInstantiatorSourceImpl.java:217)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > $ComponentInstantiatorSource_5ee3f5f438c.getInstantiator(Unknown Source)
> >  at
> > org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:225)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:222)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.pageload.PageLoaderImpl.createAssembler(PageLoaderImpl.java:221)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.pageload.PageLoaderImpl.getAssembler(PageLoaderImpl.java:211)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.pageload.PageLoaderImpl$3.invoke(PageLoaderImpl.java:183)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.pageload.PageLoaderImpl$3.invoke(PageLoaderImpl.java:178)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:177)
> > [tapestry-core-5.3.7.jar:]
> >         at $PageLoader_5ee3f5f4373.loadPage(Unknown Source)     at
> > org.apache.tapestry5.internal.services.PageSourceImpl.getPage(PageSourceImpl.java:104)
> > [tapestry-core-5.3.7.jar:]
> >         at $PageSource_5ee3f5f4370.getPage(Unknown Source)      at
> > org.apache.tapestry5.internal.services.NonPoolingRequestPageCacheImpl.get(NonPoolingRequestPageCacheImpl.java:82)
> > [tapestry-core-5.3.7.jar:]
> >         at $RequestPageCache_5ee3f5f436f.get(Unknown Source)    at
> > $RequestPageCache_5ee3f5f4369.get(Unknown Source)    at
> > org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:55)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.services.TapestryModule$38.handle(TapestryModule.java:2222)
> > [tapestry-core-5.3.7.jar:]
> >         at $PageRenderRequestHandler_5ee3f5f436d.handle(Unknown Source) at
> > $PageRenderRequestHandler_5ee3f5f4366.handle(Unknown Source) at
> > org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.services.InitializeActivePageName.handlePageRender(InitializeActivePageName.java:47)
> > [tapestry-core-5.3.7.jar:]
> >         at $ComponentRequestHandler_5ee3f5f4367.handlePageRender(Unknown
> > Source)        at
> > $ComponentRequestHandler_5ee3f5f435f.handlePageRender(Unknown Source)
> >   at
> > org.apache.tapestry5.internal.services.RootPathDispatcher.dispatch(RootPathDispatcher.java:66)
> > [tapestry-core-5.3.7.jar:]
> >         at $Dispatcher_5ee3f5f4362.dispatch(Unknown Source)     at
> > $Dispatcher_5ee3f5f435c.dispatch(Unknown Source)     at
> > org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:302)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
> > [tapestry-core-5.3.7.jar:]
> >         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> > org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:902)
> > [tapestry-core-5.3.7.jar:]
> >         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> > org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:892)
> > [tapestry-core-5.3.7.jar:]
> >         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> > org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:90)
> > [tapestry-core-5.3.7.jar:]
> >         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> > org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:105)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:95)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
> > [tapestry-ioc-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:119)
> > [tapestry-core-5.3.7.jar:]
> >         at $RequestHandler_5ee3f5f435d.service(Unknown Source)  at
> > $RequestHandler_5ee3f5f4351.service(Unknown Source)  at
> > org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:253)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:53)
> > [tapestry-core-5.3.7.jar:]
> >         at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source)
> >      at
> > org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
> > [tapestry-core-5.3.7.jar:]
> >         at $HttpServletRequestFilter_5ee3f5f434f.service(Unknown Source)
> >       at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source)
> >    at
> > org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
> > [tapestry-core-5.3.7.jar:]
> >         at $HttpServletRequestHandler_5ee3f5f4353.service(Unknown Source)
> >      at $HttpServletRequestHandler_5ee3f5f434e.service(Unknown Source)
> >  at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> > [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> >         at
> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920)
> > [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> >         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> > Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException:
> > com.amadego.cast.webclient.data.LocalitaData from [Module
> > "deployment.Troubleshooting-1.0.ear:main" from Service Module Loader]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.ClassWriter.getCommonSuperClass(ClassWriter.java:1588)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.ClassWriter.getMergedType(ClassWriter.java:1559)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1406)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.Frame.merge(Frame.java:1308)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.MethodWriter.visitMaxs(MethodWriter.java:1353)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:635)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.tree.MethodNode.accept(MethodNode.java:557)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.asm.tree.ClassNode.accept(ClassNode.java:361)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.PlasticClassPool.toBytecode(PlasticClassPool.java:187)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.PlasticClassPool.realize(PlasticClassPool.java:140)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.PlasticClassPool.realizeTransformedClass(PlasticClassPool.java:122)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.PlasticClassImpl.createInstantiator(PlasticClassImpl.java:358)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.PlasticClassPool.loadAndTransformClass(PlasticClassPool.java:350)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.plastic.PlasticClassLoader.loadClass(PlasticClassLoader.java:38)
> > [plastic-5.3.7.jar:]
> >         at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> > [rt.jar:1.6.0_45]
> >         at
> > org.apache.tapestry5.internal.plastic.PlasticClassPool.getClassInstantiator(PlasticClassPool.java:516)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.plastic.PlasticManager.getClassInstantiator(PlasticManager.java:189)
> > [plastic-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl$2.invoke(ComponentInstantiatorSourceImpl.java:235)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.internal.services.ComponentInstantiatorSourceImpl$2.invoke(ComponentInstantiatorSourceImpl.java:229)
> > [tapestry-core-5.3.7.jar:]
> >         at
> > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74)
> > [tapestry-ioc-5.3.7.jar:]
> >         ... 73 more
> >
> >
> >
> >
> >
> > > Sent: Friday, December 11, 2015 at 11:16 PM
> > > From: "Thiago H de Paula Figueiredo" <[hidden email]>
> > > To: "Tapestry users" <[hidden email]>
> > > Subject: Re: Is tapestry plastic incompatible with JEE specs?
> > >
> > > On Fri, 11 Dec 2015 19:20:14 -0200, Luca Arzeni <[hidden email]>
> > wrote:
> > >
> > > > Hi Jens,
> > >
> > > Hi!
> > >
> > > > I like it, but if these problems cannot be solved, it may be better for
> > > > me to migrate to Guice or Spring.
> > >
> > > Common, you don't need or want to do that. Have you checked that the
> > > incredibly useful Tapestry JumpStart runs on JBoss?
> > > http://jumpstart.doublenegative.com.au/jumpstart6.0/servers_jboss_7.html
> > .
> > > Or this? https://wiki.apache.org/tapestry/HowToRunTapestry5OnJBoss7Dot1
> > >
> > > By the way, please post the full stack trace. The important part of it
> > got
> > > left out when you copied it.
> > >
> > > --
> > > Thiago H. de Paula Figueiredo
> > > Tapestry, Java and Hibernate consultant and developer
> > > http://machina.com.br
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

based2
In reply to this post by larzeni
https://translate.google.com/translate?sl=fr&tl=en&js=y&prev=_t&hl=fr&ie=UTF-8&u=http%3A%2F%2Fjavaetmoi.com%2F2013%2F01%2Fisoler-classloader-ear-jboss%2F&edit-text=&act=url

Le 12/12/2015 15:08, Luca Arzeni a écrit :

> 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: "[hidden email]" <[hidden email]>
>> To: "Tapestry users" <[hidden email]>
>> 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 <[hidden email]>:
>>>
>>> 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: "[hidden email]" <[hidden email]>
>>>> To: "Tapestry users" <[hidden email]>
>>>> 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 <[hidden email]>:
>>>>>
>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

Thiago H de Paula Figueiredo
In reply to this post by larzeni
On Sat, 12 Dec 2015 16:42:51 -0200, Luca Arzeni <[hidden email]> wrote:

> Hi Dimitris,

Hi, Luca!

Thanks for the insights about JBoss. I've never used it, so I've learned  
some new stuff today and I thank you for that. :)

I agree with you when you say the problem is caused by JBoss separating  
which classloader can access which classes (or classpaths). Is this  
defined by the Java EE specs? If yes, so yes, Tapestry doesn't support the  
spec fully.

Well, at least you seem to have found a way to avoid this problem, and  
thanks for sharing it. ;)

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs? SADLY YES, BUT HERE IS A WORKAROUND

larzeni
In reply to this post by larzeni
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" <[hidden email]>
> To: "Tapestry Users" <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs? SADLY YES, BUT HERE IS A WORKAROUND

Jens Breitenstein
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" <[hidden email]>
>> To: "Tapestry Users" <[hidden email]>
>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs? SADLY YES, BUT HERE IS A WORKAROUND

larzeni
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" <[hidden email]>
> To: "Tapestry users" <[hidden email]>
> 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" <[hidden email]>
> >> To: "Tapestry Users" <[hidden email]>
> >> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is tapestry plastic incompatible with JEE specs?

Jens Breitenstein
In reply to this post by larzeni
Hi Luca

a) via Graddle I built the ear which is located below build/libs/.
b) I created a JBoss (Wildfly 9) Project, added the ear as external
dependency because Intellij did not notice it as project artifact (why
ever) and started it.
c) opened a webbrowser pointing to http://localhost:8080/webclient/

and I see the following in my console:

Connected to server
[2015-12-16 04:21:58,219] Artifact Troubleshooting-1.0.ear: Artifact is
being deployed, please wait...
16:21:58,317 INFO  [org.jboss.as.server.deployment] (MSC service thread
1-7) WFLYSRV0027: Starting deployment of "Troubleshooting-1.0.ear"
(runtime-name: "Troubleshooting-1.0.ear")
16:21:58,859 INFO  [org.jboss.as.server.deployment] (MSC service thread
1-8) WFLYSRV0207: Starting subdeployment (runtime-name:
"webclient-1.0.war")
16:21:59,171 INFO  [org.wildfly.extension.undertow] (ServerService
Thread Pool -- 19) WFLYUT0021: Registered web context: /webclient
16:21:59,192 INFO  [org.jboss.as.server] (management-handler-thread - 2)
WFLYSRV0010: Deployed "Troubleshooting-1.0.ear" (runtime-name :
"Troubleshooting-1.0.ear")
[2015-12-16 04:21:59,205] Artifact Troubleshooting-1.0.ear: Artifact is
deployed successfully
...
16:22:05,489 ERROR [stderr] (default task-2) else branch choosen...
16:22:05,490 ERROR [stderr] (default task-2) else branch completed
successfully!
16:22:11,475 ERROR [stderr] (default task-4) else branch choosen...
16:22:11,476 ERROR [stderr] (default task-4) else branch completed
successfully!
16:22:16,046 ERROR [stderr] (default task-5) else branch choosen...
16:22:16,046 ERROR [stderr] (default task-5) else branch completed
successfully!
...

I am running this version:

// LocalitaData l_localitaData2 = new LocalitaData(); // Uncomment this
row and the app will work

QueryStringConverter<LocalitaData> l_queryStringConverter = new
QueryStringConverter<LocalitaData>(); // Uncomment this row and the app
will crash


I did not modify any JBoss related configs, just plain install and fire
up IntelliJ without any issues...

Jens


Sorry for the delay, seems like my message sent yesterday never made it
to the mailing-list even sending succeeds without problems...strange

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]