geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: JNDI lookup in trunk is broken?
Date Thu, 08 Feb 2007 21:44:21 GMT
After some investigation I'm doubting that the jndi problem was caused
by the jasper dependency shuffling I did for JSF.  I think dblevins
change in r505020 may have fixed the jndi problem but like Sachin my
build is currently failing in modules/geronimo-openenb-builder.  When
that problem is resolved I will verify.

Best wishes,
Paul

On 2/8/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
> OK thanks, I misunderstood where you suspected the bug was at.  BTW, I
> just found out that the lookup will also throw an NPE in a servlet...
> still investigating.
>
> Best wishes,
> Paul
>
> On 2/8/07, Jarek Gawor <jgawor@gmail.com> wrote:
> > Paul,
> >
> > The JSP was just an example. I originally saw that exception in a web
> > service (running in a servlet container) but wanted something simple
> > to replicate/demonstrate the error.
> >
> > Jarek
> >
> > On 2/8/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
> > > This is probably due to a change I made last night which introduced
> > > jsf support.  I couldn't get myfaces to work correctly unless it uses
> > > the same classloader as jasper and jstl. Adding it to a webapp's
> > > default env during deployment (like Joe did with jstl) didn't quite
> > > work.  I moved the jasper, jstl, and myfaces deps from the tomcat and
> > > jetty configs to a new config which the tomcat and jetty configs now
> > > depend on.  This is based on the approach Joe and David J. discussed
> > > here:  http://tinyurl.com/3bdzxr
> > > Besides enabling jsf, another motivation of separating jasper into its
> > > own config is that both tomcat and jetty use it for jsp support.
> > >
> > > I suspect that the problem you're seeing is caused by the fact that
> > > jasper's classloader is now a parent of the tomcat/jetty classloader.
> > >  So I think I need to move some dependencies around to make your JSP
> > > work again.   I will try to resolve this quickly, in the mean time I
> > > think your code should work if you precompile your jsp (see how this
> > > is done using the jspc plugin in the welcome app project).  Sorry for
> > > the trouble, getting jsf to work right has been much more complicated
> > > than I expected!
> > >
> > > If anyone has any insights or hints on a better way to set up the deps
> > > then my ears are wide open :-)
> > >
> > > Best wishes,
> > > Paul
> > >
> > > On 2/8/07, Jarek Gawor <jgawor@gmail.com> wrote:
> > > > From within a JSP, I'm doing:
> > > >
> > > >             Context ctx = new InitialContext();
> > > >             ctx = (Context) ctx.lookup("java:comp/env");
> > > >
> > > > and I get:
> > > >
> > > > Caused by: javax.naming.NamingException [Root exception is
> > > > java.lang.NullPointerException]
> > > >         at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:588)
> > > >         at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:533)
> > > >         at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:279)
> > > >         at javax.naming.InitialContext.lookup(InitialContext.java:351)
> > > >         at org.apache.jsp.StaxJSP_jsp._jspService(StaxJSP_jsp.java:71)
> > > >         ... 27 more
> > > > Caused by: java.lang.NullPointerException
> > > >         at org.apache.openejb.core.ivm.naming.java.javaURLContextFactory.getContext(javaURLContextFactory.java:72)
> > > >         at org.apache.openejb.core.ivm.naming.java.javaURLContextFactory.getObjectInstance(javaURLContextFactory.java:45)
> > > >         at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:584)
> > > >         ... 31 more
> > > >
> > > > Jarek
> > > >
> > >
> >
>

Mime
View raw message