Thanks, David. Not yet. I think it is caused by the moduleName created by the ModuleBuilder. For while adding sub gbeans, moduleName is always used to create the abstractName. I will try jetty later. Ivan
2009/5/25 David Jencks <[email protected]> > That seems like a bug to me... it's probably a small code change to fix if > you can figure out where :-) Does jetty do the same thing? > thanks > david jencks > > On May 25, 2009, at 5:17 AM, Ivan wrote: > > Hi, > I have some confusion about those artifact ids while deploying an EAR > package. > While deploying an EAR package, the deployer will create a > ConfigurationData gbean for the EAR and all the WARs under the EAR. The > problem is those Configuations represent those WAR pacakges in the EAR. > Those gbeans do not have the same artifact with the Configuration > contains them. They have the same artifact id with the EAR Configuration. > Let's take the console-tomcat for an example. > The artifactId for the *console-tomcat* (EAR) is * > org.apache.geronimo.plugins/console-tomcat/2.2-SNAPSHOT/car* > The artifactId for the *portal-driver.war* (a WAR in the EAR) is * > org.apache.geronimo.plugins/console-tomcat_portal-driver.war/2.2-SNAPSHOT/car > * > But the gbeans contained by the *portal-driver.war*'s abstract name is > *org.apache.geronimo.plugins/console-tomcat/2.2-SNAPSHOT/car*?J2EEApplication=org.apache.geronimo.plugins/console-tomcat/2.2-SNAPSHOT/car,WebModule=portal-driver.war,j2eeType=GBean,name=CARExportForward > > So is it the correct behavior, I guess that some JIRAs are caused by > this. > Thanks for any comment ! > -- > Ivan > > > -- Ivan
