Folks, it's time to address the problem of generalized Java EE
Web Beans needs to support injection of the following kinds of things:
* EE resources (e.g. JDBC datasources, etc)
* remote EJB references
* web service references
I believe we can treat all three as essentially the same kind of thing
in the spec. Let's call it a "EE resource reference", or whatever.
It's a new "kind" of Web Bean in Chapter 3. This functionality should
not impact any other part of the specification.
(An additional complication is that we need to unify the current
notion of a "JMS endpoint" with this functionality. I don't believe
that this is a difficult problem, we just need to make it a special
case of a "EE resource reference", that supports additional
I see two possible paths we could go down here:
The spec could simply say that for every "EE resource reference"
defined in web.xml or ejb-jar.xml, that a Web Bean exists with
deployment type @Production and no name. The scope and binding types
of this Web Bean have the usual defaults (@Depenent, @Current), but
these may be specified explicitly in web.xml or ejb-jar.xml:
The lifecycle of this Web Bean would be super-simple:
* Bean.create() would be equivalent to a JNDI lookup for the resource
* Bean.destroy() would simply discard the reference
There is just one problem with this approach: EE resource references
are by nature scoped to a particular EE module, whereas this is not
naturally the case for Web Beans (which are naturally EAR scoped). I
don't believe this is a really big problem but we would need to
institute an additional layer of validation to ensure that injection
points that refer to an EE resource are in the same module as the
resource ref declaration. This would be a new section in the spec, but
I don't believe it is difficult to write.
The second option would be to require explicit declaration of the
resource in web-beans.xml, thus making them an EAR-global declaration.
There are a couple of major problems with this:
* resources must be declared twice, in different places
* the two declarations are correlated via a global JNDI name, which:
- is still not really a well-defined construct in the EE spec
- cannot be properly validated at development time
Therefore I strongly prefer Option 1.