geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <jga...@gmail.com>
Subject Re: GERONIMO-348 patch and issues with ejb deployments
Date Fri, 18 May 2007 14:42:40 GMT
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 <dwoods@apache.org> 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
> >
> >
>
>

Mime
View raw message