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?

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?

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.

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

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

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

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

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

You can find it at https://javaee.github.io/javaee-spec/javadocs/

In the past, the javadoc for Java EE was housed on docs.oracle.com like this for Java EE 7:

https://docs.oracle.com/javaee/7/api/

But, I can't find a corresponding site for Java EE 8.

Thanks, Kevin

On Tue, Sep 19, 2017 at 12:09 pm, Bill Shannon wrote:

The CDI expert group didn't raise this at the platform level, and they didn't even do this consistently for their annotations

I'm not sure if there's any inconsistency, other than creating literals for the JSR 330 spec and including them in 299. Or is that what you're referring to?

Some of the annotations have literals and some do not.  There may be some rationale for why only some of the annotations need literals, but it wasn't explained.

, so I'm not clear on what their intent is with these annotation instances.  How would applications use them?

They're mostly used for the various builders that CDI has for dynamically adding annotations to beans. CDI already has a helper class for that that makes it somewhat easier (https://docs.jboss.org/cdi/api/2.0/javax/enterprise/util/AnnotationLiteral.html), but even with the helper class it's still a bit verbose.

For a practical example see: http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html

It's also used for lookups, as in this code:

myGreetings.select(NamedLiteral.of("northern")).get();

For the full context see: https://github.com/javaee-samples/javaee8-samples/blob/master/cdi/qualified-lookup/src/test/java/org/javaee8/cdi/qualified/lookup/QualifiedLookupTest.java#L41

In that latter example a bean is selected that has the @Named("northern") annotation applied to it.

Hopefully this is very much an advanced case and not something that typical applications will need to do.

If there's a reason applications need to be able to create annotation instances, wouldn't it be better if it worked the same whether or not the annotation has members? 

Perhaps, but without members the annotation instance is a totally static singleton, like enum values basically. With members this is obviously not the case.

If an annotation evolves to have members, would you still want a static instance?  Wouldn't it be simpler if there was always just one way to get an instance?

Maybe this really belongs in the JDK...

Possibly indeed, but not sure how feasible it is to get that in.

For now Java EE support throughout all applicable specs (basically the specs that already leverage CDI) isn't that hard at all. Had I learned about this annotation literals a tiny bit earlier I could have added them trivially to JSF and Java EE security (if the spec lead and EG would have agreed, of course).

Depending on each spec to do it means that some won't.

This is not the first thing about annotations that we wished every spec would handle.  I really wish we could push more of this into the JDK, or find a way to centralize all of this in a place that would apply to all Java EE uses of annotations automatically.

Lacking that, a "design pattern" as you suggest might be the best approach.  Another item for the future Eclipse project to address!  :-)

On Tue, Sep 19, 2017 at 12:09 pm, Bill Shannon wrote:

The CDI expert group didn't raise this at the platform level, and they didn't even do this consistently for their annotations

I'm not sure if there's any inconsistency, other than creating literals for the JSR 330 spec and including them in 299. Or is that what you're referring to?

, so I'm not clear on what their intent is with these annotation instances.  How would applications use them?

They're mostly used for the various builders that CDI has for dynamically adding annotations to beans. CDI already has a helper class for that that makes it somewhat easier (https://docs.jboss.org/cdi/api/2.0/javax/enterprise/util/AnnotationLiteral.html), but even with the helper class it's still a bit verbose.

For a practical example see: http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html

It's also used for lookups, as in this code:

myGreetings.select(NamedLiteral.of("northern")).get();

For the full context see: https://github.com/javaee-samples/javaee8-samples/blob/master/cdi/qualified-lookup/src/test/java/org/javaee8/cdi/qualified/lookup/QualifiedLookupTest.java#L41

In that latter example a bean is selected that has the @Named("northern") annotation applied to it.

If there's a reason applications need to be able to create annotation instances, wouldn't it be better if it worked the same whether or not the annotation has members? 

Perhaps, but without members the annotation instance is a totally static singleton, like enum values basically. With members this is obviously not the case.

Maybe this really belongs in the JDK...

Possibly indeed, but not sure how feasible it is to get that in.

For now Java EE support throughout all applicable specs (basically the specs that already leverage CDI) isn't that hard at all. Had I learned about this annotation literals a tiny bit earlier I could have added them trivially to JSF and Java EE security (if the spec lead and EG would have agreed, of course).

Kind regards,
Arjan Tijms

Arjan Tijms wrote on 9/19/17 9:00 AM:

Sorry, that's not what I meant ;)

What I meant was that each annotation should of course stay within their respective spec. I.e. @Transactional should of course stay in JTA.

But the annotation literal support should be somewhat mandated by the umbrella spec, so that all specs provide those for their annotations (where applicable) and all specs do it in the same way.

For instance, CDI now has:

RequestScoped requestScopedLiteral = RequestScoped.Literal.INSTANCE;

So JSF should get:

ViewScoped viewScopedLiteral = ViewScoped.Literal.INSTANCE;

And not say:

ViewScoped viewScopedLiteral = ViewScoped.getAnnotation();

or 

ViewScoped viewScopedLiteral = ViewScoped.of(ViewScoped.class);

or ...

ViewScoped should of course stay within JSF and nothing should ever move to the umbrella spec. The umbrella spec should only establish a rule saying that annotation literals are to be done via [annotation class].Literal.INSTANCE;

Hope it's more clear now ;)

Kind regards,
Arjan Tijms

 

Sorry, that's not what I meant ;)

What I meant was that each annotation should of course stay within their respective spec. I.e. @Transactional should of course stay in JTA.

But the annotation literal support should be somewhat mandated by the umbrella spec, so that all specs provide those for their annotations (where applicable) and all specs do it in the same way.

For instance, CDI now has:

RequestScoped requestScopedLiteral = RequestScoped.Literal.INSTANCE;

So JSF should get:

ViewScoped viewScopedLiteral = ViewScoped.Literal.INSTANCE;

And not say:

ViewScoped viewScopedLiteral = ViewScoped.getAnnotation();

or 

ViewScoped viewScopedLiteral = ViewScoped.of(ViewScoped.class);

or ...

ViewScoped should of course stay within JSF and nothing should ever move to the umbrella spec. The umbrella spec should only establish a rule saying that annotation literals are to be done via [annotation class].Literal.INSTANCE;

Hope it's more clear now ;)

Kind regards,
Arjan Tijms