7:34 a.m.
I think we're talking about two different JndiBinderDeployers.
The one you are using right now is the old one,
which is the one that uses that JndiBinder bean,
hence no initial jndi lookup call at deployer deployment --> no failure.
The new one I pointed out is not used yet.
Afaik it was agreed we set BeanValidator directly on the Weld bootstrap,
and place the Weld bootstrap into jndi - which is what the new deployer
is doing.
So sorry, no magic there. :-)
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?
Ales Justin wrote:
> 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/s...
>
> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
------------------------------------------------------------------------
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development