JBossAppParsingDeployer issue

[starksm64]

A problem with the JBossAppParsingDeployer is that there can be an ear that only contains a META-INF/jboss-app.xml. This is not being processed correctly because there is no J2eeApplicationMetaData input if there is no META-INF/application.xml. We are throwing away the J2eeApplicationMetaData determined by the EARStructure deployer which is the deployer that has the implicit ear contents logic that is based on structure/annotations. We need the ability for a structure deployer to add attachments that can be used as input to parsing deployers.

I guess the correct place for this is in the StructureMetaData/ContextInfo, however, this only supports PredeterminedManagedObjects. It would also need to support TransientManagedObjects.

[starksm64]

I created JBMICROCONT-199 for this and have checked that change into the structure deployer layer. A new snapshot release is needed to allow the EARStructure to propagate the J2eeApplicationMetaData. I have tested this locally and the ear with only the jboss-app.xml is being processed correctly.

[adrian.brock]

This is wrong.

e.g. What if I want to deploy an EAR programatically where I tell it upfront
what the structure and metadata is.

i.e. it doesn't go through either the structure or the parsing deployer,
it uses the structure and metadata I've told it to use when I did the programmtic
deployment.

I'm I supposed to know to add the transient managed object that represents
the context root to the war context I create manually, or should I expect it to
pick it from the J2eeApplicationMetaData where I defined it?

The correct solution is to have a seperate deployer that looks
for application level metadata when processing subdeployments.

In principle there is not just the context-root that can defined at the ear
level, one could also provide things like a default "call-by-value" in jboss-app.xml, etc.

The creator of the deployment (including the profile service) should not
be expected to know what transient managed objects need to be created.
That is just an implementation detail of one way the deployers can "talk to each other".

Also to make this work at all, the transient managed objects would
have to be serialized such that a remote caller can add this information
and the profile service can remember what they were when re-creating the deployment,
this doesn't sound correct to me.

[starksm64]

This is wrong.

e.g. What if I want to deploy an EAR programatically where I tell it upfront
what the structure and metadata is.

i.e. it doesn't go through either the structure or the parsing deployer,
it uses the structure and metadata I've told it to use when I did the programmtic
deployment.

Then the deployer processing has to support complete vs incomplete inputs. I can have a complete programmatic specification, or multiple partial sources as is the case where javaee naming conventions along with a jboss-app.xml is used to define the contents of an ear. I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment.

I'm I supposed to know to add the transient managed object that represents
the context root to the war context I create manually, or should I expect it to
pick it from the J2eeApplicationMetaData where I defined it?

The correct solution is to have a seperate deployer that looks
for application level metadata when processing subdeployments.

In principle there is not just the context-root that can defined at the ear
level, one could also provide things like a default "call-by-value" in jboss-app.xml, etc.

The creator of the deployment (including the profile service) should not
be expected to know what transient managed objects need to be created.
That is just an implementation detail of one way the deployers can "talk to each other".

Right, there are multiple types of component level data that can be specified at the ear level. There are two level of metadata for the javaee components, ear and component. I don't see how introducing another deployer that maps from J2eeApplicationMetaData to the component specific value is better than having the component deployer look in two places. Something produces the J2eeApplicationMetaData (the EARStructure or another implicit AppParsingDeployer that runs when there is no application.xml, or programmatic definition), and component deployers look to the component level source and then to the ear level if needed. Nothing needs to know what the component level piece of metadata for the context-root is.

Also to make this work at all, the transient managed objects would
have to be serialized such that a remote caller can add this information
and the profile service can remember what they were when re-creating the deployment,
this doesn't sound correct to me.

A remote caller is passing in the ear and having the structure/regular deployers process it. A profile service impl may only be storing the raw ear with just the META-INF/jboss-app.xml and running through the full deployment processing every time, or it may be saving off all metadata as predetermined overrides. I don't see where there is an intermediate situation where a remote caller is providing transient managed objects.

[adrian.brock]

I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment.

Because the structural deployer is not invoked if I tell it explicitly what the
structure of the ear is. It is also not invoked if I add a META-INF/jboss-structure.xml

Describing the structure programmatically is just a case of adding the
structure metadata equivalent of META-INF/jboss-structure.xml to the deployment.

In order:
1) Is there is a predetermined StructureMetadata attachment?
2) Is there a META-INF/jboss-structure.xml
3) Is it an EAR - EARStructure.

Only if (1) and (2) fail will the EARStructure get invoked.

So in summary you can't assume that a structural deployer will be invoked.
It shouldn't do anything other than creating structure (and only then
when it is invoked because there isn't an explicit structure).

[starksm64]

I don't see how allowing the structural parse to introduce deployment metadata has any affect on a programmatic deployment.

Because the structural deployer is not invoked if I tell it explicitly what the
structure of the ear is. It is also not invoked if I add a META-INF/jboss-structure.xml
...

Ok, that is the real problem but I'm ignoring why this has any impact on programmatic deployments other than that to properly provide the structure metadata for an ear without an application.xml, you would have to also provide the J2eeApplicationMetaData. It is too much to assume this will also be programmatic available, so if that is what your saying I agree.

I have created an EARContentsDeployer that is ordered after the AppParsingDeployer and runs on ears without META-INF/application.xml to produce the implicit J2eeApplicationMetaData. The jboss-app.xml only ear is being correctly processed with this deployer in the chain.

[anil.saldhana]

An immediate issue that I am noticing is if there exists a jboss-app.xml that defines a security domain and there is no jboss.xml in the EAR, then the ApplicationMetaData that gets generated in the process has lost the merge from the ear level settings, because the merge of the security domain is currently being done in the JBossEJBParsingDeployer.

So no jboss.xml, implies no invocation of the JBossEJBParsingDeployer.

So should this merging be also done in the EjbParsingDeployer?

[adrian.brock]

An immediate issue that I am noticing is if there exists a jboss-app.xml that defines a security domain and there is no jboss.xml in the EAR, then the ApplicationMetaData that gets generated in the process has lost the merge from the ear level settings, because the merge of the security domain is currently being done in the JBossEJBParsingDeployer.

So no jboss.xml, implies no invocation of the JBossEJBParsingDeployer.

So should this merging be also done in the EjbParsingDeployer?

The parsing deployers should not be doing anything except parsing
(and maybe doing things like filling in the VFS url which isn't known to the parser
but is in the metadata).

Any modification of the metadata after parsing should be in a seperate deployer.
The parsing deployers aren't even guaranteed to be called if the metadata is passed
in programmatically.

[anil.saldhana]

http://jira.jboss.com/jira/browse/JBAS-4706

I have opened a JIRA issue for this.