Date   

Re: Javadoc for Java EE 8?

Bill Shannon
 

They're also linked from the Java EE Documentation page.

Kevin Sutter wrote on 11/28/17 09:02 AM:

Thanks, Ivar...  Even Google couldn't find this for me...


Question on transaction propagation in EJB remoting

klaus.rothert@...
 

Hello,

we recently looked into IBM Liberty as Java EE container and were very suprised to find that it does not support inbound or outbound transaction propagation. Asking our IBM contact about that we were told that supporting transaction propagation over IIOP is nothing they intend to support.

Isn't supporting transaction propagation over IIOP a requirement as of Java EE 7 and 8?
In the specefication I can't find a specific requirement.

In EE.6.2.3.6 it is mentioned that

Note that while RMI-IIOP doesn’t specify how to propagate the current
security context or transaction context, the EJB interoperability specification does
define such context propagation.
which kind of implies transaction propagation.

In the EJB 3.2 interoperability specification I can only find

10.6 Transaction Interoperability
Transaction interoperability between containers provided by different vendors is an optional feature in this version of the EJB specification
which to my understanding only means its optional between different vendors. Which implies it is not optional with containers from the same vendor.

Could you please help me to clarify this.

Thanks
Best regards
Klaus Rothert


Re: Question on transaction propagation in EJB remoting

Bill Shannon
 

Yes, transaction propagation is required, but interoperability of transaction propagation between vendors is unspecified.

klaus.rothert@... wrote on 08/10/2018 05:30 AM:

Hello,

we recently looked into IBM Liberty as Java EE container and were very suprised to find that it does not support inbound or outbound transaction propagation. Asking our IBM contact about that we were told that supporting transaction propagation over IIOP is nothing they intend to support.

Isn't supporting transaction propagation over IIOP a requirement as of Java EE 7 and 8?
In the specefication I can't find a specific requirement.

In EE.6.2.3.6 it is mentioned that

Note that while RMI-IIOP doesn’t specify how to propagate the current
security context or transaction context, the EJB interoperability specification does
define such context propagation.
which kind of implies transaction propagation.

In the EJB 3.2 interoperability specification I can only find

10.6 Transaction Interoperability
Transaction interoperability between containers provided by different vendors is an optional feature in this version of the EJB specification
which to my understanding only means its optional between different vendors. Which implies it is not optional with containers from the same vendor.

Could you please help me to clarify this.

Thanks
Best regards
Klaus Rothert


Re: Question on transaction propagation in EJB remoting

klaus.rothert@...
 

Thanks for the clarification Bill.

How can IBM Liberty be listed as a Java EE 7 and 8 Full Platform Compatible Implementation if it does not support transaction propagation in EJB remoting at all?

Is that not tested in some kind of compatibilty test?
Shouldn't Liberty be removed from that list?

Best Regards
Klaus


Java EE 8 dependency JTA issue on modulepath

Guillermo González de Agüero
 

Hi,

Doing some testing with Java modules, I found the Java EE 8 API has a splitted package problem on JTA. This was fixed on a JTA MR but it was done after Java EE 8 went final [1].

This is only a problem when the old JTA dependency is put on the module path.

We still have a long road before Jakarta EE publishes its first version. Is it possible to get a Java EE 8.0.1 API release updating this dependency?


Regards,

Guillermo González de Agüero




Re: Question on transaction propagation in EJB remoting

Kevin Sutter
 
Edited

Hi Klaus,
In section E.4.2.1.1 Transaction Requirements, there is the following statement.  Liberty fully supports this "local" transaction propagation.

Note that this transaction propagation requirement applies only to invocations
of enterprise beans in the same Java EE product instance[1] as the invoking
component. Invocations of enterprise beans in another Java EE product
instance (for example, using the EJB interoperability protocol) need not prop-
agate the transaction context. See the EJB specification for details.


Re: Question on transaction propagation in EJB remoting

Arjan Tijms
 

Hi Klaus,

I can’t comment about this issue, but full 100% absolutely compatibility with the Java EE specs is rare. The CTS/TCK supposedly contains a LOT of tests, but there’s always things slipping through, or are silently accepted.

JEUS for instance is listed as EE 7 compatible, which means it should implement JASPIC, but it doesn’t.

EE implementations should also by default use JACC for authorisation, but a couple just don’t. Every EE implementation must ship with a default JACC provider, but one doesn’t and magically is still certified.


Re: Question on transaction propagation in EJB remoting

Bill Shannon
 

Yes, sorry, Kevin is right.

Transaction propagation is only required within a single product instance, which (depending on the architecture of the product) might involve multiple processes (e.g., a cluster).  Transaction propagation between two separate installations of the same vendor's product is not required.

What's the exact situation where you were expecting transaction propagation to work?

Kevin Sutter wrote on 08/16/2018 01:28 PM:

Hi Klaus,
In section E.4.2.1.1 Transaction Requirements, there is the following statement.  Liberty fully supports this "local" transaction propagation.

Note that this transaction propagation requirement applies only to invocations
of enterprise beans in the same Java EE product instance[1] as the invoking
component. Invocations of enterprise beans in another Java EE product
instance (for example, using the EJB interoperability protocol) need not prop-
agate the transaction context. See the EJB specification for details.


Re: Java EE 8 dependency JTA issue on modulepath

Bill Shannon
 

GlassFish 5.0.1 will use JTA 1.3.  The current development release includes this change.

We're not planning to publish new versions of the API jar files since this doesn't change the effective API used when compiling programs.

In what scenario are you concerned about updating this dependency?

Guillermo González de Agüero wrote on 08/16/2018 06:08 AM:

Hi,

Doing some testing with Java modules, I found the Java EE 8 API has a splitted package problem on JTA. This was fixed on a JTA MR but it was done after Java EE 8 went final [1].

This is only a problem when the old JTA dependency is put on the module path.

We still have a long road before Jakarta EE publishes its first version. Is it possible to get a Java EE 8.0.1 API release updating this dependency?


Regards,

Guillermo González de Agüero