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

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 cl

Yes, transaction propagation is required, but interoperability of transaction propagation between vendors is unspecified. klaus.rothert@... wrote on 08/10/2018 05:30 AM:

They're also linked from the Java EE Documentation page. Kevin Sutter wrote on 11/28/17 09:02 AM:

Arjan Tijms wrote on 09/19/17 01:29 PM: 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.

The CDI expert group didn't raise this at the platform level, and they didn't even do this consistently for their annotations, so I'm not clear on what their intent is with these annotation instances.

That's it! Clearly you guys don't appreciate what we're giving you! The deal is off!!! :-) Jeff Genender wrote on 08/31/2017 09:13 PM:

No, sorry. Guillermo González de Agüero wrote on 08/31/2017 03:35 PM:

I think you should take this up with the owners of the next release. Ondrej Mihályi wrote on 08/31/2017 03:10 PM:

Or whatever you guys end up calling it. Not my problem! :-) Kevin Sutter wrote on 08/31/2017 02:14 PM:

Java EE 8 is essentially done. Your suggested fix would result in an API jar file that's not usable by people who aren't using Maven. If some application server provides a beta API that's not exactly

The Maven project that builds the API jar file does so by recompiling all the javax.* source files. Because some of these source files have static dependencies on non-javax.* classes, those classes ar

Jens Engel wrote on 08/ 4/17 02:34 AM: Right, which is why I expect many Java EE vendors will be supporting these technologies for quite some time, even after they become optional. Java EE issue track

Jens Engel wrote on 08/03/2017 06:16 AM: The EJB spec should have clear functionality requirements that are independent of the remote protocol being used. If this isn't clear in the EJB spec, we'll ma

At least "J2EE" was the correct term at one point, even though it's been obsolete for more than 10 years and we've been calling it "Java EE" longer than it was ever called "J2EE". Suffering from our o

Jeff Genender wrote on 08/ 2/17 12:08 PM: I know it's like whack-a-mole, but I can whack those moles while still frying fish. And if all the rest of you would help me whack those moles, it might actua

Hi Jens. First of all, there is nothing named "JEE". The correct name is "Java EE". "Proposed optional" means that it might be declared optional in the next release. In Java EE 8, it is still required

Note that the schemas are in GitHub here. Kevin Sutter wrote on 06/ 6/17 11:29 AM:

All the downloads from our original java.net project are still available in the GitHub repository here. I should probably add a link from the web site to make it more obvious. Kevin Sutter wrote on 06