[jboss-dev] DefaultJndiBinder use of jndi from constructor

[Scott Stark]

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/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.
>>>
>>>