Re: [jboss-dev] DefaultJndiBinder use of jndi from constructor
Ok, I'll have the core jndi naming beans in deploy. Deployers that
require a jndi service should have a dependency/demand on a
NamingService alias or maybe even InitialContextProvider since any
deployer making use of the jndi api during its lifecycle should have a
dependency. I should create links from the JBAS-6948 issue to external
deployer projects that will need dependencies declared. What is the weld
jira?
Ales Justin wrote:
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.
>>
>>