jee module's alt-dd

[aloubyansky]

I see that it has been mentioned here for the WAR modules http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131976

but that affects other modules too, e.g. EJB.

To mee it looks like the filename should either be passed as a parameter to deploy() or be available from the DeploymentUnit. Any other ideas?

I am looking into an EJB issue that is a consequence of this. I could dig into it further or if someone else was planning to work on this I'll jump on something else. Please let me know. Thanks.

[starksm64]

The only issue is how to generically integrate the alt-dd path. Most ee descriptor has an alt-dd child of the root element, so one way to handle this would be to extend AbstractParsingDeployerWithOutput to have an alt-dd property that specifies element name of the alt-dd, and createMetaData(DeploymentUnit unit, String name, String suffix, String key) would do a simple jaxp query of the document to see if alt-dd path name exists. It would have to be encapsulated in another abstract method like:

 protected abstract String getAltName(DeploymentUnit unit, String name) throws Exception;

as we don't know how to obtain the input stream for the name at the AbstractParsingDeployerWithOutput level. The jaxp default impl would have to be added to AbstractVFSParsingDeployer.

http://jira.jboss.com/jira/browse/JBDEPLOY-27

[aloubyansky]

Most ee descriptor has an alt-dd child of the root element, so one way to handle this would be to extend AbstractParsingDeployerWithOutput to have an alt-dd property that specifies element name of the alt-dd

I guess, I misunderstand this. AFAICS, the alt-dd is specified in the application.xml per module. Like this

<application version="1.4"
 xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
 http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
 <module>
 <ejb>ejb.jar</ejb>
 <alt-dd>altDD_ejb.xml</alt-dd>
 </module>
 <module>
 <java>client.jar</java>
 <alt-dd>altDD_client.xml</alt-dd>
 </module>
</application>

The ModuleMetaData has a property for alt-dd but it's not used except in the web deployer.

[adrian.brock]

The only issue is how to generically integrate the alt-dd path. Most ee descriptor has an alt-dd child of the root element, so one way to handle this would be to extend AbstractParsingDeployerWithOutput to have an alt-dd property that specifies element name of the alt-dd, and createMetaData(DeploymentUnit unit, String name, String suffix, String key) would do a simple jaxp query of the document to see if alt-dd path name exists. It would have to be encapsulated in another abstract method like:

 protected abstract String getAltName(DeploymentUnit unit, String name) throws Exception;

as we don't know how to obtain the input stream for the name at the AbstractParsingDeployerWithOutput level. The jaxp default impl would have to be added to AbstractVFSParsingDeployer.

http://jira.jboss.com/jira/browse/JBDEPLOY-27

Why don't you make an interface, e.g.

public interface AltDD
{
 String getAltDD();
}

Then the metadata classes could implement it and parsing deployers check it
regardless of where it appears.

On Alex's point, these just need to be added as attachments by the EarStructure
and checked by the relevant parsing deployer.

In principle it should be possible to do the same thing programmatically
even for non-ears.

VFSDeployment d = new VFSDeployment(ejbjar);
d.addAttachment("EJBAltDD", "al.ternatelocation");

[starksm64]

I guess, I misunderstand this. AFAICS, the alt-dd is specified in the application.xml per module. Like this

...

The ModuleMetaData has a property for alt-dd but it's not used except in the web deployer.

Sure, your right, I was thinking it could also show up at the descriptor level. That would be silly.

Then the metadata classes could implement it and parsing deployers check it
regardless of where it appears.

...

On Alex's point, these just need to be added as attachments by the EarStructure
and checked by the relevant parsing deployer.

Good point, the EarStructure is where this should be done. The AltDD interface would need to be in the deployer project so that the general handling of the alt path can be handled in AbstractVFSParsingDeployer.

If were using the AltDD interface as the typed path/key, wouldn't the programtic usage be:

addAttachment(Class<T> type, T attachment);
VFSDeployment d = new VFSDeployment(ejbjar);
AltDD altDD = ...("al.ternatelocation");
d.addAttachment(AltDD.class, altDD);

[adrian.brock]

Good point, the EarStructure is where this should be done. The AltDD interface would need to be in the deployer project so that the general handling of the alt path can be handled in AbstractVFSParsingDeployer.

If were using the AltDD interface as the typed path/key, wouldn't the programtic usage be:

addAttachment(Class<T> type, T attachment);
VFSDeployment d = new VFSDeployment(ejbjar);
AltDD altDD = ...("al.ternatelocation");
d.addAttachment(AltDD.class, altDD);

You could use a class rather than a String to recognise the AltDD,
but you'd need more than one.
Remember a deployment can be both an EJB and a Web Deployment,
e.g. webservices where the web metadata is constructed programmatically
by the ws deployers

[adrian.brock]

Remember a deployment can be both an EJB and a Web Deployment,
e.g. webservices where the web metadata is constructed programmatically
by the ws deployers

Although I think in this case, the ws deployers run after the parsing
so it wouldn't actually conflict in this case.

[aloubyansky]

I am trying to make it work. I don't see how I can add an attachment in the EARStructure. Instead, I am doing this in the AppParsingDeployer. I override the parse(..) method like (for now just for ejb)

protected EarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EarMetaData root) throws Exception
 {
 VirtualFile earRoot = file.getParent().getParent();
 EarMetaData earMetaData = super.parse(unit, file, root);
 ModulesMetaData modules = earMetaData.getModules();
 if(modules != null && modules.size() > 0)
 {
 for(ModuleMetaData module : modules)
 {
 String alternativeDD = module.getAlternativeDD();
 if(alternativeDD != null && module.getType() == ModuleType.Ejb)
 {
 VirtualFile altDDFile = earRoot.getChild(alternativeDD);
 unit.addAttachment("ejb.altDD", altDDFile);
 }
 }
 }
 return earMetaData;
 }

Then in the EjbParsingDeployer in the init(..)

protected void init(VFSDeploymentUnit unit, EjbJarMetaData metaData, VirtualFile file) throws Exception
 {
 VFSDeploymentUnit earUnit = unit.getParent();
 if(earUnit != null)
 {
 VirtualFile altDD = (VirtualFile) earUnit.getAttachment("ejb.altDD");
 if(altDD != null)
 file = altDD;
 }
 super.init(unit, metaData, file);
 }

Am I getting it right?

About the AltDD interface being in the deployers project. If metadata classes are going to implement it it would make the metadata project depend on deployers. Which doesn't seem to be a good idea to me.

[aloubyansky]

A bit more generalized, how does this look? The change that is in this example in the EjbParsingDeployer could probably be in the SchemaResolverDeployer?

Index: org/jboss/deployment/AppParsingDeployer.java
+ protected EarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EarMetaData root) throws Exception
+ {
+ EarMetaData ear = super.parse(unit,file, root);
+ List<DeploymentUnit> children = unit.getChildren();
+ if(children != null)
+ {
+ for(DeploymentUnit child : children)
+ {
+ String moduleName = child.getSimpleName();
+ ModuleMetaData module = ear.getModules().get(moduleName);
+ if(module != null && module.getAlternativeDD() != null)
+ {
+ VirtualFile altDDFile = unit.getRoot().getChild(module.getAlternativeDD());
+ if(altDDFile == null)
+ throw new IllegalStateException("Failed to locate alternative DD '" + module.getAlternativeDD() + "' in " + unit.getRoot().getPathName());
+ child.addAttachment(child.getSimpleName() + ".altDD", altDDFile);
+ log.info("attached alt-dd " + altDDFile + " for " + child.getSimpleName());
+ }
+ }
+ }
+
+ return ear;
+ }
 }
Index: org/jboss/deployment/EjbParsingDeployer.java
 @Override
- protected void init(VFSDeploymentUnit unit, EjbJarMetaData metaData, VirtualFile file) throws Exception
+ protected EjbJarMetaData parse(VFSDeploymentUnit unit, VirtualFile file, EjbJarMetaData root) throws Exception
 {
- super.init(unit, metaData, file);
+ VirtualFile altDDFile = (VirtualFile) unit.getAttachment(unit.getSimpleName() + ".altDD");
+ if(altDDFile != null)
+ {
+ log.info("using alt-dd: " + altDDFile);
+ file = altDDFile;
+ }
+ return super.parse(unit, file, root);
 }

[adrian.brock]

Looks good.

But why are you using the unit.SimpleName() + ".altDD"
wouldn't it be more logical to use something like
EARMetaData.class.getName() + ".altDD"
or generically
getOutput().getName() + ".altDD"
that way you can have an altDD for every xml file in META-INF
with the override attachment metadata name based on the type.

[aloubyansky]

I don't have strong preferences here. If it looks more logical then I'll do it that way.

Except as it is done now, getOutput() is available only in the module deployer. The deployer that is attaching the altDD value (AppParsingDeployer in this case) has to use class names explicitly? I did it that way because the key construction was identical everywhere and that looked easier to me.

[adrian.brock]

I don't have strong preferences here. If it looks more logical then I'll do it that way.

Except as it is done now, getOutput() is available only in the module deployer. The deployer that is attaching the altDD value (AppParsingDeployer in this case) has to use class names explicitly? I did it that way because the key construction was identical everywhere and that looked easier to me.

Yes, but in the standard EAR metadata you have to know the type anyway.

 <module>
 <ejb>ejb.jar</ejb> // Implies EjbJarMetaData.class.getName().altdd
 <alt-dd>altDD_ejb.xml</alt-dd>
 </module>

But the real point is that In JBoss there can be other files in META-INF.
e.g. an altDD_jboss.xml for the same module
which could be specified in jboss-app.xml or could be specified by the deployer
programmatically.

[aloubyansky]

I've committed the change (with a testcase) to the SchemaResolverDeployer's parse(..) method

VirtualFile altDD = (VirtualFile) unit.getAttachment(getOutput().getName() + ".altDD");
 if(altDD != null)
 file = altDD;

I am going to create a separate issue in JBAS project for ejb, client and also war(?) deployers.

[aloubyansky]

I am going to re-open the issue and do the same for ObjectModelFactoryDeployer. This is needed for the connector alt-dd in EARs.

[aloubyansky]

Fixed in the AbstractVFSParsingDeployer.