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. >>> >>> _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development