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

On 12/3/10 1:00 PM, David M. Lloyd wrote: > On 12/03/2010 12:21 PM, Jason T. Greene wrote: >> 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. > > That's exactly what Scott proposes though: that top-level deployments > have a special search scope. > >>> 2. Actual availability of implementation classes. >>> >>> My feeling is that both should be handled via explicit dependencies in >>> all cases. Scott is saying that these could be implicit by treating all >>> top-level deployments as a part of a sort of implicit "super-EAR" in >>> terms of #1 and consequently #2 to auto-wire dependencies at this >>> level, >>> which is *possible* but I argue is too complex to be worth it - at >>> least >>> in 7.0.0.GA. We'll have problems enough getting the simple cases to >>> work without borrowing trouble for the first release. >> >> Scott's suggestion is similar how I had been viewing this problem. We >> always import all "global" EE deployments. That's very easy to >> implement, and would work pretty much the same as what we have done >> historically, and complies with the spec. >> >> Auto-detecting is certainly more complex, but would be user friendly, >> and result in less packaging errors. >> >> Explicit module definitions is certainly the "future", and the least >> error prone, but it is border line on spec compliance, so it might need >> to be an optional capability vs a required one. I'm not entirely sure. > > That just means that by default, it's impossible to deploy two beans > with the same class as TLDs, so what's the point of having per-module > scope if we just disregard it? > Actually we do have a bit more wiggle room than I am letting on. Technically the spec doesn't require that local interfaces be accessible at all outside of an application (in fact it was originally intended that it they would not be, although I think such a restriction is silly). So explicit deps sound reasonable and technically comply (although I find the auto-writing notion extremely powerful) So really the only thing the spec requires is rars that are used, and those are much easier to resolve. However, in most cases they are accessed through standard interfaces (JDBC/JMS). So we can get by not doing it here as well. I'm fine saying this is a > 7.0 feature, if we choose to do it; however, I think we should try and do our processing in a such a way that we don't outright prevent it.