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.
toggle quoted messageShow quoted text
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,
|
|
Re: Question on transaction propagation in EJB remoting
Bill Shannon
Yes, sorry, Kevin is right.
toggle quoted messageShow quoted text
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,
|
|
Re: Question on transaction propagation in EJB remoting
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
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.
|
|
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
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
|
|
Re: Question on transaction propagation in EJB remoting
Bill Shannon
Yes, transaction propagation is required, but interoperability of
transaction propagation between vendors is unspecified.
toggle quoted messageShow quoted text
klaus.rothert@... wrote on
08/10/2018 05:30 AM:
Hello,
|
|
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 which kind of implies transaction propagation. In the EJB 3.2 interoperability specification I can only find 10.6 Transaction Interoperabilitywhich 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: Javadoc for Java EE 8?
Bill Shannon
|
|
Re: Javadoc for Java EE 8?
|
|
Re: Javadoc for Java EE 8?
reza_rahman <reza_rahman@...>
We have discussed this issue offline with Oracle if I remember correctly. The suggestion was to redirect the old URLs that Google, etc pick up to the new location. I believe the outcome was that this will need to be tackled by the EE4J effort somehow (not really sure how without cooperation from Oracle). Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- From: Kevin Sutter <kwsutter@...> Date: 11/28/17 12:02 PM (GMT-05:00) To: javaee-spec@javaee.groups.io Subject: Re: [javaee-spec] Javadoc for Java EE 8?
|
|
Re: Javadoc for Java EE 8?
Thanks, Ivar... Even Google couldn't find this for me...
|
|
Re: Javadoc for Java EE 8?
You can find it at https://javaee.github.io/javaee-spec/javadocs/
|
|
Re: Javadoc for Java EE 8?
On Tue, Nov 28, 2017 at 5:41 PM Kevin Sutter <kwsutter@...> wrote: In the past, the javadoc for Java EE was housed on docs.oracle.com like this for Java EE 7: -- Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader
|
|
Javadoc for Java EE 8?
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
|
|
Re: Platform wide guideline for build-in annotation literals?
Bill Shannon
Arjan Tijms wrote on 09/19/17 01:29 PM:
On Tue, Sep 19, 2017 at 12:09 pm, Bill Shannon wrote: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. Hopefully this is very much an advanced case and not something that typical applications will need to do. 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?Perhaps, but without members the annotation instance is a totally static singleton, like enum values basically. With members this is obviously not the case. Depending on each spec to do it means that some won't.Possibly indeed, but not sure how feasible it is to get that in. 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! :-)
|
|
Re: Platform wide guideline for build-in annotation literals?
On Tue, Sep 19, 2017 at 12:09 pm, Bill Shannon wrote:
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? 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. Perhaps, but without members the annotation instance is a totally static singleton, like enum values basically. With members this is obviously not the case. 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
|
|
Re: Platform wide guideline for build-in annotation literals?
Bill Shannon
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. How would applications use
them? 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? Maybe this really
belongs in the JDK...
Arjan Tijms wrote on 9/19/17 9:00 AM:
|
|
Re: Platform wide guideline for build-in annotation literals?
Sorry, that's not what I meant ;)
|
|
Re: Platform wide guideline for build-in annotation literals?
I'd say if there is an umbrella spec with these kinds of annotations then then it must be a requirement for the other specs to implement them. Otherwise, leave the annotations within the individual specs so that it's more clear that the annotation only applies to code in that spec. Once you move it to an umbrella spec, I'd just naturally assume it's able to be used anywhere.
On Tuesday, September 19, 2017, 6:45:08 AM CDT, Arjan Tijms <arjan.tijms@...> wrote:
Hi, CDI 2.0 introduced a number of very convenient build-in annotation literals, for many of the annotations it owns and for some it doesn't own (JSR 330). See: http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals I think something like this would be a prime candidate for an umbrella spec guideline so: 1. All specs do this for their relevant annotations (e.g. @Transactional in JTA, @ViewScoped in JSF, @RememberMe in Security, @Named in AtInject, etc) 2. All specs do this in a consistent way Thoughts? Kind regards, Arjan Tijms
|
|