It's quite tricky because the war and ejb module have the same name, Hence, they have the same hashcode because we are returning name.hashCode() in Module.hashCode().
r1130391 Change to moduleURI.hashCode() will fix this because the URI can identify a module. It should be fixed, I will trigger a G JCDI tck to see. On Thu, Jun 2, 2011 at 10:02 AM, Shawn Jiang <genspr...@gmail.com> wrote: > I'll take a look. > > > On Thu, Jun 2, 2011 at 8:27 AM, David Blevins <david.blev...@gmail.com>wrote: > >> Made great progress in CDI/EJB integration, but seems we have a general >> issue with deploying EARs the CDI TCK gives us so we aren't seeing it yet. >> >> It looks like the deploy is successful but the EJB module doesn't start. >> No errors in the log other than the webapp failing to start due to missing >> EJB jar classes. >> >> If someone could take a quick look that would be wonderful. I've attached >> an example EAR to the JIRA. >> >> >> -David >> >> On Jun 1, 2011, at 5:16 PM, David Blevins (JIRA) wrote: >> >> > CDI EAR deployment issue >> > ------------------------ >> > >> > Key: GERONIMO-5989 >> > URL: >> https://issues.apache.org/jira/browse/GERONIMO-5989 >> > Project: Geronimo >> > Issue Type: Bug >> > Security Level: public (Regular issues) >> > Components: deployment, javaee6 >> > Reporter: David Blevins >> > >> > >> > Attached is one of many EAR files produced by the CDI TCK that do not >> deploy. Both the EJB and WAR modules are found and created, but only the >> WAR starts and has none of the required jars in the classpath. >> > >> > -- >> > This message is automatically generated by JIRA. >> > For more information on JIRA, see: >> http://www.atlassian.com/software/jira >> >> > > > -- > Shawn > -- Shawn
