Thanks for catching this. Done in revision 539548. -Donald
Jarek Gawor wrote:
In my case that would be SwitchingServiceRefBuilder.java. But I think the same problem could happen in other builders too. I'm +1 for log.warn() change. Jarek On 5/18/07, Donald Woods <[EMAIL PROTECTED]> wrote:Which changed file is throwing the exception? ResourceRefBuilder.java? We can turn the throw() into a log.warn() for now, until this EJB case is fixed.... -Donald Jarek Gawor wrote: > Recently the GERONIMO-348 patch was committed. That is causing > problems with EJB deployments. Here's an example. > > ejb-xml.jar has 2 ejbs, and one of the ejbs has a service-ref entry: > > <enterprise-beans> > <session> > <service-ref></service-ref> > </session> > <session> > </session> > </enterprise-beans> > > The G plan has corresponding entries for the beans and one service-ref > overwrite. > > Now, during deployment and in case of ejbs the > moduleBuilder.buildNaming() function is called once per each bean. The > specDD parameter will point only the given bean's xml data but the > planDD parameter will always point to the entire G plan. That means > when buildNaming() is called for the second bean and even though it > has no service-refs, one service-ref overwrite will be discovered in > the G plan. And with the GERONIMO-348 patch the deployment will fail. > > So it seems like the ejb deployment processing needs to change to pass > only the relevant parts of the particular ejb as the planDD. I'm just > not sure if there is any code that relies on having the entire G plan > around... > > Jarek > >
smime.p7s
Description: S/MIME Cryptographic Signature
