Re: GERONIMO-348 patch and issues with ejb deployments
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: > > > > > > > > > > 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
Re: GERONIMO-348 patch and issues with ejb deployments
On May 18, 2007, at 10:42 AM, 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. I'm good with that... Donald, Can you make this happen? --kevan
Re: GERONIMO-348 patch and issues with ejb deployments
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: > > > > > > > > > > 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 > >
Re: GERONIMO-348 patch and issues with ejb deployments
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: 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
