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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development_______________________________________________ jboss-development mailing list jboss-development@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development