I'm disappointed that so few of you have an opinion on this, but maybe
I should be pleased that so many of you trust Oracle!
The few responses we got were split between B and D:
B. Any class that also supports injection (table EE-5.1).
D. Any class in the application package or referenced as an
external library.
In fact, our interpretation of the Java EE 7 spec is that C is required:
C. Any class in the application package (ear/war/jar file).
In our upcoming Java EE 7 errata, we'll be making it clearer that C
is the requirement. Currently, the spec is not as clear as we would
like as to whether B or C is the requirement.
I understand the attraction of D, but when we first introduced annotations
there was a concern about the cost of scanning for annotations. A compromise
we made is that only code in the application package needed to be scanned;
code in external libraries did not need to be scanned.
If we now believe that the cost of scanning for annotations is not an issue,
and that D is a better answer for developers, we can consider that as a new
requirement for Java EE 8, although we would also have to consider the
compatibility impact of that change.
Thanks for your feedback. We'll be sending out the draft Java EE 7 errata
shortly.
Bill Shannon wrote on 01/23/2015 11:51 AM:
> We only got one response to this message. Many of you probably never got
> back to this after the holidays, but now's the time. If we don't hear from
> you we'll assume your position is "we trust you, Oracle, to do what's best".
>
> But really, we'd rather hear from you directly.
>
> Thanks.
>
> Bill Shannon wrote on 12/08/14 15:25:
>> I'd like to clarify some of the requirements around resource annotations.
>>
>> There's two kinds of resource annotations that can be applied to a class:
>>
>> 1. Resource reference annotations such as @Resource. This is probably
>> rarely used (as opposed to injection), but can be useful in cases where
>> dynamic lookup of the resource is required.
>>
>> @Resource(name = "myDS", lookup = "java:app/application-database")
>> public class Something {
>> public void someMethod() {
>> ...
>> InitialContext ic = new InitialContext();
>> DataSource ds = (DataSource)ic.lookup("myDS");
>> }
>> }
>>
>> 2. Resource definition annotations such as @DataSourceDefinition.
>>
>> @DataSourceDefinition(
>> name = "java:app/applicaiton-database",
>> className="org.apache.derby.jdbc.ClientDataSource",
>> url="jdbc:derby://localhost:1527/myDB;user=bill",
>> databaseName="testDB",
>> serverName="luckydog"
>> )
>> public class SomeOtherClass {
>> ...
>> }
>>
>> I have some questions that I'd like each of you to answer:
>>
>> For Java EE implementors:
>>
>> In your implementation, what classes may contain each of these
>> types of annotations?
>>
>> A. A limited set of container-managed classes.
>> B. Any class that also supports injection (table EE-5.1).
>> C. Any class in the application package (ear/war/jar file).
>> D. Any class in the application package or referenced as an
>> external library.
>> E. Other. (Explain)
>>
>>
>> For Java EE developers:
>>
>> What classes do you expect may contain each of these types of annotations?
>>
>> A. A limited set of container-managed classes.
>> B. Any class that also supports injection (table EE-5.1).
>> C. Any class in the application package (ear/war/jar file).
>> D. Any class in the application package or referenced as an
>> external library.
>> E. Other. (Explain)
>>
>>
>>
>> For everyone:
>>
>> What classes do you think the Java EE 7 spec requires must be able
>> to contain each of these types of annotations?
>>
>> A. A limited set of container-managed classes.
>> B. Any class that also supports injection (table EE-5.1).
>> C. Any class in the application package (ear/war/jar file).
>> D. Any class in the application package or referenced as an
>> external library.
>> E. Other. (Explain)
>> F. I don't know.
>>
>>
>> Thanks.
>