<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ok. Curiously, there was not a failure after the deployers were done
once I added the demands element I showed. Can the JndiBinderDeployer
use an on demand semantic that is conditional on a naming service
dependency showing up at a later deployment phase?<br>
<br>
Ales Justin wrote:
<blockquote cite="mid:4B02797A.2020603@gmail.com" type="cite">
  <pre wrap="">The DefaultJndiBinder was removed from Weld-int trunk.
We now do binding in JndiBinderDeployer:

<a class="moz-txt-link-freetext" href="http://anonsvn.jboss.org/repos/jbossas/projects/weld-int/trunk/deployer/src/main/java/org/jboss/weld/integration/deployer/jndi/JndiBinderDeployer.java">http://anonsvn.jboss.org/repos/jbossas/projects/weld-int/trunk/deployer/src/main/java/org/jboss/weld/integration/deployer/jndi/JndiBinderDeployer.java</a>

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:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.&lt;init&gt;(DefaultJndiBinder.java:57)
    at 
org.jboss.beanvalidation.util.DefaultJndiBinder.&lt;init&gt;(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:

  &lt;!-- Default JNDI name creator --&gt;
  &lt;bean name="DefaultJndiBinder" 
class="org.jboss.beanvalidation.util.DefaultJndiBinder"&gt;
    &lt;demand state="Instantiated"&gt;LocalNamingBean&lt;/demand&gt;
  &lt;/bean&gt;


but I'm wondering if this should be done from a more typical lifecycle 
method to simplify dependency configuration.

_______________________________________________
jboss-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
jboss-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
  </pre>
</blockquote>
<br>
</body>
</html>