[jboss-dev] DefaultJndiBinder use of jndi from constructor

[Ales Justin]

The DefaultJndiBinder was removed from Weld-int trunk.
We now do binding in JndiBinderDeployer:
* 
http://anonsvn.jboss.org/repos/jbossas/projects/weld-int/trunk/deployer/src/main/java/org/jboss/weld/integration/deployer/jndi/JndiBinderDeployer.java

I guess this means you'll have to move your jndi beans into deployers/,
otherwise PS::checkComplete on deployers phase will complain.

And of course JndiBinderDeployer would need a "depends" element.

Scott Stark wrote:
> I'm looking at moving the jndi beans into deploy, and one issue I have 
> run into is that the DefaultJndiBinder deployed from 
> deployers/beanvalidation.deployer/META-INF/bv-core-jboss-beans.xml is 
> attempting to access jndi from its ctor:
> 
> 19:59:25,942 ERROR [DefaultJndiBinder] Unable to create JNDI subcontext 
> for Bean Validation Factories: javax.naming.CommunicationException: 
> Receive timed out [Root exception is java.net.SocketTimeoutException: 
> Receive timed out]
>     at 
> org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1678)
>     at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1795)
>     at 
> org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:1106)
>     at 
> org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:1096)
>     at javax.naming.InitialContext.createSubcontext(InitialContext.java:464)
>     at 
> org.jboss.beanvalidation.util.DefaultJndiBinder.createSubContextForFactories(DefaultJndiBinder.java:65)
>     at 
> org.jboss.beanvalidation.util.DefaultJndiBinder.<init>(DefaultJndiBinder.java:57)
>     at 
> org.jboss.beanvalidation.util.DefaultJndiBinder.<init>(DefaultJndiBinder.java:51)
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>     at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>     at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>     at 
> org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:149)
>     at 
> org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
>     at 
> org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
>     at 
> org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:295)
>     at 
> org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:116)
>     at 
> org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:243)
>     at 
> org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
>     at 
> org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:111)
>     at 
> org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72)
>     at 
> org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
> 
> 
> I can get around this by adding a demand from the binder's Instantiated 
> state:
> 
>   <!-- Default JNDI name creator -->
>   <bean name="DefaultJndiBinder" 
> class="org.jboss.beanvalidation.util.DefaultJndiBinder">
>     <demand state="Instantiated">LocalNamingBean</demand>
>   </bean>
> 
> 
> but I'm wondering if this should be done from a more typical lifecycle 
> method to simplify dependency configuration.
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>