I propose that the Java EE platform should require the container to create a default connection factory which provides access to the platform default JMS provider and bind this to a well-known place in the application server's JNDI store. Applications would access this connection factory just like any other connection factory (e.g. using @resource annotations).

This would remove the need for the deployer to create this connection factory in a large proportion of cases. It would also provide frameworks (including CDI producer methods) to obtain a connection factory without the need for a JNDI name to be specified by the application.

This requirement would only apply to Java EE profiles which require a JMS provider to be provided by the application server (such as the full profile).

This proposal is supported by the JSR 343 (JMS 2.0) expert group, and is issue JMS_SPEC-63

EE.8.5.2 Deploying a Java EE Application:
d. For all files in the application package with a filename extension of .jar, but not contained in the lib directory, do the following: (0)
...
iii. All other JAR files are ignored unless referenced by a JAR file discovered above using one of the JAR file reference mechanisms such as the Class-Path header in a manifest file. (1)

According to EE.7.2.4 Data Formats
JAR files—JAR (Java Archive) files are the standard packaging format for Java technology-based application components, including the ejb-jar specialized format, the Web application archive (WAR) format, the Resource Adapt-er archive (RAR), and the Java EE enterprise application archive (EAR) format
a possible meaning of (1) can be that .jar files mentioned in (0) are NOT ignored if they are referenced by some JAR file (this includes also .war files) discovered according to subparagraph a., b. or c.
Another possible interpretation is that JAR file discovered above from (1) refers only to subparagraphs d.i. and d.ii.

This ambiguity led to the following situation: GlassFish ignores .jar files referenced from .war files, while WildFly does not ignore them.
(Not ignoring them in the before-mentioned case makes much more sense to me.)

The original intention of subparagraph d.iii. should be clarified so it is not ambiguous anymore.

Datasources defined via @DataSourceDefinition allow @resource injection of DataSource objects into application code. However, these data-sources are not integrated with the persistence.xml JPA configuration file. And attempted use of the custom defined DataSource in persistence.xml will result in deployment failure. The EE spec allow for interop between these features:

For a datasource definition:

@DataSourceDefinition(
         url = "jdbc:h2:mem:",
         className = "org.h2.jdbcx.JdbcDataSource",
         name = "java:global/jdbc/h2db",
         user = "sa",
         password = "")

The following persistence.xml should be valid:

<persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd"> 
   <persistence-unit name="default" transaction-type="JTA">
      <jta-data-source>java:global/jdbc/h2db</jta-data-source>
      <exclude-unlisted-classes>false</exclude-unlisted-classes>
   </persistence-unit>

</persistence>

Environment

EE 6/7+

Standardizing the EJB Lite Embedded Container in Java EE 6 was a very important first step in improving testability. As the various currently server-specific Java EE embedded containers and projects like Arquillian demonstrate, there is a lot of scope for further standardization in this space to improve testability. I suggest the following in roughly priority order:

1. Standardize a required embedded container for both the full and web profiles.
2. In addition to the current EJB Lite container, also standardize an embedded container for the full EJB container.
3. Standardize an embedded container for CDI (I am aware that this is already in the works).
4. Standardize a container that includes everything but the web/presentation/interface tier APIs (Servlet, JSF, WebSocket, JAX-RS, etc). This is very important in having a container that is capable of integration testing the application services layer, business/domain layer and persistence/DAO layer but is much lighter weight than a full container.

Both GlassFish and Jetty (acknowledging that Jetty is not a compatible container) Embedded are good examples of embedded container APIs. I suggest the following as embedded container features, in roughly priority order.

1. Managing the container life-cycle.
2. The ability to deploy and undeploy applications.
3. Deploy from the class-path, file systems (deflated/scattered or one deployable artifact) or programmatically (Shrinkwrap is worth looking at as an example of programmatically defining deployment artifacts).
4. The ability to configure the container (e.g. port settings).

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.

Currently there is no standard way how to enforce the ordering of the XAResource commits for the transaction. There are workarounds such as http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Transactions_Development_Guide/chap-Transactions_JTA_Programmers_Guide-Test.html#form-Transactions_JTA_Programmers_Guide-The_XAResource_Interface-Extended_XAResource_control for example, but I think that a properly specified standard API would be much better.

Environment

JTA

Although CORBA support in EJB was important once, CORBA usage has dropped precipitously in the past years in favor of REST and SOAP. Current CORBA use is so small that it makes the most sense to prune CORBA support going forward and significantly simplify EJB remoting.

Dear EG,
after reading this and trying to create services and expose them through JNDI, I have come up with an idea to simplify and standardize the way currently we can bind/unbind services on a JNDI. The Wildfly team has this reference material that the implement on top of the standard of JavaEE spec
https://docs.jboss.org/author/display/WFLY8/JNDI+Reference.
My ideas came from the fact that I want to have some services exposed but I don't want them to be either EJB's, I don't need all the EJB world since I don't have transactions etc and on top of that I want them to be remote accessible. Currently this can be achieved by some vendor specific configuration or configuration on the web.xml of your webapp. But why not enable an annotation something like @jndi or portable CDI things where you can define lightweight JNDI look able services. I firmly believe that this will help improving the adoption of Java EE since the accusation for heavy weight components will no longer stands true from any point of view.

if you look at http://java.sun.com/xml/ns/javaee/javaee_web_services_1_3.xsd it includes <xsd:include schemaLocation="javaee_6.xsd"/>

Suppose JAX-WS / WS_Metadata are not updated. What happens with this XSD ? Is it at least updated to include javaee7.xsd or does it stay with javaee6.xsd ?

This issue was unavailable for migration from original issue tracker.

In Java EE security there are various levels of roles that come into play, but the terminology for those roles is not centrally defined and the terms that are used are not always entirely clear.

Currently there are 3 levels of roles used:

| Term | Meaning |
| Group | Organization wide role |
| Role | Application wide role |
| Role ref | Component wide role |

The term group specifically is a source of confusion. People too often dream up all kinds of meanings for it, EXCEPT the meaning "organization wide role".

group is also not entirely consistently defined. JASPIC recognizes the term and uses it in its API/SPI but JACC does not. Further more the term group comes up in the concept "group to role mapping", but this is a concept that's mostly outside the current spec and there are very few to no references to this in Java EE specs.

Role ref is a problematic term too, but in practice not a big issue since it defaults to Role anyway and in practice might not be used a lot.

I propose to first investigate whether clearer names are possible, but independent of that at least clearly specify the different types of roles that are currently in use.

A possible way to clarify the role hierarchy is to take inspiration from the EJB JNDI name spaces and use the terms "global", "application" and "module" as follows:

| Term | Meaning |
| Global role | Organization wide role |
| Application Role | Application wide role |
| Component Role | Component wide role |

This issue was unavailable for migration from original issue tracker.

This issue was unavailable for migration from original issue tracker.

Section EE.5.16.2 of the Java EE platform specification contains the following obsolete paragraph:

For the benefit of implementors, we note that the Bean Validation API
includes a ValidatorFactoryBuilder interface that can be used to create a
ValidatorFactory configured according to the contents of a validation
deployment descriptor in the form of a java.io.InputStream.

While an interface ValidatorFactoryBuilder was discussed in early drafts of the Bean Validation 1.0 specification, there isn't such an interface in the final BV 1.0 spec. The mentioned paragraph should thus be removed.

Reference on BV mailing list: http://lists.jboss.org/pipermail/beanvalidation-dev/2012-August/000499.html

In section EE.5.18.4 and EE.5.18.5 of the Java EE7 spec, the examples for the JMS definitions (in the deployment descriptor and using the annotations) are incorrect.

Both jms-connection-factory and jms-destination require to define a element while the examples use incorrectly the to define the JMS interface.

Same error applies to the annotations' examples.

Correct examples would be:

<jms-connection-factory>
   ...
   <name>java:app/MyJMSCF</name>
   <interface-name>javax.jms.QueueConnectionFactory</interface-name>
   ...
</jms-connection-factory>

@JMSConnectionFactoryDefinition(
      name="java:app/MyJMSCF",
      interfaceName="javax.jms.QueueConnectionFactory",
      resourceAdapter="myJMSRA"
)

<jms-destination>
   ...
   <name>java:app/MyJMSDestination</name>
   <interface-name>javax.jms.Queue</interface-name>
   ...
</jms-destination>

@JMSDestinationDefinition(
      name="java:app/MyJMSQueue",
      interfaceName="javax.jms.Queue",
      destinationName="myQueue1"
)

My proposal is to specify in EE 7 that MBeanServer injection should be able in a container environment.

The reason for this proposal is, that some AS provide it's own platform specific MBeanServer, so that ManagementFactory.getPlatformMBeanServer() will not provide the correct MBeanServer.

To build platform independent components, the container should provide the correct MBeanServer via @resource or @Inject.

With this, one for example can implement an interceptor with @AroundConstruct to do the registration of a MXBean in a container environment.

This would pass the rule of separating concerns and will get a clear EJB Pojo as well.

Example:

@Inherited
@InterceptorBinding
@Target({TYPE}) @Retention(RUNTIME) public @interface MBean {
    @NotBinding String value() default "";
}

@Interceptor @MBean
public class MBeanInterceptor {

    @Resource
    MBeanServer server;

    @PostConstruct
    public void registerBean(InvocationContext ctx) {
        ctx.proceed();
        ObjectName on = ... // get objectname from annotation value
        server.register(on, ctx.getTarget());
        // or do the neccessary DynamicMBean work here...
    }

    @PreDestroy
    public void unregister(InvocationContext ctx) {
        ObjectName on = ... // get objectname from annotation
        server.unregister(on);
        ctx.proceed();
    }
}

@Singleton @Startup @MBean("com.example:type=MyMXBean")
public class MyMXBean {
// ... }

So with @resource injection, this will work even on appservers with its own MBeanServer, not only with JVM PlatformServer, but the developer do not care about this.

Next, @resource injection could be used also in a normal EJB to do some client work (observe notifications, get attributes aso.) with a registered mbean without the need to distinguish about the right MBeanServer to be used.

The Common Annotations spec sections on PostConstruct/PreDestroy should be updated to reflect current Interceptors spec.

More specifically, need to replace:
"The method MUST NOT have any parameters except in the case of EJB interceptors in which case it takes an InvocationContext object as defined by the EJB specification."
with:
"The method MUST NOT have any parameters except in the case of interceptors in which case it takes an InvocationContext object as defined by the Interceptors specification."

We're creating javaee7 sample to show JMS XA and non-XA connection factory implications (javaee-samples/javaee7-samples#139, javaee-samples/javaee7-samples#158 (comment))
It works great on wildfly as it exposes both XAConnectionFactory (java:/JmsXA) and non-XA ConnectionFactory (java:/ConnectionFactory).

We would need servers to expose both factories.

Following the thread http://java.net/projects/javaee-spec/lists/users/archive/2012-12/message/17

@priority is used to priorityze interceptors in Java EE 7. It would be interesting to spread this feature to other components in Java EE 8, for example @singleton & @WebServlet.

@Singleton
@Startup
@Priority(100)
public class MyVeryFirstSingleton {}

@Singleton
@Startup
@Priority(4500)
public class MyVeryLastSingleton {}

The EE6 specification, EE.8.5.2 paragraph 1, d.ii reads

"If the JAR file contains a META-INF/ejb-jar.xml file, or contains any class with an EJB component annotation (Stateless, etc.), consider the JAR file to be an EJB module."

To be consistent with the EJB specification, (and to prevent from falsely detecting a jar as EJB module without any EJBs because it contains other, possibly "leftover" EJB annotations) shouldn't the requirement be more specifically for an "EJB component-defining" annotation? I could be wrong, but I'm guessing that was the intent.

JIRA http://java.net/jira/browse/EJB_SPEC-59 was opened provide some consistency and completeness in the EJB 3.2 specification around component-defining annotations.

Java EE should add the ability to specify per-application logging configurations.

Currently, if you look across the various specs, there's lots of ways to get object references. As far as I've seen, JAX-RS does it the best (definition wise) by specifying that classes annotated will be properly looked up via CDI. JSF has similarly followed suit and aligned their instance creation to CDI when within a bean archive. JMS has done an excellent job as well, with managing scopes of its managed objects.

However, we have specs like Servlet and WebSockets that don't define this behaviour. For instance, a SerlvetFilter should be a managed CDI object with an appropriate scope, and allow for proper injection, assuming it has an adequate scope and is found within a bean archive.

This type of requirement needs to come from the entire platform overall, in order to give developers a consistent programming model.

All "default" resources (like UserTransaction, SessionContext), injectable with @resource in Java EE 6 should be also injectable with @Inject as well.

This issue was unavailable for migration from original issue tracker.

This issue was unavailable for migration from original issue tracker.

This issue was unavailable for migration from original issue tracker.

Currently, various specs define ways to convert objects from one to another (string, streams, etc). This should be consolidated to avoid duplication, e.g. if I want to convert for both JAX-RS and WebSocket support, I should be able to define one class to do it all for me.

See this mail for full details and conversation follow up: https://java.net/projects/javaee-spec/lists/users/archive/2014-08/message/0

Many Java EE implementations offer support for clustering, but clustering behavior and configuration isn't specified by the Java EE platform. The behavior when clustering is used should be more fully specified in a future release.

From Java EE 6 on the JASPIC SPI describes how to integrate portable authentication modules into a Java EE server. Unfortunately JASPIC is not a part of the increasingly popular Java EE Web Profile, which greatly limits the true portability of those authentication modules.

Adding the Servlet Container Profile of JASPIC will not add any real new functionality to the Web Profile; Web Profile implementations are already mandated to implement authentication in some way following the requirements of mainly the Servlet specification. Instead, JASPIC will mainly standardize the way in which Web Profile implementations perform authentication and will make sure server authentication modules (SAMs) can be shared between Full- and Web Profile Java EE servers.

In order to increase portability and have a more consistent security model for the Java EE platform, I'd like to propose that the Servlet Container Profile of JASPIC be added to the Java EE Web Profile.

Need to make sweep over spec to verify API version numbers for MRs.

Create Java EE 8 Schema Workarea

Copying issue GLASSFISH-15847.

This is filed here for tracking for future JSR-250 MR.
Original bug can be found at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6427252

(Note, the content at the above URL is no longer available).

Java SE 8 introduces the capability of repeating annotations: http://docs.oracle.com/javase/tutorial/java/annotations/repeating.html. There are a number of existing Java EE annotations that could adapt to the feature (fortunately in a fairly backwards compatible fashion - the Java SE feature was clearly designed with backwards compatibility in mind).

The following is a list of annotations that are fairly clear candidates, in roughly priority order (keep in mind, it is possible I missed something - hopefully spec leads will do a far better job at identifying required changes):

• EJB
  • javax.ejb.Schedule
• Java EE/Common Annotations
  • javax.annotation.sql.DataSourceDefinition
• JPA
  • javax.persistence.NamedQuery
  • javax.persistence.NamedNativeQuery
  • javax.persistence.SqlResultSetMapping
  • javax.persistence.NamedEntityGraph
  • javax.persistence.NamedStoredProcedureQuery
  • javax.persistence.SequenceGenerator
  • javax.persistence.TableGenerator
  • javax.persistence.PersistenceContext
  • javax.persistence.PersistenceUnit
  • (There may be others in JPA)
• JMS
  • javax.jms.JMSDestinationDefinition
  • javax.jms.JMSConnectionFactoryDefinition
• JavaMail
  • javax.mail.MailSessionDefinition
• JSF
  • javax.faces.application.ResourceDependency
  • javax.faces.event.ListenerFor
• JCA
  • javax.resource.AdministeredObjectDefinition
  • javax.resource.ConnectionFactoryDefinition
  • javax.resource.spi.ConnectionDefinition
  • (There may be others in JCA)
• JAX-WS
  • javax.xml.ws.WebServiceRef
  • (There may be others in JAX-WS)

Other than the above, there are other annotations where the value proposition of the repeatable annotation semantics is less clear. It is highly subjective, but in these cases having an explicit containing annotation may add clarity since the repeating annotations are more logically grouped. On the other hand, it may be simpler for developers if repeating annotations are used consistently across the platform.

The following is a list, in roughly priority order (keep in mind, it is possible I missed something - hopefully spec leads will do a far better job at identifying required changes):

• JPA
  • javax.persistence.SecondaryTable
  • javax.persistence.JoinColumn
  • javax.persistence.AttributeOverride
  • javax.persistence.AssociationOverride
  • javax.persistence.PrimaryKeyJoinColumn
  • javax.persistence.MapKeyJoinColumn
  • (There may be others in JPA)
• Bean Validation
  • javax.validation.constraints.NotNull
  • javax.validation.constraints.Size
  • javax.validation.constraints.Min
  • javax.validation.constraints.Max
  • javax.validation.constraints.DecimalMin
  • javax.validation.constraints.DecimalMax
  • javax.validation.constraints.Pattern
  • javax.validation.constraints.Digits
  • javax.validation.constraints.Past
  • javax.validation.constraints.Future
  • javax.validation.constraints.AssertTrue
  • javax.validation.constraints.AssertFalse
  • javax.validation.constraints.Null
  • javax.validation.groups.ConvertGroup
  • javax.validation.OverridesAttribute
• JAXB
  • javax.xml.bind.annotation.XmlElement
  • javax.xml.bind.annotation.XmlSchemaType
  • (there may be others in JAXB)

The repeating annotations feature also opens up some interesting possibilities such as overlapping @path annotations (effectively aliases), various @QueryParam, etc annotations mapping to the same Java method parameter and the like. The value in keeping things simple may override any compelling semantic benefit to be gained in such cases...

Do let me know if anything needs to be explained further - I am happy to help. I am also happy to disperse these JIRA issues across various projects if needed. Doing one JIRA for the platform was easier especially since this involves some older Java EE specifications.

Please note that these are purely my personal views and certainly not of Oracle's as a company.

In Java EE 7 the concept of a default data source was added to the platform. See #4

One specific request in that JIRA was to make sure the database backing this data source is actually available, without the user having to manually start a database that happens to be bundled with the application server:

From #4:

To make use of this platform default data source, the user should not have to configure anything and should not have to manually start the embedded database separately from starting the application server.

For a next revision of Java EE I would like to ask to take this original request into consideration again. The intend is that just like other platform services like e.g. JNDI, JMS etc the default data source should "simply be there" (as an implementation detail actually starting the backing DB can of course be delayed to the moment of first usage or when the deployment process detects an application is actually using the default data source).

See also GLASSFISH-20666

Currently several Java EE implementations ship with an embedded database that is often also made available to user code via a pre-defined data source.

The JNDI name under which this data source is made available differs per product. For instance GlassFish V3 uses jdbc/_default, JBoss AS 5 and 6 use java:/DefaultDS and JBoss AS 7 uses java:jboss/datasources/ExampleDS. WebLogic and WebSphere ship with embedded databases, but don't seem to have a pre-defined data source.

I would like to propose the introduction of a platform default data source and bind this to a well-known place in the application server's JNDI tree. This data source does not have to be required to be suitable for heavy production use. Instead it should be primarily intended for testing and development purposes, as well as for applications having very moderate persistence requirements (like an admin console that needs to store a few values).

To make use of this platform default data source, the user should not have to configure anything and should not have to manually start the embedded database separately from starting the application server.

A diverse range of services in the Java EE platform that now do persistence in some opaque vendor specific way (like EJB timer persistence or HTTP session persistence) could possibly be mandated to make use of this default data source.

Optionally it might be worth it to specify a portable way to let this default data source point to an external user specified database. In that way, applications and services that are written to work against the default data source can transparently and portably make use of a central database instead of the embedded one. This could also be useful for issues like EJB_SPEC-45, EJB_SPEC-47 and possibly EJB_SPEC-10.

This issue was unavailable for migration from original issue tracker.

This issue was unavailable for migration from original issue tracker.

Java EE 6 introduced the @DataSourceDefinition and corresponding data-source deployment descriptor element to allow an application to define a DataSource. (see JSR 316 EE.5.17 and JSR 250 2.13)

This opens the door for creating both self-contained applications (i.e. for which an administrator does not need to setup anything before the application can be deployed and started) and applications that have a portable DataSource definition.

However, in practice it's still not entirely possible to fully use this and use this portably due to a few omissions in the spec.

One problem is that the spec does not say anything about the location of the required JDBC driver. JSR 250 does say in section 2.13:

The driver class is not required to be available at deployment but must be available at runtime prior to any attempt to access the DataSource.

In order to create a self-contained application that defines a DataSource in the java:comp, java:module or java:app JNDI namespaces, the user should be able to place the driver on the classpath corresponding to the components which can access those namespaces. E.g. WEB-INF/lib for the web module. Currently this is possible with e.g. JBoss AS 7.1, but not with GlassFish 3.1.

Another problem is that the spec is not really clear about the transactional behavior. An example from which behavior can be deduced is given in JSR 250 section 2.13:

Vendors are not required to support properties that do not normally apply to a specific data source type. For example, specifying the transactional property to be true but supplying a value for className that implements a data source class other than XADataSource may not be supported.

Since this is non-trivial functionality, a somewhat more in depth specification of the desired behavior might not be out of place.

The annotation and xml variant define attributes for pooling, but pooling is seemingly not mandated. JSR 250 calls those attributes "vendor specific". As a result, at least one vendor (JBoss) treats the annotation as a facility for testing and development only in its certified product:

Since Java EE6, the new annotation "@DataSourceDefinition" has existed to allow users to configure a data source directly from within their application. (Note that this annotation bypasses the management layer and as such it is recommended only for development and testing purposes.)

(source: https://community.jboss.org/wiki/DataSourceConfigurationInAS7)

To sum up, I would like to request the following improvements:

• Specify all valid locations of the JDBC driver
• Mandate possibility to use application embedded JDBC driver for application scoped datasources
• Clarify transactional behavior
• Mandate connection pooling

I hope that with these improvements @DataSourceDefinition/data-source can become a facility that is more likely to be used for actual production work.

It would be quite easy to test JEE Applications using a CDI container that runs outside the Application Server. Weld already provides a CDI Container for Java SE (Weld-SE). I have been using this approach to test JEE Applications in several customer projects and the feedback has been good.

Please see this post for detailed information about this approach:
http://blog.novatec-gmbh.de/unit-testing-jee-applications-cdi/

The source code can be found on:
https://github.com/NovaTecConsulting/BeanTest

The example described in the post uses standard CDI features to make it possible to test JEE applications with (almost) all its dependencies resolved by the CDI Container. It runs like a normal Unit test, which means that the tests need milliseconds to run. It uses local transactions which it is ok for testing purposes. It also uses CDI extensions to "convert" EJBs into normal CDI Beans, so it aligns very well in the direction where JEE8 is going, namely, CDI instead of EJBs.

I think this feature will help a lot with testing. Besides, the approach uses other well established specs like JPA. I think that the technical aspects for this feature are already solved. The specs and infrastructure needed are already out there.

I know there is an Embedded Container already but it is very hard (almost impossible) to properly configure it in large projects.

Arquillian is a very good framework but I think it is used more for integration tests (deployment is still required in most cases).

@startup is currently allowed only on EJB and should be allowed on any Java EE component.

In a Java EE application deployment descriptors are used to configure and setup the application. One major issue is that these deployment descriptors are mostly static. In practice, there's often a need to have a different set of configuration files for different situations.

For instance, for a development environment I might want a link configured by a context-param in web.xml to point to 'localhost:8080/someapp/myresource', while in a QA environment I want it to point to 'qa.mycompany.com/myresource' etc.

As another example, since Java EE 6 a data source can be configured in among others web.xml using the data-source element. Especially in this case there is a pressing need to have different data sources pointing to different databases depending on the context.

Yet another example is a Servlet Filter that provides some development utilities, which should definitely not be activated in a production environment.

A possible solution for this could be the introduction of descriptor fragments that are included from the main descriptor based on a placeholder. E.g. in web.xml:

<web-app> 
    ... 
    <fragment>WEB-INF/conf/${mycompany.staging}/web-fragment.xml</fragment>
</web-app>

Inside the WEB-INF/conf directory, multiple folders could be created, each corresponding to a stage, e.g.

WEB-INF
    conf
        dev
            web-fragment.xml
        qa
            web-fragment.xml
        live
            web-fragment.xml

Starting up the application with -Dmycompany.staging=dev would then cause WEB-INF/conf/dev/web-fragment.xml to be processed.

Besides being useful for directing different fragment descriptors to be processed, placeholders can also be used to externalize some values completely. E.g. the password in a production datasource:

<data-source>
    <name>java:app/someDS</name>
    <class-name>org.example.Something</class-name>
    <url>jdbc:someDB</url>
    <user>${mycompany.someDS.user}</user>
    <password>${mycompany.someDS.password}</password>
</data-source>

For the above to be really useful, another concept should be introduced: the ability to load system properties from an external properties file. Specifying the above password via a -D command line option is of course not secure, since it can be seen in the running processes (e.g. using the ps command). Something like the following would be more suitable:

-Djavax.config.properties=/somepath/config.properties.

In CDI 2.0 EDR1 we added event observer ordering.
The proposed feature is based on @priority annotation from commons annotation.

We propose to use besides the @observes annotation, at parameter level.

Like this:

void afterLogin(@Observes @Priority(APPLICATION) LoggedInEvent event) { ... }

Right now @priority targets only types. We need it to be enhance to also support parameters as target.

This issue was unavailable for migration from original issue tracker.

It is currently not possible to define JavaMail Sessions via standard annotations or XML. This is a potential usability issue, especially in cloud environments.

It may be very helpful to have portable annotations or XML for this, just like we now have for data sources and JMS resources.

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.

currently the @stateless, @stateful annotations look like:

@target(value =

{ElementType.TYPE}

)
@retention(value = RetentionPolicy.RUNTIME)
public @interface Stateless {}

I would like to extend the @target of all @stateless, @stateful, @singleton beans to:

@target(value =

{ElementType.TYPE,ElementType.ANNOTATION_TYPE}

)

(add ElementType.ANNOTATION_TYPE)

This would allow to use EJB meta-annotations in CDI @stereotype definition

The spec currently requires the ability to provide an alternative deployment descriptor
for an ear file when deploying the ear file. The alternative deployment descriptor will
NOT be packaged in the ear file, to allow overriding the application's deployment descriptor
without modifying the application package.

However, the spec does not describe a way for that ear-level alternative deployment descriptor
to reference module-level alternative deployment descriptors that are NOT packaged in the ear
file. There should be a way to do this.

One approach would be to specify the alternative deployment descriptor as a jar file that
could contain both an application.xml deployment descriptor as well as module deployment
descriptors referenced by alt-dd elements in that application.xml deployment descriptor.

We should specify what the valid characters are in JNDI names.
Is it ASCII? Full Unicode? Are certain characters like NUL and backslash illegal?
We ought to at least set a lower bound that all products have to support.

Java EE mandates a (JTA) transaction manager to be present. There is however no standardized portable JNDI defined for this. Currently a variety of Java EE AS implementations use different names, e.g.:

| JNDI name | AS |
| java:jboss/TransactionManager | JBoss AS 7 |
| java:/TransactionManager | JBoss AS 4 ~ 6, JRun4 |
| java:comp/TransactionManager | Resin 3.x |
| java:appserver/TransactionManager | Sun Glassfish |
| java:pm/TransactionManager | Borland, Sun |
| javax.transaction.TransactionManager | BEA WebLogic |
| java:comp/UserTransaction | Resin, Orion, JOnAS (JOTM) |

(list taken from Infinispan's GenericTransactionManagerLookup)

Some implementations (e.g. WebSphere), don't seem to register a transaction manager in JNDI at all.

For an end user this is troublesome, since various transactional products (ORMs, Caching solutions) now need to bother the user with finding this information for the particular AS the user is deploying that product on. Generic solutions that scan well known locations may fail when the user upgrades the AS or moves to another AS.

To increase portability, I would like to request to introduce a portable name for the platform transaction manager and mandate that this will be available in all conforming implementations. E.g. java:/TransactionManager.

With platforms like Ruby and Play! the underlying persistence engine is often automatically enabled when a data source is defined for the application (in fact these platforms often assume only one data source per application). More recently Spring Boot appears to have understandably adopted this convention as well, ironically utilizing the JPA bootstrap API. We should explore if this is the correct default convention for Java EE.

Specifically this would mean detecting an application defined data source (e.g. via @DataSourceDefinition), detecting JPA usage in the application (e.g. via entity manager injection) and auto-wiring/enabling a sensible persistence unit that the application can use as opposed to having an explicit persistence.xml for the "default case".

This particular convention can be potentially incorrect so we should weigh it carefully with community and expert group input. The problem is that as far as I have seen personally, developers often need to put in persistence.xml settings/properties for very common cases such as logging, debugging, caching and schema generation. This is particularly true during development and testing. This may mean that this particular convention may be a potential source of confusion instead of being helpful. Nonetheless, it is at least worth considering carefully and gathering feedback.

Please note that these are purely my personal views that may or may not reflect consensus at Oracle as a company.

This issue was unavailable for migration from original issue tracker.

This issue was unavailable for migration from original issue tracker.