I tried it with 2.2-jetty, the same result with 2.2 Tomcat :-( 2009/5/25 Ivan <[email protected]>
> 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 > -- Ivan
