-
1. Re: jee module's alt-dd
starksm64 Mar 26, 2008 5:00 PM (in response to aloubyansky)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 -
2. Re: jee module's alt-dd
aloubyansky Mar 27, 2008 8:39 AM (in response to aloubyansky)"scott.stark@jboss.org" wrote:
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. -
3. Re: jee module's alt-dd
adrian.brock Mar 27, 2008 9:22 AM (in response to aloubyansky)"scott.stark@jboss.org" wrote:
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");
-
4. Re: jee module's alt-dd
starksm64 Mar 27, 2008 2:01 PM (in response to aloubyansky)"alex.loubyansky@jboss.com" wrote:
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."adrian@jboss.org" wrote:
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);
-
5. Re: jee module's alt-dd
adrian.brock Mar 28, 2008 7:54 AM (in response to aloubyansky)"scott.stark@jboss.org" wrote:
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 -
6. Re: jee module's alt-dd
adrian.brock Mar 28, 2008 7:54 AM (in response to aloubyansky)"adrian@jboss.org" wrote:
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. -
7. Re: jee module's alt-dd
aloubyansky Apr 4, 2008 6:07 AM (in response to 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. -
8. Re: jee module's alt-dd
aloubyansky Apr 11, 2008 9:03 AM (in response to 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); }
-
9. Re: jee module's alt-dd
adrian.brock Apr 11, 2008 9:22 AM (in response to aloubyansky)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. -
10. Re: jee module's alt-dd
aloubyansky Apr 11, 2008 9:39 AM (in response to 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. -
11. Re: jee module's alt-dd
adrian.brock Apr 11, 2008 9:54 AM (in response to aloubyansky)"alex.loubyansky@jboss.com" wrote:
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. -
12. Re: jee module's alt-dd
aloubyansky Apr 14, 2008 10:49 AM (in response to 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. -
13. Re: jee module's alt-dd
aloubyansky Apr 16, 2008 11:09 AM (in response to 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.
-
14. Re: jee module's alt-dd
aloubyansky Apr 17, 2008 5:32 AM (in response to aloubyansky)Fixed in the AbstractVFSParsingDeployer.