EARStructure not deploying modules

[bill.burke]

The EARStructureDeployer is not adding its modules as subdeployments and they are not getting deployed.


I took a look at the JarStructure deployer and the candidate visitor seems to be doing:

deployers.determineStructure(child, metadata) if the module is not in the Metadata's ContextInfo map.

I'm not sure what to do here. Any pointers? Looking into it further.

thanks

[bill.burke]

well, first of all, the EARSTructure is always returning false :)

[starksm64]

That is one issue. I have come across some others in testing some of the testsuite ears and I'm working on them.

[bill.burke]

Another issue I found before lunch was that EARStructure needed to set the parent of the ear module's ContextInfo. Otherwise the parent was unable to be determined by the StructureMetaDataImpl.addContext method because the vfsPath was "" for the parent and "session1.jar" for the child. THe Comparator would always return 0 so the child would never be added to the list of contexts (the tree).

[starksm64]

That is a problem then that I'll have to look at.

[bill.burke]

I'm pretty sure determineStructure is not called on the EAR module as its classpath is null. Looking into this too.

[starksm64]

I'm sitting in it now for an ear deployment:

Thread [main] (Suspended (breakpoint at line 102 in EARStructure))
 EARStructure.determineStructure(VirtualFile, StructureMetaData, StructuredDeployers) line: 102
 BasicStructuredDeployers.determineStructure(VirtualFile, StructureMetaData) line: 76
 MainDeployerImpl.determineStructure(DeploymentContext) line: 528
 MainDeployerImpl.addDeploymentContext(DeploymentContext) line: 271
 ProfileServiceBootstrap.loadProfile(String) line: 365
 ProfileServiceBootstrap.bootstrap() line: 246
 ProfileServiceBootstrap(AbstractBootstrap).run() line: 89
 ServerImpl.doStart() line: 401
 ServerImpl.start() line: 340
 Main.boot(String[]) line: 210
 Main$1.run() line: 508
 Thread.run() line: not available

[starksm64]

I'm also not seeing the parent/child problem you mention. When the ear child module from the application.xml is added to the ear ContextInfo, the parent is matched up. This is for an unpacked ear.

[bill.burke]

I'm also not seeing the parent/child problem you mention. When the ear child module from the application.xml is added to the ear ContextInfo, the parent is matched up. This is for an unpacked ear.

Maybe because you are not deploying via a JBossTestCase and MainDeployer.deploy(URL)???

[bill.burke]

I'm sitting in it now for an ear deployment:

Thread [main] (Suspended (breakpoint at line 102 in EARStructure))
 EARStructure.determineStructure(VirtualFile, StructureMetaData, StructuredDeployers) line: 102
 BasicStructuredDeployers.determineStructure(VirtualFile, StructureMetaData) line: 76
 MainDeployerImpl.determineStructure(DeploymentContext) line: 528
 MainDeployerImpl.addDeploymentContext(DeploymentContext) line: 271
 ProfileServiceBootstrap.loadProfile(String) line: 365
 ProfileServiceBootstrap.bootstrap() line: 246
 ProfileServiceBootstrap(AbstractBootstrap).run() line: 89
 ServerImpl.doStart() line: 401
 ServerImpl.start() line: 340
 Main.boot(String[]) line: 210
 Main$1.run() line: 508
 Thread.run() line: not available

What I meant was that a module within the EAR is not getting determineStructure called. I know this for a fact as I'm stepping through...

Now where to put determineStructure? Within DefaultStructureBuilder?

BTW, can you please explain what DefaultStructureBuilder is trying to accomplish? Specifically, what is going on with all the Classpath stuff? Specifically, I need to know if the Classpath will only contain the EJB jar and not other jars so that I can scan propertly for annotations.

thanks

[starksm64]

That is possible. I would think any difference in vfs paths from those two paths indicates a vfs problem though, not a deployer issue as the paths should be consistent.

I'm working with the testsuite/output/lib/unpacked-ear1.ear to start with as it tries to deploy just about every type. It needs to be updated to include an ejb3 deployments as well now that the testsuite is java5 based.

[bill.burke]

That is possible. I would think any difference in vfs paths from those two paths indicates a vfs problem though, not a deployer issue as the paths should be consistent.

Not a VFS problem...The VFS path ends up being "" empty string because you are building the VFS based on the URL of the ear because it is being deployed through MainDeployer.deploy(URL)

[starksm64]

What I meant was that a module within the EAR is not getting determineStructure called. I know this for a fact as I'm stepping through...

Now where to put determineStructure? Within DefaultStructureBuilder?

BTW, can you please explain what DefaultStructureBuilder is trying to accomplish? Specifically, what is going on with all the Classpath stuff? Specifically, I need to know if the Classpath will only contain the EJB jar and not other jars so that I can scan propertly for annotations.

thanks

Ok. Its up to a given structure deployer to call out to the input deployers (or use the AbstractStructureDeployer.addAllChildren) to recursively process contexts. Right now its a determined type of structure deployer that is only creating child ContextInfos for those modules explicitly listed. They can't have nested deployments. This will have to be changed because the EARStructure does not really know what each type of module is in terms of strucuture. We should be doing an allAllChildren starting with each declared module.

The current EARStructure deployer creates a context for the ejb jar, and only includes the jars referenced by the module classpath manifest:

 ContextInfoImpl moduleContext = new ContextInfoImpl(module.getPathName());
 metaData.addContext(moduleContext);
 // Add the manifest locations
 addClassPath(root, module, false, true, moduleContext);

to include the jar the call should be addClassPath(root, module, true, true, moduleContext). The ejb jar should be in its own classpath, while a war should not.

DefaultStructureBuilder is a dumb mapping of what the structure deployers specified as the deployment in the StructureMetaData. It should not be doing anything else or else its overriding what the structure deployers indicated.

[bill.burke]

What I meant was that a module within the EAR is not getting determineStructure called. I know this for a fact as I'm stepping through...

Now where to put determineStructure? Within DefaultStructureBuilder?

BTW, can you please explain what DefaultStructureBuilder is trying to accomplish? Specifically, what is going on with all the Classpath stuff? Specifically, I need to know if the Classpath will only contain the EJB jar and not other jars so that I can scan propertly for annotations.

thanks

Ok. Its up to a given structure deployer to call out to the input deployers (or use the AbstractStructureDeployer.addAllChildren) to recursively process contexts. Right now its a determined type of structure deployer that is only creating child ContextInfos for those modules explicitly listed. They can't have nested deployments. This will have to be changed because the EARStructure does not really know what each type of module is in terms of strucuture. We should be doing an allAllChildren starting with each declared module.

addAllChildren isn't the way to go because the ear only deploys those things at the top level or those deployed in application.xml ... plus ... jars in the lib/ directory (for JPA).

So, why did you remove the code in the old EarStructure code that I wrote that created DeploymentContexts? WHo is responsible for creating the deployment contexts in the EAR and determining their structure?

I am really confused on WTF is going on. It was pretty clear before, but with this structure metadata it is not anymore...

[starksm64]

addAllChildren isn't the way to go because the ear only deploys those things at the top level or those deployed in application.xml ... plus ... jars in the lib/ directory (for JPA).

So, why did you remove the code in the old EarStructure code that I wrote that created DeploymentContexts? WHo is responsible for creating the deployment contexts in the EAR and determining their structure?

I am really confused on WTF is going on. It was pretty clear before, but with this structure metadata it is not anymore...

I said an addAllChildren that started at each file listed in the ear modules. The DeploymentContext is a mix of structure info and runtime metadata like the object models for ear descriptors. The StructureMetaData is to describe exactly what contexts in the vfs should be treated as deployment contexts, what the context classpaths are, and what the parent child relationships are. That is input to the MainDeployer to initiate the runtime deployment where the metadata can be obtained from the DeploymentContexts (created by the MainDeployer.StructureBuilder) using the associated virtual file and classpath info.