Missing EAR/WAR Isolation

[jason.greene]

It looks like we are missing EAR isolation in the trunk ear deployer. This results in several WS TCK failures:

http://jira.jboss.com/jira/browse/JBWS-1581

After looking at the code, it appears the intention is that EARStructure should be creating an isolated load repository config that is used by the ServiceClassLoaderDeployer. Any reason this has not been implemented yet?

Another reason for this failure is that WAR isolation is effectively disabled as well (WarClassLoadingDeployer is commented out). Why?

-Jason

[starksm64]

The EARStructure defines what the deployable content is in the ear along with what its classpath is. It does not define scoping. This should be coming from the metadata of the AppParsingDeployer (jboss-app.xml, deployer isolation property) that is passed to the ServiceClassLoaderDeployer which should be creating the scoped ULR. I'll have to check if this is wired up correctly. I'm working on the jboss5 testsuite so I'll look at the existing ear isolation tests today.

On the first port of the war deployer, jbossweb didn't have a mechanism to accept a class loader so it was commented out. It should be creating a scoped class loader by default though, but its probably still an implementation detail of the webcontainer. It does need to be pulled out so its available at the DeploymentUnit level. I assume that is what you are looking for?

[jason.greene]

The EARStructure defines what the deployable content is in the ear along with what its classpath is. It does not define scoping. This should be coming from the metadata of the AppParsingDeployer (jboss-app.xml, deployer isolation property) that is passed to the ServiceClassLoaderDeployer which should be creating the scoped ULR.

Ah I see, I was confused since currently, EARStructure is parsing jboss-app.xml.

The issue is the lack of a default if there is no jboss-app.xml (or no loader-repository-config). In the past we had a global isolation setting directly on the ear deployer. So I assumed we are keeping that. I take it we are moving away from it?

I'll have to check if this is wired up correctly. I'm working on the jboss5 testsuite so I'll look at the existing ear isolation tests today.

Great thanks.

-Jason

[jason.greene]

On the first port of the war deployer, jbossweb didn't have a mechanism to accept a class loader so it was commented out. It should be creating a scoped class loader by default though, but its probably still an implementation detail of the webcontainer. It does need to be pulled out so its available at the DeploymentUnit level. I assume that is what you are looking for?

Ah I see. Yes, the issue is that the WS deployer has to inspect every war (WS or not) by loading all servlet classes (and related WS classes if it is in fact a WS deployment). If the DeploymentUnit CL is not isolated, there is the possibility of a conflict with multiple deployments.

That said, fixing EAR isolation will resolve the WS TCK issues, since they separate the client and server side components in individual EARs.

[starksm64]

Ah I see, I was confused since currently, EARStructure is parsing jboss-app.xml.

The issue is the lack of a default if there is no jboss-app.xml (or no loader-repository-config). In the past we had a global isolation setting directly on the ear deployer. So I assumed we are keeping that. I take it we are moving away from it?

No, the global setting should be coming in from the AppParsingDeployer as a default. Its just not been ported over. I created this issue for that:
http://jira.jboss.com/jira/browse/JBAS-4214

Ah I see. Yes, the issue is that the WS deployer has to inspect every war (WS or not) by loading all servlet classes (and related WS classes if it is in fact a WS deployment). If the DeploymentUnit CL is not isolated, there is the possibility of a conflict with multiple deployments.

That said, fixing EAR isolation will resolve the WS TCK issues, since they separate the client and server side components in individual EARs.

I created this issue for the externalization of the war class loader.
http://jira.jboss.com/jira/browse/JBAS-4215

[thomas.diesler]

This should be fixed

[tdiesler@tdvaio trunk]$ svn log -v -r61470
------------------------------------------------------------------------
r61470 | [e-mail] | 2007-03-19 23:19:11 +0100 (Mon, 19 Mar 2007) | 1 line
Changed paths:
 M /trunk/server/src/main/org/jboss/deployment/AppParsingDeployer.java
 M /trunk/server/src/main/org/jboss/deployment/JBossAppParsingDeployer.java
 M /trunk/server/src/main/org/jboss/deployment/JBossApplicationObjectFactory.java
 M /trunk/system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java

Fix EAR scoping with <loader-repository>

[starksm64]

I have further added the isolation and callByValue flags to the ear and ejb deployers:

ear-deployer-beans.xml:
 <bean name="JBossAppParsingDeployer" class="org.jboss.deployment.JBossAppParsingDeployer">
...
 <!-- A flag indicating if ear deployments should have their own scoped
 class loader to isolate their classes from other deployments.
 -->
 <property name="isolated">true</property>
 <!-- A flag indicating if the ear components should have in VM call
 optimization disabled.
 -->
 <property name="callByValue">true</property>
 </bean>

ejb-deployer-beans.xml:
 <bean name="EJB2xDeployer" class="org.jboss.ejb.deployers.EjbDeployer">

 <!-- A flag indicating if the ear components should have in VM call
 optimization disabled.
 -->
 <property name="callByValue">false</property>
 </bean>

Your change would pickup deployments with explicit jboss-app.xml isolation, now apps without any isolation config will pickup the ear default as well.