Re: [jboss-as7-dev] Deployment Chain/Service interaction

On 12/3/10 11:52 AM, David M. Lloyd wrote: > On 12/03/2010 11:45 AM, Jason T. Greene wrote: >> On 12/2/10 9:28 PM, David M. Lloyd wrote: >> e to add one manifest entry. >>> >>> If implicitly detecting EJB interdependencies based on annotations >>> becomes a requirement, I see other downsides as well. For example this >>> would mean that at a container level, there can only be one EJB with a >>> given interface name (otherwise there'd be no way to "wire" reliably), >>> which means that deploying multiple EJB JARs defining an EJB with the >>> same class or interface name is impossible for no good reason. EJBs are >>> normally identified by app name/module name/bean name - or in the case >>> of top level EJB JARs, just module name/bean name - and by having >>> detection based upon a global EJB name scope we defeat this. >> >> @EJB though specifies a unique bean via either a comp/module ref (which >> uses unique identifiers in the DD), OR via lookup and a JNDI path that >> points to one of the unique jndi paths of the ejb. > > Yes, and @Resource works the same way I believe. However I think it's > OK to require the dependency to be available by one of the two > mechanisms to have this actually work. The alternative is pretty > complex - i.e. using some rule-based strategy to determine what implicit > dependencies to add - but maybe it's something we can add in a later > release? > > In other words, there are two issues at play: > > 1. Type-based resolution. By spec, this happens in the scope of what is > available via Class-Path; It's slightly more extensive, as it's defined as per-application. So this means everything in an EAR following the standard isolation rules. The important thing though is that it doesn't escape the TLD, which make the rules much easier. So we don't have to consider root level ejb jars for example.