4 Replies Latest reply on Jan 11, 2011 6:06 AM by adinn

Exception trace from JNDi via WS when using XTS demo on AS 6.0.0.Final

adinn Jan 10, 2011 12:01 PM

Hi Alessio,

I am seeing an exception trace from JNDI underneath the JBossWS code when I run the XTS demo on JBoss AS 6.0.0.Final. It does not appear to stop the demo from working correctly but it doesn't inspire confidence seeing errors in the console output. Here is a sample error:

15:59:16,187 INFO  [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] Creating Service {http://schemas.arjuna.com/ws/2005/10/wsarjtx}TerminationParticipantService from WSDL: vfs:/ssd/home/adinn/jboss/jbossas/jboss-6.0.0.Final/server/default/deploy/jbossxts.sar/ws-t11.jar/com/arjuna/schemas/ws/_2005/_10/wsarjtx/wsdl/wsarjtx-termination-participant-binding.wsdl
15:59:16,239 ERROR [org.jboss.wsf.framework.deployment.DefaultHttpEndpoint] JNDI not available neither in JSE environment nor in SAR archives.: javax.naming.NameNotFoundException: env not bound
    at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) [:5.0.5.Final]
    at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) [:5.0.5.Final]
    at org.jnp.server.NamingServer.getObject(NamingServer.java:785) [:5.0.5.Final]
    at org.jnp.server.NamingServer.lookup(NamingServer.java:396) [:5.0.5.Final]
    at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728) [:5.0.5.Final]
    at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:835) [:5.0.5.Final]
    at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) [:5.0.5.Final]
    at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_21]
    at org.jboss.wsf.common.invocation.AbstractInvocationHandlerJSE.getJNDIContext(AbstractInvocationHandlerJSE.java:123) [:1.4.1.GA]
    at org.jboss.wsf.framework.deployment.DefaultHttpEndpoint.getJNDIContext(DefaultHttpEndpoint.java:76) [:3.4.1.GA]
    at org.jboss.wsf.common.invocation.InvocationHandlerJAXWS.onEndpointInstantiated(InvocationHandlerJAXWS.java:70) [:1.4.1.GA]
    at org.jboss.wsf.common.invocation.AbstractInvocationHandlerJSE.init(AbstractInvocationHandlerJSE.java:59) [:1.4.1.GA]
    at org.jboss.wsf.common.invocation.AbstractInvocationHandlerJSE.invoke(AbstractInvocationHandlerJSE.java:91) [:1.4.1.GA]
    at org.jboss.wsf.stack.cxf.AbstractInvoker._invokeInternal(AbstractInvoker.java:164) [:3.4.1.GA]
    at org.jboss.wsf.stack.cxf.AbstractInvoker.invoke(AbstractInvoker.java:112) [:3.4.1.GA]
    at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) [:2.3.1]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_21]
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_21]
    at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_21]
    at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) [:2.3.1]
    at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) [:2.3.1]
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) [:2.3.1]
    at org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:224) [:2.3.1]
    at org.apache.cxf.ws.addressing.ContextUtils$1.run(ContextUtils.java:446) [:2.3.1]
    at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:253) [:2.3.1]
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
    at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]

The exceptions appear to be associated with service creation as shown in the preceding INFO message.

regards,

Andrew Dinn

1. Exception trace from JNDi via WS when using XTS demo on AS 6.0.0.Final

ropalka Jan 11, 2011 2:51 AM (in response to adinn)

I'll change it to warning. Is it OK with you?
I won't change it to anti pattern like

try { /* some code */ } catch (Exception ignore) {}
Actions
2. Re: Exception trace from JNDi via WS when using XTS demo on AS 6.0.0.Final

adinn Jan 11, 2011 4:55 AM (in response to ropalka)
Hi Richard
Richard Opalka wrote:

I'll change it to warning. Is it OK with you?
I won't change it to anti pattern like

try { /* some code */ } catch (Exception ignore) {}
Well, your preferred option is still going to generate a message which is redundant and, perhaps even, misleading (see below) and can only give unnecessary cause for concern.

The exception gets caught in DefaultHttpEndpoint.getJNDIContext(). Currently, it has two clients, InvocationHandlerJAXWS.onEndpointInstantiated() and ServletHelper.injectServiceAndHandlerResources(). Both of them are perfectly happy to receive a null value from the call i.e. they don't expect there to be a JNDI context. So, the warning that it does not exist is not necessary for these two clients. In fact it is unnecessary in all cases. If other clients need to warn that the JNDI context is not present they can test for a null return value and generate the warning themselves.

Your anti-pattern is not actually what is required to fix this. The current code in DefaultHttpEndpoint.getJNDIContext() looks like

try { /* lookup and return JNDI entry */ } catch (NamingException ) { /* log message */ return null; }

I suggest you change this to

try { /* lookup and return JNDI entry */ } catch (NamingException ) { return null; }

Catching a specific checked exception with a definite handling strategy is not really an anti-pattern.
Actions
3. Re: Exception trace from JNDi via WS when using XTS demo on AS 6.0.0.Final

ropalka Jan 11, 2011 5:55 AM (in response to adinn)

OK, this have been fixed in JBossWS trunk.
We do not log anymore, I changed it to comment.
Actions
4. Re: Exception trace from JNDi via WS when using XTS demo on AS 6.0.0.Final

adinn Jan 11, 2011 6:06 AM (in response to adinn)

Thanks, Richard.
Actions

Go to original post