I wouldn't put it in deploy/ atm,
as we don't have JBDEPLOY-135 implemented yet.
Which could potentially mean that some deployments
installed before your jndi bean is deployed,
would by-pass the "required" jndi deployer.
Scott Stark wrote:
Ok, I'll have the core jndi naming beans in deploy. Deployers
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
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:
>>> 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