Nested deployments, duplicate names and jsr77

[dimitris]

I'm looking into http://jira.jboss.com/jira/browse/JBAS-1305
(see also the discussion at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=58955)

I undestand there are 2 notions that currently don't map well to jsr77.

One is 'location'. The following deployments collide and only one gets registered in the jsr77 tree because we don't consider the path to a deployment having an impact on the ServiceModule ObjectName, at all.

deploy/test-service.xml
deploy/management/test-service.xml
or
file:/..../conf/jboss-service.xml
http://bla/bla/jboss-service.xml
or
deploy/a.sar/another.sar
deploy/a.sar/somedir/another.sar

My initial idea to solve this is having the deployment url, part of the ObjectName:
jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=iiop-service.xml,url=file:/X:/cvs/jboss-public/jboss-4.0/build/output/jboss-4.0.4.GA/server/all/deploy/iiop-service.xml

or subtract the path to the config dir and use this as the 'name':
jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=deploy/iiop-service.xml

(this will probably look better like conf/jboss-service.xml, farm/xxx.sar)

[dimitris]

The other notion is 'nesting'. I understand jsr77 indicates a single level of nesting of .war,.jar,.rar inside an .ear and that's all (or the modules can appear outside of an .ear but still we mark this with J2EEApplication=null)

In jboss we have almost arbitrary nesting, and I find it very hard to express this with jsr77.

We do allow a module inside a .sar, declaring the .sar as the enclosing J2EEApplication, but I'm not sure if this is a bug or a feature. (In this case I would still assume J2EEApplication should be null).

Any idea how to deal with this?

[mclaugs]

The Nesting feature of JBoss has always made the jsr77 expression of some deployment very hard to think about. Since we have defined a j2eeType of ServiceModule and Looking at the spec I would suggest this as a possible approach.

Lets assume you have this deployment.
fooSar.sar containing a fooEar.ear containing a fooWar.war

jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,Name=fooSar.sar
for the SAR

jboss.management.local:J2EEServer=Local,j2eeType=J2EEApplication,Name=fooEar.ear
for the EAR

jboss.management.local:J2EEServer=Local,J2EEApplication=fooEar.ear,j2eeType=WebApplication,ServiceModule=fooSar.sar,Name=fooWar.war
for the WAR

What I am thinking is that we do not treat a SAR like an application because a SAR archive can contain an application but it might also contain just a web archive or the other types as well, so I think having the J2EEApplication= key for the SAR can lead to a lot of confusion.

[dimitris]

I came to the conclusion that using J2EEApplication for wrapping non-ear modules is a bug. E.g. a war inside a sar that describes the parent .sar as being a J2EEApplication is not correct.

So I've removed this wrapping here: http://jira.jboss.com/jira/browse/JBAS-2026

A J2EEApplication with a non-null value really refers to an .ear. The TCK tests seem to agree with that.

Based on this, the org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase doesn't make sense, so I'll disable it. This is in Branch_4_2 and HEAD.

We need to rethink our jsr77 view of location and scoping and the discussion in this thread is a good start.