[webbeans-dev] RE: Java EE resource injection

Michael Keith MICHAEL.KEITH at oracle.com
Tue Jan 6 12:54:37 EST 2009


I think the problem should be rephrased, not for the purpose of philosophical consistency, 
but because I believe that it changes the nature of the problem.

"Web beans" does not need to support EE resource injection since EE container components 
already do. Again, this spec is in the business of defining new services, not new components.
If we are in agreement (and I thought this was already assumed by the "removal of pluggability 
contract" thread?) that these services are going to be integrated with the container, and not 
pluggable, then the container already knows how to name, inject and locate resources. That part
is well-defined. 

What is not well-defined is how to specify the service parameters for the services that this 
spec does define (scoping, binding, etc.) of an injected resource/component. So option 1 
would discuss how the scope, binding, etc could be overridden on the component when the ref 
is defined.

A couple of comments to the two options:

1. Refs in EE are currently scoped to the component, not the module, so the validation is
not nearly as bad as having to look at the entire module. This is a better option and makes 
the most sense for integration with the platform.

2. EE 6 is in fact defining the global naming rules for components via the mapped name,
so there could be a portable way of correlating the duplicate entries. (I still don't like
the duplication, though, and much prefer option 1.)

I would like to see all of the EE injection be in the same spec, meaning that existing 
EE resource injection would transition from its definition in the EE document to being in this
one (if injection is to be a primary service defined and offered by this spec). All injection
should be consistently defined, explained and implemented.

-Mike

> -----Original Message-----
> From: Gavin King [mailto:gavin at hibernate.org]
> Sent: Monday, January 05, 2009 9:11 PM
> To: Java Community Process JSR #299 Expert List; Michael Keith; Scott
> Ferguson; Matt Drees; WebBeans
> Subject: Java EE resource injection
> 
> 
> Folks, it's time to address the problem of generalized Java EE
> resource injection.
> 
> 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
> semantics.)
> 
> I see two possible paths we could go down here:
> 
> Option 1:
> =======
> 
> 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:
> 
> <ejb-ref>
>     <ejb-ref-name>foo</ejb-ref-name>
>     <remote>org.myapp.FooRemote</remote>
>     <binding>org.myapp.Bar</binding>
>     <scope>javax.webbeans.Conversation</scope>
> </ejb-ref>
> 
> <resource-ref>
>      <res-ref-name>jdbc/DefaultDS</res-ref-name>
>      <res-type>javax.sql.DataSource</res-type>
>      <res-auth>Container</res-auth>
>      <binding>org.myapp.Default</binding>
> </resource-ref>
> 
> <service-ref>
>     <service-ref-name>service/FooService</service-ref-name>
>     <service-interface>org.myapp.Foo</service-interface>
>     <wsdl-file>META-INF/wsdl/FooService.wsdl</wsdl-file>
>     
> <jaxrpc-mapping-file>META-INF/foo-mapping.xml</jaxrpc-mapping-file>
>     <binding>org.myapp.Bar</binding>
>     <scope>javax.webbeans.Request</scope>
> </service-ref>
> 
> 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.
> 
> Option 2:
> =======
> 
> The second option would be to require explicit declaration of the
> resource in web-beans.xml, thus making them an EAR-global declaration.
> 
> <ResourceRef jndiName=".....">
>     <myapp:Foo>
>         <myapp:Bar/>
>     </myapp:Foo>
>     <ResquestScoped/>
> </ResourceRef>
> 
> 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.
> 
> WDYT?
> 
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>




More information about the weld-dev mailing list