I've looked at this a bit and here's my current understanding of the problem. First, we are dealing with two different web application contexts (/console and /MonitoringPortlet) and both web app contexts have different JNDI trees with different resources. The console is basically forwarding a request from /console to /MonitoringPortlet. It looks like on Jetty when a request is forwarded from one context to another, the JNDI tree associated with the current thread does NOT change for the duration of the call. That means, when a monitoring portlet looks for resources in JNDI it actaully gets /console JNDI tree instead of its own. Your portlet works on Tomcat as Tomcat appears to be properly switching the JNDI trees during the call.
So this seems like a bug in Jetty but I couldn't really find much info on how this should work in the specs. Does anybody know? For now I opened a bug to track this issue: https://issues.apache.org/jira/browse/GERONIMO-3609 Jarek On Nov 16, 2007 11:03 AM, Viet Nguyen <[EMAIL PROTECTED]> wrote: > Hi All, > > I am having trouble looking up a DataSource from an EAR containing a > WAR (which is where the lookup takes place) using JNDI. I find it to > be really weird, because I can look up the DataSource fine if I do it > through a JSP page or a servlet. However, when I try to look it up in > portlet code, the jndi name does not seem to be visible, although it > is visible in the JNDI viewer. Additionally, I have successfully > looked it up through jsp and servlets. > > This is only a problem in Jetty, because the same code works fine for Tomcat. > > Is this possibly a Geronimo/XBean bug in how we bind JNDI names? I am > not familiar with the jndi binding process, so any expertise in that > area or the portlet area will be much appreciated. > > Thanks, > Viet >
