JNDI env-entry + env not bound

[dduchaine]

Configuration:
JBoss4.0.3SP1 with embedded Tomcat

When deploying a webapp, <env-entry> elements specified in web.xml are read (we can see it in the log file) but are not accessible from a Struts action through JNDI using

context.lookup("java:comp/env/anEnvEntry");

any idea?

David D.

[dduchaine]

We get a:
javax.naming.NameNotFoundException: env not bound

[starksm64]

The struts action has an incorrect context class loader, or has introduced a jndi.properties that is corrupting the naming environment. Stacktrace is step 1.

[dduchaine]

Could it be related? We configured a virtual host this way (stacktrace below):

<Host name="domainname.com" appBase="/home/virtual/site8/fst/var/www/html" autoDeploy="false" deployXML="false">
 <DefaultContext allowLinking="true" useNaming="true" override="true"/>
 <Context docBase="." path=""/>
 <Alias>www.domainname.com</Alias>
 <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="domainname_com-" suffix=".log" pattern="common" directory="${jboss.server.home.dir}/log"/>
</Host>

2006-04-05 15:00:25,849 WARN [org.apache.struts.action.RequestProcessor] Unhandled Exception thrown: class javax.naming.NameNotFoundException
2006-04-05 15:00:25,851 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[domainname.com].[/].[action]] Servlet.service() for servlet action threw exception
javax.naming.NameNotFoundException: env not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:514)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:522)
at org.jnp.server.NamingServer.getObject(NamingServer.java:528)
at org.jnp.server.NamingServer.lookup(NamingServer.java:252)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:610)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:701)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.icube.struts.LoginActions.login(LoginActions.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:276)
at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:196)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

[dduchaine]

Th problem doesn't occur when the webapp is deployed as a .war archive in the /deploy directory.

[dduchaine]

The problem still occur when the webapp is deployed as an exploded virtual host. See above for server.xml .

Do we still have to specifiy a jboss-web.xml since only env-entry elements are to be available via JNDI?

[ipojman]

I have the same issue - did you ever solve the problem?

I think this is because when you deploy something directly in tomcat, it's not using jboss's JNDI context. So i would think you could simply define the resource in the server.xml itself. But apparently that doesn't work either ...

still working on it.

[dduchaine]

Found the problem. Virtual host's files MUST be deployed in the deploy directory. I simply put a symbolic link (on Linux) named with a .war suffix

For symbolic links on Windows, see http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3887963


Also, I removed the
appBase="c:\\domaindirectory"
autoDeploy="false"
deployXML="false"

attributes found in the Host element in server.xml
(which was used to specify the webapp's root directory)

Now the webapp is hooked into JBoss and JNDI, datasources, JAAS are accessible as expected.

thanks for your time