Classloader Isolation

[meetoblivion]

It looks like AS 6 doesn't maintain classloader isolation.  I found a few examples.

1. Deploy two applications (In my case, I deployed 2 WAR files) that are named differently.  Let's say that the first has a class org.jboss.ex1.MyStatelessBean and the second has a class org.jboss.ex2.MyStatelessBean, both of which are no interface SLSBs.  You will observe that the application server is attempting to inject the first into the second or the second into the first, result in class cast exceptions.  The no interface views should be local to the app, correct?

2. Deploy several applications (again, WAR files in my case) that have a common dependency on some library.  Within this library is a no interface view Singleton EJB.  You'll eventually run into a similar error.

Thoughts on these use cases? are they bad setups? GFv3 supported both of these.

[alesj]

Thoughts on these use cases? are they bad setups? GFv3 supported both of these.

I doubt CL isolation is the culprit.

IMO it's the EJB or Weld-int layer that misbehaves.

Can you provide a simple use case / example?

[jaikiran]

John Ament wrote:

It looks like AS 6 doesn't maintain classloader isolation.  I found a few examples.

1. Deploy two applications (In my case, I deployed 2 WAR files) that are named differently.  Let's say that the first has a class org.jboss.ex1.MyStatelessBean and the second has a class org.jboss.ex2.MyStatelessBean, both of which are no interface SLSBs.  You will observe that the application server is attempting to inject the first into the second or the second into the first, result in class cast exceptions.  The no interface views should be local to the app, correct?

Like Ales said, it's more of a server implementation issue from the looks of it. Is this JBoss AS 6.0.0.Final? I remember we had fixed some similar issue in JBoss EJB3 before 6.0.0.Final was released. Also can you provide more details about where these beans are being injected? Some sample code and the exception stacktrace will help.