[javaee-spec users] [jsr366-experts] Compatibility Problems with MR Resource Annotation Widening

From: Jason Greene <>
Date: Thu, 19 Feb 2015 14:36:37 -0600

One thing that came up internally is that the language of this MR will break compatibility with existing applications:

Section EE.5.2.2

 An environment entry declared in the application.xml descriptor or
 by an annotation on a class in the application package other than
 within a web module or EJB module must specify a JNDI name in the
 java:app or java:global namespace, for example:
 java:app/env/myString or java:global/someValue.

Section EE.5.2.5
Change the text starting on line 3 on page 74 from:
  Resource annotations may appear on any of the classes listed above,
  or on any superclass of any class listed above.
  Resource annotations may appear on any class in the application package.

One common pattern that we have seen in applications, is that they contain annotated classes in ear/lib (interceptors, common base classes etc), which are reused across multiple components. The annotations are brought into effect by extending the class, and at that point the namespace references are relative to the EE component, not to the base class. With these changes if @Resource on a class in ear/lib specifies an unqualified name, the default is comp, which doesn’t exist for ear/lib, leading to undefined results (probably a failure, but maybe an unintended, potentially conflicting, mapping to java:app). Likewise, if @Resource on a class in ear/lib uses java:module then we again end up with undefined results. If a user happened to have specified @Resource on java:global then things start to work out, unless of course sharable was false, in which case we end up with a duplicate conflicting binding and failure again.

Another problem is third party libraries which make use of common annotations using a different facility will suddenly be processed by EE containers and this also will likely lead to failure.

It makes sense for @DatasourceDefinition (and friends), but we should still clarify the namespace handling for classes which are not a component and/or do not have a module namespace.

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat