You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repository was archived by the owner on Jan 30, 2019. It is now read-only.
clarification needed: RMI/IIOP being proposed optional does not mean dropping the requirement for EJB remote protocols supporting transactions and security #55
Chapters EE.2.7.4 and EE.6.2.3.6 of the Java EE 8 spec deal with the declaration of RMI-IIOP as proposed optional. When reading this section and the corresponding parts of the EJB 3.2 spec, it's not clear if it means
that a future Java EE product must provide some standardized remote EJB protocol that supports transaction and security context propagation (but it needs not to be RMI/IIOP)
or
that a future Java EE product must provide any (could even be vendor specfic) remote EJB protocol that supports transaction and security context propagation (but it needs not to be RMI/IIOP)
or (hopefully not)
that a future Java EE product does not need to provide any EJB remote protocol that supports transaction and security context propagation.
We've got many applications using remote transactions that can't be easily converted to a different paradigm. So it's important to know that future Java EE products will support that feature. CORBA ORB interoperability is not a requirement for us although we see advantages in having a standardized (not vendor-specific) remote EJB protocol including transactions and security.
We would appreciate a clarification statement added for example in section EE.2.7.4 and when describing further details of RMI/IIOP becoming optional in any future Java EE specification.
Some of this aspects are discussed in issue #16 Prune CORBA interoperability.
Chapters EE.2.7.4 and EE.6.2.3.6 of the Java EE 8 spec deal with the declaration of RMI-IIOP as proposed optional. When reading this section and the corresponding parts of the EJB 3.2 spec, it's not clear if it means
that a future Java EE product must provide some standardized remote EJB protocol that supports transaction and security context propagation (but it needs not to be RMI/IIOP)
or
that a future Java EE product must provide any (could even be vendor specfic) remote EJB protocol that supports transaction and security context propagation (but it needs not to be RMI/IIOP)
or (hopefully not)
that a future Java EE product does not need to provide any EJB remote protocol that supports transaction and security context propagation.
We've got many applications using remote transactions that can't be easily converted to a different paradigm. So it's important to know that future Java EE products will support that feature. CORBA ORB interoperability is not a requirement for us although we see advantages in having a standardized (not vendor-specific) remote EJB protocol including transactions and security.
We would appreciate a clarification statement added for example in section EE.2.7.4 and when describing further details of RMI/IIOP becoming optional in any future Java EE specification.
Some of this aspects are discussed in issue #16 Prune CORBA interoperability.