A couple of document corrections/improvements:
Several sections of the spec refer to capability which we removed from
this version, specifically distributability. For example (there are
others)
3.1.1 Application Component Provider’s Responsibilities
Task classes can optionally implement the
javax.enterprise.concurrent.ManagedTask interface to provide identity
information, execution properties such as whether the task can be run
in a remote process, and to register a
javax.enterprise.concurrent.ManagedTaskListener instance to receive
lifecycle events notifications.
Consider instead:
Task classes can optionally implement the
javax.enterprise.concurrent.ManagedTask interface to provide execution
properties and to register a
javax.enterprise.concurrent.ManagedTaskListener instance to receive
lifecycle events notifications. Execution properties allow
configuration and control of various aspects of the task including
whether to suspend any current transaction on the thread and identity
information.
Someone has asked for clarity on the expected behavior of a JSR236 impl
with regards to user transactions, specifically what happens if a CMT
EJB creates a task which accesses a user transaction and submits it.
The EJB spec states that a naming exception must be thrown if a CMT
enterprise bean attempts to lookup or otherwise access the user
transaction registered in JNDI. However, because the lookup is
performed in a task which is expected to be executing in a thread other
than that of the CMT EJB, there seems no good reason that such a task
couldn't access a user transaction. In that section, it might be
useful to also explain what is otherwise hidden in the javadoc, that
is, any transactions active in the submitting thread are suspended by
default, otherwise configured by the corresponding execution property.