javaee / ejb-spec Goto Github PK

The @dependsOn annotation should be extended with an additional element Class[] beans

@target(value =

{ElementType.TYPE}

)
@retention(value = RetentionPolicy.RUNTIME)
public @interface DependsOn {
public Class[] beans(); //NEW
public String[] value();
}

Reason:

in EJB 3.1 only the name of the bean can be used, what can be easily misspelled. The syntactical correctness of the bean-class would be checked by the compiler.
Furthermore you will get auto-completion IDE-support as well.

Affected Versions

[3.2]

From Linda's request in Core book:

Section 11.7.1.3. This chapter isn't always clear about which deployment descriptor elements get mentioned and discussed. In particular, lookup-name and mapped-name coverage seems rather hit-or-miss. Need to revisit. Ditto section 11.8.1.3 for example.

Affected Versions

[3.2]

EJB 3.2 lite spec should support EJB Timer Service. Scheduling is common functionality (cache flushing, mail sending), and should be available in EJB 3.2 lite. At least transient timers should be supported.

It is not supported in EJB 3.1 lite. (see chapter 21.1, Table 27, EJB 3.1 spec)

Affected Versions

[3.2]

This is a request for the EJB 3.2 spec to add additional activation configuration properties clientId and subscriptionName for JMS message-driven beans as follows:

Section 5.4 of the EJB 3.1 spec currently defines the the following activation configuration properties for JMS message-driven beans:
acknowledgeMode (optional, default is AUTO_ACKNOWLEDGE)
messageSelector (default is an empty String)
destinationType (optional, no default)
subscriptionDurability (default is NonDurable)

This should be extended to define the following additional activation configuration properties:

clientId
subscriptionName

These property names match those recommended in JCA 1.6.

If set, clientId would be used to set clientId for the connection used by the MDB, and must be unique in accordance with JMS 1.1. There would be no default value. JMS 1.1 states that clientId must be set if a durable subscription is being used. However in JMS 2.0 JMS_SPEC-39 proposes that this requirement would be removed and clientId would always be optional.

If a durable subscription is being used, then JMS requires that subscriptionName be set. In the case of a MDB the subscriptionName is normally given a name unique to the MDB, to distinguish it from other MDBs and other applications subscribed to the same topic. It is therefore proposed that the EJB specification state that if the subscription is durable and subscriptionName is not set then the container will automatically set subscriptionName to the name of the MDB.

As with the existing activation configuration properties for JMS message-driven beans defined in the EJB specification, clientId and subscriptionName could be specified either using the MessageDriven annotation

@MessageDriven(activationConfig =  {
    @ActivationConfigProperty(propertyName = "subscriptionDurability.", propertyValue = "Durable"),
    @ActivationConfigProperty(propertyName = "clientId", propertyValue = "MyMDB"),
    @ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "MySub")
})

or in ejb-jar.xml:

<ejb-jar>
  <enterprise-beans>
    <message-driven>
      <ejb-name>test.MyMDB</ejb-name>
      <activation-config>
         <activation-config-property>
            <activation-config-property-name>subscriptionDurability</activation-config-property-name>
            <activation-config-property-value>Durable</activation-config-property-value>
         </activation-config-property>
         <activation-config-property>
            <activation-config-property-name>clientId</activation-config-property-name>
            <activation-config-property-value>MyMDB</activation-config-property-value>
         </activation-config-property>
         <activation-config-property>
            <activation-config-property-name>subscriptionName</activation-config-property-name>
            <activation-config-property-value>MySub</activation-config-property-value>
         </activation-config-property>  
      </activation-config>
    </message-driven>
  </enterprise-beans>
</ejb-jar>

Affected Versions

[3.2]

Currently the EJB TimerService interface can only be used with the EJB component model. With the introduction of managed beans and CDI, there are not many good technical reasons why the TimerService interface should not be used in managed beans as well. In fact, many developers that are wary of the EJB component model would opt to use this model instead. In addition, decoupling EJB services such as the TimerService interface from the component model moves towards removing one-off component models in Java EE in favor of unifying around managed beans/CDI.

We currently allow this capability in Resin. The code looks like this:

@ApplicationScoped
public class MyScheduledBean {
...
@Inject private TimerService timerService;
...
public void myScheduleCreator()

{ ... Timer timer = timerService.createTimer(...); ... }

...
@timeout
public void handleTimeout(Timer timer)

{ ... }

...
}

Affected Versions

[3.2]

There are two element definitions for ejb-relationship-role in the ejb-jar xsd instead of having one element with the correct occurrence counts.

Currently proprietary max-pool-size settings are used to control the max concurrency of an application and so to prevent overloading the application server.

We could abstract the intended behavior into an annotation:

@target(value =

{ElementType.METHOD, ElementType.TYPE})
@retention(value = RetentionPolicy.RUNTIME)
public @interface MaxConcurrency {
public int value() default 30;
}

We could provide more generic annotation like:

@target(value = {ElementType.METHOD, ElementType.TYPE}

)
@retention(value = RetentionPolicy.RUNTIME)
public @interface Concurrency {
public int max() default 30;
}

to support future extensions.

This functionality should be available for EJB 3.2 and CDI.

Affected Versions

[3.2]

EJB 3.2 draft 20110511

For programmatically created timers, the timeout callback method may be a method that is annotated
with the Timeout annotation or the bean may implement the javax.ejb.TimedObject interface.
The javax.ejb.TimedObject interface has a single method, the timer callback method
ejbTimeout.

Should become:

For programmatically created timers, the timeout callback method must either be a single method that
is annotated with the Timeout annotation or the bean must implement the javax.ejb.TimedObject interface.
The javax.ejb.TimedObject interface has a single method, the timer callback method
ejbTimeout.

See Section 13.2.4, last paragraph:

"The getTimers method returns all active timers associated with the bean. These include both the programmatically-created timers and the automatically-created timers"

Affected Versions

[3.2]

This is a request for the JMS and/or EJB specifications to improve the way in which specify how an application or deployer may specify the destination from which a JMS message-driven bean to receive messages. There are several significant omissions from the specification which need to be rectified.

Although MDBs are specified in the EJB specification, this request should be considered first by the JMS 2.0 expert group who may then want to raise it with the EJB 3.2 expert group.

Review of existing specification (EJB 3.1)

In the EJB 3.1 specification, Section 16.9 "Message Destination References" states that the destination used by a JMS message-driven bean can be specified using the element of the element in ejb-jar.xml:

<message-driven>
   <ejb-name>ExpenseProcessing</ejb-name>
   <ejb-class>com.wombat.empl.ExpenseProcessingBean</ejb-class>
   <messaging-type>javax.jms.MessageListener</messaging-type>
   ...
   <message-destination-type>javax.jms.Queue</message-destination-type>
   <message-destination-link>ExpenseProcessingQueue</message-destination-link>
   ...
</message-driven>

Issues with the existing specification

This raises the following questions:

1. What is ?

The element defines the destination from which the MDB consumes messages in terms of a "message destination reference".

The purpose of "message destination references" is to allow an application which sends messages to a particular destination and also consumes from the same destination to inform the deployer of this fact without having to actually specify the name (or JNDI name) of the destination.

As stated above, a MDB can specify the "message destination reference" of the destination from which it consumes messages using a element under the element. Another component (e.g. a session bean or another MDB) can specify the destination to which it sends messages using a element under a element. If these two elements contain the same string then the deployer knows they refer to the same queue or topic.

A message destination reference is not the JNDI name of the queue or topic. It is just a logical name. It can be mapped to an actual JNDI name using the element in ejb-jar.xml as follows:

Here's how ejb-jar.xml could be used to define a MDB as consuming messages from a "message destination reference" called MsgBeanInQueue which was mapped to a JNDI name jms/inboundQueue:

<ejb-jar>
  <enterprise-beans>
    <message-driven>
      <display-name>MDB1</display-name>
      <ejb-name>MessageBean</ejb-name>
      <messaging-type>javax.jms.MessageListener</messaging-type>
      <transaction-type>Container</transaction-type>
      <message-destination-type>javax.jms.Queue</message-destination-type>
      <message-destination-link>MsgBeanInQueue</message-destination-link>
    </message-driven>
  </enterprise-beans>
  <assembly-descriptor>
    <message-destination>
      <lookup-name>jms/inboundQueue</lookup-name>   <!---
      <message-destination-name>MsgBeanInQueue</message-destination-name>
    </message-destination>
  </assembly-descriptor>
</ejb-jar>

A message destination reference can typically also be mapped to an actual JNDI name using the application-server-specific deployment descriptor, though by definition this is beyond the scope of the EJB specification.

2. Is that the only way you can define the destination on which a MDB consumes messages in ejb-jar.xml? Can you define its JNDI name directly without bothering with references?

No, the EJB specification doesn't mention any way to define the destination in ejb-jar.xml apart from using the element of ejb-jar.xml. In particular it doesn't define any way to define its JNDI name directly, analogous to using either the JNDI API or a @resource(lookup="jms/foo") declaration for managed connections.

(The EJB specification does define a element in ejb-jar.xml but this is optional and not intended to be portable, perhaps in the same way that @resource(mappedName="jms/foo") is optional and not intended to be portable, whereas @resource(lookup="jms/foo") is mandatory and portable)

3. Can I define the message destination reference for a MDB using annotation?

No, there is equivalent to using annotation.

4. Can I define the JNDI name of the destination on which a MDB consumes messages directly using annotation?

No, there is no way to define this using annotation, analogous to using a @resource(lookup="jms/foo") declaration when using the JMS API directly.

So, what seems to be missing?

A. As explained in (2) and (4) above, there isn't a standard way for MDB applications to short-circuit the use of message destination references and define the JNDI name of the destination from which a JMS message-driven bean consumes messages, either using ejb-jar.xml or annotations. This contrasts with EJBs which send messages, where the JNDI name of the destination can be specified in the MDB code using the JNDI API or a @resource(lookup="jms/foo") declaration.

B. As explained in (3) above, there is no standard way for the application to define using annotation the "message destination reference" on which the JMS message-driven bean is consuming messages.

Proposals:

A. It is proposed that the element in ejb-jar.xml be extended to define an additional sub-element which can be used to specify the JNDI name of the destination from which a JMS message-driven mean consumes messages. A suggested element name is :

<ejb-jar>
  <display-name>Ejb1</display-name>
  <enterprise-beans>
    <message-driven>
      <display-name>MDB1</display-name>
      <ejb-name>MessageBean</ejb-name>
      <message-destination-type>javax.jms.Queue</message-destination-type>
      <message-destination-jndi-name>jms/inboundQueue<message-destination-jndi-name>
      ...

It might be asked why this needs to be defined by a new subelement of rather than, say, a new standard activation configuration property. The answer is that the way that the JNDI name is defined needs to be consistent with the way that the message destination reference is defined, which is by the subelement of

B. It is proposed that the equivalent annotation be a new attribute of the @MessageDriven annotation, called messageDestinationJndiName. For example:

@MessageDriven(messageDestinationLookup="jms/inboundQueue")
public class MyMDB implements MessageListener {
....

(An alternative attribute name would be messageDestinationJndiName).

C. It is proposed that the @MessageDriven annotation be extended to allow applications to define the "message destination reference" on which the JMS message-driven bean is consuming messages, using a new attribute messageDestinationLink"

@MessageDriven(messageDestinationLink="ExpenseProcessingQueue")
public class MyMDB implements MessageListener {
....

Affected Versions

[3.2]

EJB 3.1 introduces asynchronous methods as a client invocation mechanism. However the method of designating asynchronous methods is left up to the bean developer instead of the application developer. Effectively limiting the application developer to be able to do asynchronous invocations anywhere.

Affected Versions

[3.2]

EJB 3.2 lite spec should support @asynchronous (Asynchronous session bean invocations) invocation of methods. It is not supported in EJB 3.1 lite. (see chapter 21.1, Table 27, EJB 3.1 spec)

Affected Versions

[3.2]

As for Java IO restrictions, I'd like to also discuss Classloading restrictions.

From EJB 3.1 FR - 21.2.2 Programming Restrictions

• The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams.
These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container's ability to properly manage the runtime environment.

First, that's not clear for me what is the "current" classloader. Would be great to clarify what it is really to avoid misunderstandings.
Apologize if the question is stupid, but does it mean "thread context class loader" or "component class loader (ie. this.getClass().getClassLoader())"?

I guess it's relevant to disallow setting the classloader, but why preventing to obtain the classloader as well as creating classloader?
IMHO, the point is only to avoid changes in container managed classloaders, then it does not matter if the user actually creates a classloader or wants to obtain an existing one?
I know that there are other rules preventing reflection API usage, ... but to load resources for example, it can be useful because the user does not need to use the Java IO api.

Moreover, if we refer to Java EE 6 spec - EE.6.2.4.7 Context Class Loader, it's fully acceptable to get the classloader and load resources (#getResource()) from the jar/ear/war.

Can we make things more consistent between Java EE Spec and EJB Spec?

Given the functionality of a transaction manager to set the transaction timeout [1], expose this feature in a spec defined manner.

With either the following annotation:

**TransactionTimeout.java**@Target({METHOD, TYPE})
@Retention(RUNTIME)
public @interface TransactionTimeout {
    long timeout() default -1L;
    TimeUnit unit() default TimeUnit.SECONDS;
}

Or the following descriptor:

<ejb-jar version="3.2">
  <assembly-descriptor>
    <container-transaction>
      <method>
        <ejb-name>A</ejb-name>
        <method-name>*</method-name>
      </method>
      <trans-attribute>RequiresNew</trans-attribute>
      <trans-timeout>
        <timeout>10</timeout>
        <unit>Seconds</unit>
      </trans-timeout>
    </container-transaction>
  </assembly-descriptor>
</ejb-jar>

(Note that the descriptor fragment only serves as an example.)

[1] http://docs.oracle.com/javaee/6/api/javax/transaction/TransactionManager.html#setTransactionTimeout%28int%29

@singleton EJBs are perfect MXBeans: http://www.adam-bien.com/roller/abien/entry/singleton_the_simplest_possible_jmx

The registration of @singleton in JMX runtime, however, requires a bit of plumbing.

Proposal:

Auto-registration of all EJB-methods of a @singleton bean with the @mxbean annotation:

1. All accessors should result in attributes (getters in read-only and getters / setters in writable attributes)
2. public EJB methods should be exposed as JMX-operations
3. A MXBean interface should be optional (it could be auto-generated by the EJB-container)
4. The MBean name should be derived from the class.getName() and the type from the class

Affected Versions

[3.2]

This is a request for the EJB specification to define a standard way to configure the connection factory used by a MDB to consume messages.

Currently there is no standard way to do this, and vendors differ in the way in which connection information is specified in a MDB. Some vendors support an activation property connectionFactoryJndiName but this is not defined in the EJB 3.1 (or the JCA 1.6) specifications and support for it is not universal. In fact some vendors expect connection information to be specified directly using non-standard activation properties rather than via a connection factory.

This limits the portability of applications between different JMS providers, resource adapters and application servers. It will also hinder the automatic provisioning of JMS resources in a PaaS environment which is a goal of Java EE 7.

Two alternatives are proposed:

1. Define a mandatory activation property connectionFactoryJndiName

This would make it mandatory for application servers to support the activation property connectionFactoryJndiName. This would essentially standardise what some vendors support already.

This could be specified in ejb-jar.xml as follows:

<ejb-jar>
  <enterprise-beans>
    <message-driven>
      <ejb-name>MyMDB</ejb-name>
      <activation-config>          
         <activation-config-property>
            <activation-config-property-name>connectionFactoryJndiName</activation-config-property-name>
            <activation-config-property-value>jms/connectionFactory</activation-config-property-value>
         </activation-config-property>
      <activation-config>   
      ...

...or using annotation as follows:

@MessageDriven(
    activationConfig = {
        @ActivationConfigProperty(
            propertyName="connectionFactoryJndiName", propertyValue="jms/connectionFactory")
    })
public class MyMDB implements MessageListener {
....

2. Define a new element under the element and a corresponding annotation

This option would propose that the element in ejb-jar.xml be extended to define an addition sub-element which can be used to specify the JNDI name of the connection factory used by a JMS message-driven bean to consume messages. A suggested element name is :

<ejb-jar>
  <enterprise-beans>
    <message-driven>
      <ejb-name>MessageBean</ejb-name>
      <message-destination-type>javax.jms.Queue</message-destination-type>
      <connection-factory-jndi-name>jms/connectionFactory<connection-factory-jndi-name>
      ...

To provide an equivalent annotation, a new attribute would need to be added to the @MessageDriven annotation. A suggested name is connectionFactoryJndiName:

@MessageDriven(connectionFactoryJndiName="jms/connectionFactory")
public class MyMDB implements MessageListener {
....

It might be asked why this needs to be defined by a new subelement of and a new attribute of @MessageDriven rather than by a new standard activation configuration property. Possible answers are:

• this is needed for consistency with the existing and the proposed subelements of . (See JMS_SPEC-54).

• the connection factory is such an important property of a JMS MDB that it deserves explicit support in the ejb-jar.xml schema and by the compiler, rather than being relegated to being just an activation property.

Options

In brief, the options are:

1. New mandatory activation property connectionFactoryJndiName
2. New element and corresponding annotation @MessageDriven(connectionFactoryJndiName=...
3. Both 1) and 2)
4. Neither

Affected Versions

[3.2]

In EJB 3.1, Session Beans were redefined to be Managed Beans. For some reason, this was not done for Message Driven Beans. I don't think it makes any sense for Message Driven Beans to not also be Managed Beans.

Affected Versions

[3.2]

Currently the EJB @asynchronous annotation can only be used with the EJB component model. With the introduction of managed beans and CDI, there are not many good technical reasons why the @asynchronous annotation should not be used in managed beans as well. In fact, many developers that are wary of the EJB component model would opt to use this model instead. In addition, decoupling EJB services such as @asynchronous from the component model moves towards removing one-off component models in Java EE in favor of unifying around managed beans/CDI.

We currently allow this capability in Resin. The code looks like this:

@ApplicationScoped
public class MyAsyncBean {
...
@asynchronous
public void myAsyncTask()

{ ... }

...
}

It should also be possible to use @asynchronous in CDI stereotypes so that developers can compose custom component types to meet the needs of their individual applications. The code for this could look like the following:

@ApplicationScoped
@stereotype
@retention(RUNTIME)
@target(TYPE)
@asynchronous
public @interface AsyncTask {}

Now, one outstanding item we did not resolve in Resin is the SessionContext.wasCancelCalled() method in managed beans, primarily because we did not want to introduce new APIs for EJB functionality and wanted to stick to what was available in the standard.

Affected Versions

[3.2]

Currently, local and no-interface beans are not guaranteed to be accessible cross-application via their global JNDI names. In order to guarantee such access in a standard manner, the beans must be remote - which really seems overkill since the bean is still on the same JVM, albeit in a different class-loader.

This seems like an artificial restriction that should be removed going forward.

Affected Versions

[3.2]

As the spec versions will change, the reference page and any versions in the document need to be updated

Affected Versions

[3.2]

[Note was marked XXX in Section 8.3.3] "In general, the semantics of transactions+interceptors is not as clear in the spec as it should be. Need to double-check the MDB chapter in particular."

Affected Versions

[3.2]

These chapters were in sync at some point. Either keep them in sync or replace with a ref to the platform spec

Affected Versions

[3.2]

There is no clear description in the spec (because at the beginning all features were required), what does support for a specific feature (say CMP in the new Optional part of the spec) mean in terms of any dependencies on other features (say EJBQL for the CMP example). This needs to be clarified.

Affected Versions

[3.2]

The current definition of a throws clause leaves the actual definition of an application exception optional. This should be made more strict by mandating that a throws clause of a checked exception implies that the exception is an application exception.

EJB 3.1 FR 14.2.1

The Bean Provider defines application exceptions. Application exceptions that are checked exceptions
may be defined as such by being listed in the throws clauses of the methods of the bean's business
interface, no-interface view, home interface, component interface, and web service endpoint.

Should become:

The Bean Provider defines application exceptions. Application exceptions that are checked exceptions
are defined as such by being listed in the throws clauses of the methods of the bean's business
interface, no-interface view, home interface, component interface, and web service endpoint.

Note that there are other spots which state the effect of a throws clause.

In EJB 3.1 the @schedule annotation was introduced supporting cron style scheduled tasks. However, this annotation does not take in to account cloud based servers/multiple instances running. To support this idea, I believe we should add an attribute "perVM" or similar. Setting this to true states that this scheduled job should be run on all instances. Setting this to false should result in the scheduled job running in only one instance of the application.

Affected Versions

[3.2]

By default, JEE synchronizes access to a stateful EJB to only allow a single thread at any given time.

EJB 3.1 brought about the @singleton annotation, along with two simple annotations: @lock(READ) and @lock(Write). These two anntotations should be ported to Stateful EJBs. Since the whole world is going concurrent, these controls will be completely necessary in the future. This would be extremely useful in Domain Driven Design.

The usefulness of this suggestion is greatly enhanced if there was a way to grab a handle to a Stateful EJB3. I'm putting the latter suggestion in another JIRA ticket.

Affected Versions

[3.2]

JSR 315 standardized how Servlets should initiate a programmatic login. This now happens via a call to HttpServletRequest#login, where previously a vendor specific mechanism was required.

For EJB components such a programmatic login has not been standardized, which means vendor specific solutions are still required (e.g. the ProgrammaticLogin from GlassFish 3.1). This hurts portability and may make it quite hard for bean providers to accomplish this task (the GlassFish class is easy to find, but for other EJB implementations this can be rather difficult).

I therefor propose to standardize programmatic login from within EJB components.

Such a login should support at least the following use cases:

• Login from within a local invocation of an EJB (where the call chain e.g. originates in a web component)
• Login from within a remote invocation of an EJB
• Login from within an asynchronous invocation of an EJB
• Login from within a timeout method (both automatic and programmatic)
• Login from a MDB during message delivery

Some thought should be given to the scope of the established security context. Some ideas:

• During the invocation of the above mentioned methods/message delivery only.
• For stateful session beans, for the full life-time of the bean until it is destroyed
• For all beans, for the full life-time of the bean, but only when login executed in the @PostConstruct method
• For all beans, for the full life-time of the bean, without restrictions in which method the login is executed

Possibly the API could make a distinction between a method invocation scoped login (first item) and a bean life-cycle scoped login (last three items).

E.g.

@Stateless
public class SomeBean {

    @Resource
    private SessionContext sessionContext;

    public void businessMethod() {
        sessionContext.invocationLogin("username", "password");
        assert sessionContext.getCallerPrincipal().getName().equals("username");
    }
}

@Stateless
public class SomeOtherBean {

    @Resource
    private SessionContext sessionContext;

    @PostConstruct
    private void doLogin() {
        sessionContext.beanLogin("username", "password");
    }

    public void businessMethod() {        
        assert sessionContext.getCallerPrincipal().getName().equals("username");
    }
}

Affected Versions

[3.2]

Another todo item

Affected Versions

[3.2]

The default injection case:

@PersistenceContext
EntityManager em;

should be also possible with:

@Inject
EntityManager em;

In this case an EntityManager from the single persistence unit defined in the persistence.xml with the TRANSACTED type is going to be injected.

The elements unitName and type should be "replaced" by the Qualifiers:

@Unit("")

and

@Transacted / @Extended

Stateful EJBs should be treated as first class citizens in the JEE container. I think you should be able to write a webapp that creates a stateful EJB, puts user data in it, then passes it to an MDB for offline processing. This could be useful for creating batch jobs, offline processing, or stat counting.

I think this has great relevance to Domain Driven Design. Domain Driven Design dictates that you create smart objects that mutate their state when actions are called on them. Stateful EJBs provide an implementation for DDD, but lack the ability to pass a particular instance around the container reliably.

The JEE spec already dictates that Stateful EJBs references can be stored in a Session object. This request just takes that a few steps farther.

Affected Versions

[3.2]

MBeanServer is especially important for management and monitoring, and so also in cloud scenarios.

It should be injectable with:

@resource
private MBeanServer platformMBeanServer;

instead of the current approach:

@PostConstruct
public void registerInJMX() {
try

{ platformMBeanServer = ManagementFactory.getPlatformMBeanServer(); }

catch (Exception e)

{ //... }

}

See also: http://www.adam-bien.com/roller/abien/entry/singleton_the_simplest_possible_jmx

I think it's going to become clear to us over the coming weeks/months how overloaded one of our most important lifecycles is, the Stateful session bean.

The root idea discussed with Ken last time around was to make ManagedBean our plain-cheese-pizza bean. I.e. a bean type where no particular services were enabled by default and all were possible. Certainly this means splitting the services out as we already plan to do. Making them available "outside" EJB is great as well.

That said, there's certainly something to be said about splitting the services up and making them available "inside" EJB as well. Simply making it possible to declare @ManagedBeans (or something similar) as a session bean would be a great start. I think we'll only get so far if we're solely thinking on how our services could be used externally.

Perhaps we start by splitting things up and figuring out how they apply to a "Managed SessionBean" and then where it fits we apply them to @ManagedBean in general. I think it would give us a critical buffer that we currently lack. When "ManagedBean" is truly a pojo under our control, many services are far easier to split out. When "ManagedBean" is a Servlet, that's a far different proposition.

So rather than let that slow us down, we could first do our work on "managed" beans which would simply have all pojo defaults and no "enterprise" defaults. We get the concept of services working "idividually" on this bean type. Once we get things carved out, we see what we can do about exporting the ones that can apply to any @ManagedBean.

Split first, then export where needed.

Some things that we split may not make sense to export to @ManagedBean in general. That being said, other specs may decide that some of the things we split and do not export to @ManagedBean still do apply to their models and could be free to add such requirements in their individual specifications. A concrete example is servlets might not choose to adopt our split out @asynchronous concept, but CDI might.

If we make split services usable inside EJB, using them outside EJB will be a whole lot easier.

EJB 3.2 lite spec should support JAX-RS Web Service Endpoint. It is not supported in EJB 3.1 lite. (see chapter 21.1, Table 27, EJB 3.1 spec).
JAX-RS should be also included in the WebProfile first (see Java EE 7 mailing list).

Given that lifecycle callbacks of singleton and stateful bean interceptors can now run within container managed transactions, I think we need to add a new method-intf type to the possible values of the container-transaction->method definition in the DD. The current values do not provide the ability to specifically target transaction attributes to this style of interceptor via the DD. The name "LifecycleInterceptor" seems a good fit. Thoughts?

I've seen at least one location in Javadoc that provides the list of possible meta-inf values, so at least one, maybe more, updates would be needed there as well.

Affected Versions

[3.2]

Currently the EJB @Startup/@dependsOn annotations can only be used with @singleton beans. The @Startup/@dependsOn annotations are actually a very useful and elegant way of declaratively listening to the container life-cycle and managing component inter-dependency. With the introduction of managed beans and CDI, there are not many good technical reasons why the @Startup/@dependsOn annotations should not be used in managed beans as well. Decoupling useful EJB services such as @Startup/@dependsOn from the component model moves towards removing one-off component models in Java EE in favor of unifying around managed beans/CDI.

We currently allow this capability in Resin. The code looks like this:

@ApplicationScoped
@startup
@dependsOn(...)
public class MyStartupBean {
...
@PostConstruct
public void init()

{ ... }
...
@PreDestroy
public void destroy() { ... }

...
}

It should also be possible to use @Startup/@dependsOn in CDI stereotypes so that developers can compose custom component types to meet the needs of their individual applications. The code for this could look like the following:

@ApplicationScoped
@stereotype
@retention(RUNTIME)
@target(TYPE)
@startup
@dependsOn(...)
public @interface StartupComponent {}

Affected Versions

[3.2]

The resource and transaction handling in the code examples is wrong. That should be fixed IMHO. See http://jandiandme.blogspot.com/2012/02/dangerous-code-example-in-ejb-31-spec.html .

The ToC does not have hyperlinks. I find it really useful for navigation.

Affected Versions

[3.2]

Context data can be easily passed between interceptors with a Map returned by the method: public Map<String, Object> getContextData().

This data, however, is not easily accessible to EJBs.

Proposal:

Addition of the method public Map<String, Object> getContextData();
to EJBContext (http://download.oracle.com/javaee/6/api/javax/ejb/EJBContext.html)

Affected Versions

[3.2]

A reminder

Affected Versions

[3.2]

Section 16.3.2.
Clarify availability of the resource factories used by the enterprise beans in Web Profile vs.Full Java EE Platform.

Affected Versions

[3.2]

This is a request for changes to the EJB specification to support the asynchronous delivery of messages to a message-driven bean in batches.

This new feature is described in JMS_SPEC-36. To support this there will be a new listener interface javax.jms.BatchMessageListener, which provides the method onMessages(Message[] messages).

Note that the final details of this new feature have yet to be confirmed, so this issue is dependent on JMS_SPEC-36.

Where batch delivery is not required, the existing javax.jms.MessageListener interface and its method onMessage(Message message) will continue to be used as before.

The following changes to the EJB specification are suggested (references are to the EJB 3.1 specification)

Section 5.4.2 "The Required Message Listener Interface"

Change: "The message-driven bean class's implementation of the javax.jms.MessageListenerinterface distinguishes the message-driven bean as a JMS message-driven bean."

To: "The message-driven bean class's implementation of the javax.jms.MessageListener or javax.jms.BatchMessageListener interface distinguishes the message-driven bean as a JMS message-driven bean."

An additional note should be added to state that a JMS message-driven bean may implement either of these interfaces.

5.6.2 "Message-Driven Bean Class"

Change: "In the case of JMS, this is the javax.jms.MessageListener interface."

To: "In the case of JMS, this is either the javax.jms.MessageListener or javax.jms.BatchMessageListener interface."

Add a note to say that if a MDB implements both interfaces, then the one specified using the element will be used. The other will be ignored. If the element is not defined we may want to specify a default, or we may want to leave this undefined. Add a clarification that for a given MDB, only one interface would be used in a given deployment.

13.6.3.2 "REQUIRED"

In all four places change: "onMessage method"

to: "onMessage or onMessages method"

21.3.5 "JMS 1.1 Requirements"

Change name of section to: "JMS 2.0 Requirements"

Change: "An implementation requiring the full EJB 3.1 API must include the JMS 1.1 extension"

To: "An implementation requiring the full EJB 3.2 API must include JMS 2.0"

In the fourth paragraph,

Change: "Enterprise beans must not call the javax.jms.MessageConsumer.setMessageListener or javax.jms.MessageConsumer.getMessageListener method."

To: "Enterprise beans must not call the javax.jms.MessageConsumer.setMessageListener, javax.jms.MessageConsumer.setBatchMessageListener, javax.jms.MessageConsumer.getMessageListener or javax.jms.MessageConsumer.getBatchMessageListener methods."

5.4.14 "Activation Configuration Properties"

This section introduces a list of activation configuration properties for JMS message-driven beans. An additional section should be inserted which describes the additional properties needed for batch delivery:

Insert new section: 5.4. "Batch delivery" as follows:

If the JMS Message-driven bean implements the javax.jms.BatchMessageListener interface then the following activation configuration properties may be used to configure batch delivery:

• batchSize: If set to greater than zero, messages will be delivered by calling the onMessages(Message[] messages) method. The bean class must implement javax.jms.BatchMessageListener. Messages will be delivered in batches of up to batchSize messages. The actual batch size used may be any value between one and the specified batchSize. It is invalid to specify a value greater than zero if the bean class does not implement javax.jms.BatchMessageListener.

• batchTimeout: If batch delivery is used, this specifies the maximum number of milliseconds that the JMS provider may defer message delivery for in order to assemble a batch of messages that is as large as possible but no larger than the batch size.

Currently the EJB @Lock/@AccessTimeout annotations can only be used with @singleton beans (@AccessTimeout can also be used with @stateful). The @Lock/@AccessTimeout annotations are actually a very useful and elegant way of declaratively managing component concurrency. With the introduction of managed beans and CDI, there are not many good technical reasons why the @Lock/@AccessTimeout annotations should not be used in managed beans as well. Decoupling useful EJB services such as @Lock/@AccessTimeout from the component model moves towards removing one-off component models in Java EE in favor of unifying around managed beans/CDI.

We currently allow this capability in Resin. The code looks like this:

@ApplicationScoped
public class MyConcurrentBean {
...
@lock(READ)
@AccessTimeout(...)
public void myReadLockedTask()

{ ... }
...
@lock(WRITE)
@AccessTimeout(...)
public void myWriteLockedTask() { ... }

...
}

It should also be possible to use @Lock/@AccessTimeout in CDI stereotypes so that developers can compose custom component types to meet the needs of their individual applications. The code for this could look like the following:

@ApplicationScoped
@stereotype
@retention(RUNTIME)
@target(TYPE)
@lock
@AccessTimeout(...)
public @interface ConcurrentComponent {}

Affected Versions

[3.2]

See changes in Section 4.3.3.

Affected Versions

[3.2]

Chapter 14, "Deployment Descriptor"
Deployment descriptor schema should be updated to the latest version and compared against the schema on http://java.sun.com/xml/ns/javaee/ and reviewed for correctness and compatibility with this document.

Affected Versions

[3.2]

It would be nice to have a well defined way to access all timers available in the container. Right now, we can fetch only timers associated with particular bean using i.e. injected TimerService and its getTimers().

How about defining either:

a.) additional method, i.e.

TimerService#getAllTimers()

b.) overloaded method, i.e.:

TimerService#getTimers(boolean containerWide)

when set to 'true' it would return all available timers on the container level; when set to 'false' it would return bean-private timers only.
TimerService#getTimers() and TimerService#getTimers(false) must yield the same results.

This problem has been "discussed" i.e. here: http://stackoverflow.com/questions/4530275/how-to-get-all-ejb-timers or here: http://stackoverflow.com/questions/8681557/job-scheduling-ejb-3-1-timers-or-quartz/8683595#8683595

It has been more than five years since EJB 3/Java EE 5 was finalized. In terms of the technology industry, that's almost a life-time. At this point, I don't think it is sensible to continue to support the flawed EJB 2 development model. Pruning it in EJB 3.2 would significantly simplify the EJB specification/implementations going forward.

Affected Versions

[3.2]

Alle EJB 3.1 methods, also @asynchronous, are defaulted to the @required transaction setting. @asynchronous methods are executed asynchronously, so that the already active transaction just cannot be reused. Especially not, if the execution of the @asynchronous method takes longer, than the execution of the invoker.

Affected Versions

[3.2]

Currently the EJB @schedule annotation can only be used with the EJB component model. With the introduction of managed beans and CDI, there are not many good technical reasons why the @schedule annotation should not be used in managed beans as well. In fact, many developers that are wary of the EJB component model would opt to use this model instead. In addition, decoupling EJB services such as @schedule from the component model moves towards removing one-off component models in Java EE in favor of unifying around managed beans/CDI.

We currently allow this capability in Resin. The code looks like this:

@ApplicationScoped
public class MyScheduledBean {
...
@schedule(...)
public void myScheduledTask()

{ ... }

...
}

It should also be possible to use @schedule in CDI stereotypes so that developers can compose custom component types to meet the needs of their individual applications (currently the @schedule annotation can only be applied to methods). The code for this could look like the following:

@ApplicationScoped
@stereotype
@retention(RUNTIME)
@target(TYPE)
@schedule(...)
public @interface MonthlyTask {}

Affected Versions

[3.2]

Currently the EJB @TransactionAttribute annotation can only be used with the EJB component model. With the introduction of managed beans and CDI, there are not many good technical reasons why the @TransactionAttribute annotation should not be used in managed beans as well. In fact, many developers that are wary of the EJB component model would opt to use this model instead. In addition, decoupling EJB services such as @TransactionAttribute from the component model moves towards removing one-off component models in Java EE in favor of unifying around managed beans/CDI.

You should be able to do something like:

@TransactionAttribute(RequiresNew)
@RequestScoped
public class OrderService{
...

public void store()

{...}

}

Currently transactions are re-invented in various projects with custom interceptor bindings like @transactional in CDI.

Section 18.4.3 of the EJB 3.1 spec defines that timers created by the EJB Timer Service are persistent:

Timers are persistent objects (unless explicitly created as non-persistent timers). In the event of a container crash or container shutdown, any single-event persistent timers that have expired during the intervening time before container restart must cause the corresponding timeout callback method to be invoked upon restart. Any interval persistent timers or schedule based persistent timers that have expired during the intervening time must cause the corresponding timeout callback method to be invoked at least once upon restart.

There is however no notion of where timers are exactly persisted. In practice implementations often use an embedded database for this persistence requirement, which in turn means timers end up being persisted somewhere inside the installation directory of the application server.

This can be undesirable since it means outstanding timers are lost whenever an application is e.g. migrated to another application server, the application server is upgraded, etc. Implementations have recognized this issue and many provide a way to persist timers to a user-specified database.

I would like to propose standardizing this, so EJB applications can be more portable.

For instance:

@Stateless
public class SomeBean {

    @Resource(lookup="java:/myDs")
    private DataSource dataSource;

    @Resource
    private TimerService timerService;

    public void doSchedule() {
        timerService.createSingleActionTimer(new Date(), new TimerConfig("test", dataSource));
    }

    @Timeout
    public void timeout(Timer timer) {

    }

    @Schedule(hour = "*", minute = "*/30", second="0", dataSource="java:/myDs")
    public void scheduled() {

    }
}

In the example above, both the programmatic and automatic timers would be persisted to the data source located at "java:/myDs" in a table with a default name defined by the spec. Optionally the user should be able to specify a table name, e.g.:

@Schedule(hour = "*", minute = "*/30", second="0", dataSource="java:/myDs", table="EJB_TIMERS")
public void scheduled() {

}

The user should not need to know anything about the table structure in advance. If the table doesn't exist yet, the container should create it with the required columns.