WAS 6.1 ND Custom registry ConfigurationException on NameNotFoundException for comp/UserTransaction
hbartolin
I am using custom registry in WAS 6.1 cluster environment and I get this error only in cluster environment only once when server starts. What is wrong:
[2/5/07 9:27:04:509 GMT+01:00] 0000000a javaURLContex E NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. Exception stack trace:
javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at hr.etna.jmoneta.security.registry.MonetaDB2Registry.getUniqueUserId(MonetaDB2Registry.java:246)
at com.ibm.ws.security.registry.UserRegistryImpl.getUniqueUserId(UserRegistryImpl.java:446)
at com.ibm.websphere.security._UserRegistry_Stub.getUniqueUserId(_UserRegistry_Stub.java:379)
at com.ibm.ws.security.role.RoleBasedConfiguratorImpl.fillMissingAccessIds(RoleBasedConfiguratorImpl.java:706)
at com.ibm.ws.security.role.RoleBasedConfiguratorImpl.loadApplication(RoleBasedConfiguratorImpl.java:270)
at com.ibm.ws.security.core.distSecurityComponentImpl.configureRoleBasedAuthz(distSecurityComponentImpl.java:1222)
at com.ibm.ws.security.core.distSecurityComponentImpl.initialize(distSecurityComponentImpl.java:378)
at com.ibm.ws.security.core.distSecurityComponentImpl.startSecurity(distSecurityComponentImpl.java:305)
at com.ibm.ws.security.core.SecurityComponentImpl.startSecurity(SecurityComponentImpl.java:101)
at com.ibm.ws.security.core.ServerSecurityComponentImpl.start(ServerSecurityComponentImpl.java:281)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:977)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:673)
at com.ibm.ws.runtime.component.ApplicationServerImpl.start(ApplicationServerImpl.java:191)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:977)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:673)
at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:485)
at com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:192)
at com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:140)
at com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:461)
at com.ibm.ws.runtime.WsServer.main(WsServer.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at com.ibm.wsspi.bootstrap.WSLauncher.launchMain(WSLauncher.java:183)
at com.ibm.wsspi.bootstrap.WSLauncher.main(WSLauncher.java:90)
at com.ibm.wsspi.bootstrap.WSLauncher.run(WSLauncher.java:72)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at com.ibm.wsspi.bootstrap.WSPreLauncher.launchEclipse(WSPreLauncher.java:321)
at com.ibm.wsspi.bootstrap.WSPreLauncher.main(WSPreLauncher.java:89)
Caused by: javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1095)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
... 44 more
Paul Ilechko
> I am using custom registry in WAS 6.1 cluster environment and I get
> this error only in cluster environment only once when server starts.
> What is wrong:
>
> [2/5/07 9:27:04:509 GMT+01:00] 0000000a javaURLContex E NMSV0310E:
> A JNDI operation on a "java:" name cannot be completed because the
> server runtime is not able to associate the operation's thread with
> any J2EE application component. This condition can occur when the
> JNDI client using the "java:" name is not executed on the thread of a
> server application request. Make sure that a J2EE application does
> not execute JNDI operations on "java:" names within static code
> blocks or in threads created by that J2EE application. Such code does
> not necessarily run on the thread of a server application request and
> therefore is not supported by JNDI operations on "java:" names.
> Exception stack trace:
>
You're doing something illegal in your CUR initialization code.
hbartolin
> initialization code.
I think that is not case here because in 'public void initialize(Properties props)' method I am only reading property. Exception is in method 'public String getUniqueUserId(String userSecurityName)':
InitialContext ic=new InitialContext();
UserTransaction userTran=(UserTransaction) ic.lookup("java:comp/UserTransaction");
Paul Ilechko
It very clearly states in the WAS infocenter: "Make sure that your
implementation of the custom registry does not depend on any WebSphere
Application Server components such as data sources, enterprise beans,
and so on. Do not have this dependency because security is initialized
and enabled prior to most of the other WebSphere Application Server
components during startup. If your previous implementation used these
components, make a change that eliminates the dependency."
JNDI and Transaction support would clearly fall into this category.
Also, the CUR is used in the Node Agent and dMgr as well as in the
application servers, and the NA does not have a full J2EE environment.
hbartolin
The problem was that user was added in list of admins and that user does not exist in CUR.
Paul Ilechko
> The problem was that user was added in list of admins and that user does not exist in CUR.
You still should not be doing that JNDI lookup and starting a
transaction in your CUR. That will fail in some circumstances.