[wildfly-dev] problem binding to JNDI in subsystem extension

John Mazzitelli mazz at redhat.com
Sun Mar 15 17:37:17 EDT 2015


I have a custom subsystem extension I'm deploying in Wildfly 8.2. I hit a problem when trying to bind an object to JNDI.

In my AbstractAddStepHandler.performRuntime() (the Subsystem Add handler), I want to bind an object to JNDI, like this:

  InitialContext initialContext = new InitialContext();
  WritableServiceBasedNamingStore.pushOwner(context.getServiceTarget());
    try {
      initialContext.bind(jndiName, jndiObject); // <--- this sometimes throws exception you see below
    } finally {
      WritableServiceBasedNamingStore.popOwner();
    }

where "context" is the first parameter passed to the performRuntime() method, and "jndiName" is "java:global/example/demo/myname" and "jndiObject" is just a java.lang.String, like "hello".

The use of WritableServiceBasedNamingStore is recommended on the wiki: https://docs.jboss.org/author/display/WFLY8/JNDI+Reference - though I have no idea what it is doing :)

The problem is - each time I start my wildfly server, sometimes it works, other times it doesn't. It is as if there is a race condition somewhere on startup of the wildfly server. If it works, my JNDI object is bound properly; when it fails, this bombs with the exception I show below.

Anyone know what the problem is and how to fix?

====

javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662) [rt.jar:1.8.0_31]
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) [rt.jar:1.8.0_31]
	at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350) [rt.jar:1.8.0_31]
	at javax.naming.InitialContext.bind(InitialContext.java:425) [rt.jar:1.8.0_31]
	at org.demo.extension.SubsystemAdd.performRuntime(SubsystemAdd.java:153)
	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:354) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]


More information about the wildfly-dev mailing list