Search |
||
Java EE 6: module and application scopes of java:comp/env?Posted by guruwons on June 5, 2008 at 8:47 PM PDT
I would like to get feedbacks about
application-scoped and module-scoped resource/EJB references (in
As you know, when we define simple
environment entries or refer to data sources or EJBs we need to
specify
<env-entry>
<env-entry-name>foo/maximum</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>10</env-entry-value>
</env-entry>
<resource-ref>
<res-ref-name>myDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
</resource-ref>
<ejb-ref>
<ejb-ref-name>ejb/myBean</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<remote>some.package.MyBeanInterface</remote>
</ejb-ref>
or via annotations on the component class
Then we use these Current limitation is that EJB module can only have component-scoped(per-bean) namespace so that you need to define the same references and mappings again and again for each EJB. This is different from web module which has only module scope. Therefore it's hard to define shared configuration/references at module level and it's especially inconvenient for module default interceptors. Also there is no notion of application scope for sharing between modules inside one application. So it's difficult to share those between modules. As we try to enable packaging EJBs in web module, it's also an option to add component scope to web module so each EJB has its own scope. I'm not sure that we need to add this for servlet components either. Even though there are multiple scopes,
you don't need to find out exactly where the entries are defined.
General scope rule will be applied here. When you looking up with
I would like to hear from you about this.
Please give us any use cases or reasons if you have. Your feedbacks are important to add these extensions to Java EE 6. »
Related Topics >>
J2EE Comments
Comments are listed in date ascending order (oldest first)
Submitted by jwenting on Fri, 2008-06-06 00:00.
JNDI addresses should never be relative to where you call them from, else all hell may break loose. There are enough problems with figuring out what root to use to call something without that root being dependent on where you make the call in your code.
Submitted by jhook on Fri, 2008-06-06 00:07.
please don't duplicate functionality/solutions coming out of JSR 299 :-)
Submitted by guruwons on Sun, 2008-06-08 23:15.
[Answers]
1. On the contrary, application and module scopes makes it easy to share common entries/references regardless of where the code is being called. Current EJB component scope has this problem - if an interceptor is attached to EJBs the interceptor need to know which component is being called, or people should fill those references in all EJBs.
2. This is different from JSR 299. Web Beans defines the scope of component instance, but this defines simple type entries, resource references, EJB references in the JNDI tree. This releases the need to duplicate such entries in each EJB or each module.
|
||
|