I'd like to follow-up on the module context SPI discussion from the July 31st con call. There are a number of SPI methods that will be ambiguous w.r.t. module in the presence of an .ear with multiple 299- enabled modules. For example, EjbServices.resolveEjb(InjectionPoint injectionPoint) and JpaServices.resolvePersistenceContext(String unitName). These are both cases where the container side needs additional module context but there are probably equivalent cases for the webbeans side of the contracts. One way to solve this is to move the services registrations to the BeanDeploymentArchive level instead of on Bootstrap, since there is only one instance of Bootstrap for the entire .ear. Thoughts?

On Aug 11, 2009, at 12:51 PM, Pete Muir wrote: > > On 11 Aug 2009, at 15:48, Kenneth Saks wrote: > >> I'd like to follow-up on the module context SPI discussion from the >> July 31st con call. There are a number of SPI methods that will >> be >> ambiguous w.r.t. module in the presence of an .ear with multiple >> 299- >> enabled modules. >> >> For example, EjbServices.resolveEjb(InjectionPoint injectionPoint) >> and >> JpaServices.resolvePersistenceContext(String unitName). These >> are >> both cases where the container side needs additional module context >> but there are probably equivalent cases for the webbeans side of the >> contracts. >> >> One way to solve this is to move the services registrations to the >> BeanDeploymentArchive level instead of on Bootstrap, since there is >> only one instance of Bootstrap for the entire .ear. Thoughts? > > Agreed, I had seen this problem too. I had planned to add > BeanDeploymentArchive as a parameter to the resolve() method. > Alternatively we could support a certain services at the per-BDA > level. > > Which is easier to implement? From the JBoss AS side, AFAICT it's > easier to take the first path. I think the per-BDA is a better way to go. Otherwise we need to add the parameter to almost every method of five or more services.