|
[
Permalink
| « Hide
]
Stephane Nicoll added a comment - 08/Aug/06 03:01 PM
applicable to which J2EE spec? I don't see this as mandatory so please provide more details / reference / sample.
The id is not mandatory, but it would enable eclipse deployment to be much more simpler. And since id is part of http://java.sun.com/xml/ns/j2ee/application_1_4.xsd
 it would be a good thing if you generated it. This patch adds the "id" attribute to the "module" element used by some tools (eclipse/wtp).
The id is constructed using the "groupid", "." (a dot), and "artifactid", that easily can be generated in other plugins (such as the eclipse plugin  ) Its requirement for websphere specific deployment descriptors like ibm-ejb-jar-ext.xmi.
I am not sure this patch is enough since theoretically I could deploy the same app more than once. with different deployment plans.
so the classifier should be also included in the ID if it is present .. maybe something like: groupId.artifactId.classifier I've ran into this problem as well.
Here is the use-case I am dealing with. The module ID's are used by IBM application server 5.1 (and 6.1 for that matter) to wire up all security roles and EJBs. While I won't be doing any security administration myself. I do have to provide unique id's to modules. The current work-around I am using right now. (we're running an inhouse repository by overriding central)
It's a bit different compared to the earlier patch. With this patch I can use a "moduleId" element within my ejbModule items. I've done this for the ejbModule only because this is just a proof of concept. The attached patch allows the module ID to be supplied explicitly through a "moduleId" configuration parameter; if none is supplied, "TYPE_groupId.artifactId[-classifier]" is used by default, where TYPE is the artifact type converted to uppercase (such as "WAR") and [-classifier] is included if the artifact has a classifier.
Module ID support has been added to the EJB, JAR, and Web module types only.
Thanks for the patch, the configuration parameter is the way to go. I'd like to suggest supporting it on all module types, not just those three. The id attribute is a special case in XML, it's allowed on any element so long as its value is unique in the document. I see no reason to support it on an arbitrary subset of module types. It might come in handy on one of the others. I'm new to EAR and WebSphere but it seems I will need an ID on the application tag also. Here is an existing application.xml used by the old Ant build:
<?xml version="1.0" encoding="ISO-8859-15"?> <!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd"> <application id="Application_ID"> <display-name>MyApp</display-name> <module id="WebModule_1102675755495"> <web> <web-uri>app.war</web-uri> <context-root>/app</context-root> </web> </module> <security-role id="SecurityRole_1102689931785"> <description></description> <role-name>appuser</role-name> </security-role> </application> |
|||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Minor
Generate id for modules in application.xml
