Topics (original) (raw)
- Javaee | Javaee-Spec
- Topics
| Java EE 8 dependency JTA issue on modulepath 2 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 [1] https://javaee.groups.io/g/jta-spec/message/1 Started by Guillermo González de Agüero @ · Most recent @ |
|---|
| Question on transaction propagation in EJB remoting 6 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. ( https://www.ibm.com/support/knowledgecenter/en/SSAW57\_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp\_ejb\_remote.html ) 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 Started by klaus.rothert@... @ · Most recent @ |
| Javadoc for Java EE 8? 7 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 Started by Kevin Sutter @ · Most recent @ |
| Platform wide guideline for build-in annotation literals? 6 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 Started by Arjan Tijms @ · Most recent @ |
| Request for Maven Java EE 8 artifact 20 Hi all, Java EE 8 is near release and I'd like to request a simple change on the artifact layout that is published to Maven central. Until Java EE 7 the artifact contained all the API classes packaged on it, which doesn't work with Maven dependency exclusions. It is ok when coding against that whole EE version, but becomes problematic when you want to upgrade one dependency API. For example, I've been using CDI 2.0 on a patched Java EE 7 server. For that project I need two provided dependencies: Java EE 7 (which bundles CDI 1.2) and CDI 2.0 to get access to the new interfaces. I won't have problems at runtime since the correct classes will be provided by the server, but at compile time the classpath has two versions of the same classes, and I can't easily do nothing to fix it My request then is, now that we have the missing JPA API on Maven (thanks Lukas for that), could the Java EE 8 artifact just be an aggregator declaring dependencies to all other specs? Using that approach we could benefit from Maven dependency exclusion mechanism and just exclude the "outdated" version. This will become more important as side projects like MicroProfile gain momentum, since it also declares dependencies on EE specs and a lot of people will likely combine the two technologies. Any thoughts? Regards, Guillermo González de Agüero Started by Guillermo González de Agüero @ · Most recent @ |
| Cats out of the bag... impact? 2 Any thoughts on impact from this? http://www.infoworld.com/article/3217347/java/oracle-doesnt-want-java-ee-any-more.html What will this potentially do to this group? Thanks, Jeff Started by Jeff Genender @ · Most recent @ |
| RMI-IIOP proposed optional 15 Hello, I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional. Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself? Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls? A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?). Regards -Jens Started by Jens Engel @ · Most recent @ |
| Java EE 8 Platform and Web Profile Final Draft specs Greetings, I've just uploaded Final Draft versions of the Java EE and Web Profile specifications to our Java EE downloads area: https://github.com/javaee/javaee-spec/tree/master/download. These are the versions that we to submit to the JCP later this week for the Final Approval Ballot. The few changes from the Proposed Final Draft of the Java EE Platform specification are referenced in Appendix EE.B. Briefly, these include minor clarifications regarding metadata-complete for application clients and updates to the Security chapter to align with the requirements of the Java EE Security API. The contents of the Web Profile specification are unchanged from the Proposed Final Draft. regards, -Linda Started by Linda DeMichiel @ |
| Java EE 8 Proposed Final Draft I've just uploaded to our project documents area (https://github.com/javaee/javaee-spec/tree/master/download) the drafts of the Java EE 8 Platform and Web Profile specification documents that we plan to submit to the JCP for Proposed Final Draft. The drafts have changebars indicating all changes made to the documents since the Public Review draft. Changes are also summarized in the appendices. Changes in this draft are quite minimal, mostly to sync with updates in the Java Security API. At this point we are not anticipating much further in the way of updates to the Platform spec, other than what might be needed to reflect any further updates to Java EE Security. Please let me know if you find any issues. thanks, -Linda Started by Linda DeMichiel @ |
| Inconsistent or incomplete usage of @Repeatable 5 Hi, I know we discussed this back in May of 2016, but actual practice is causing us to scratch our heads... Without the @Repeatable annotation usage being spelled out at the Platform level, we're discovering some inconsistent or incomplete usage patterns. For example, JPA has stepped up to use the @Repeatable annotation on several of their annotations. And, Common Annotations has identified the use with @Resource and @DataSourceDefinition. But, what about @EJB? It seems that this would be another valid usage of @Repeatable. So, with each spec deciding for themselves whether to support @Repeatable, we don't have a consistent story for our users. It won't be intuitive. Sometimes you can skip the plural form of the annotation, and sometimes you can't. You'll just have to "know"... I haven't thought through every plural Annotation usage, so I'm not sure if the @EJB is the only miss. If we're down to just a handful of misses, should we step up to support these additional @Repeatables in Java EE 8? Thanks, Kevin Started by Kevin Sutter @ · Most recent @ |
| URL redirects from java.net pages to new pages on github? Dear Java EE and java.net maintainers, Since java.net was shutdown, most of the content has been migrated to github. However, although much of the content is available, it's not easy to find it because there are still many links refereing to java.net on the internet and even search engines like google yield these old links among the to results. Is it possible to set up a redirect from java.net to the new pages for the content that is already migrated and easy to map from the old URL to the new URL? This should be easy for all JIRA issues migrated to github issues, because the issue ID was preserved in github. Many JIRA issues are also referenced from SCM commits and it's not easy to find the issue information now. Also, project pages should be rather easy to redirect - e.g. grizzly.java.net to grizzly.github.io and the same for glassfish once the page is migrated to glassfish.github.io. It's a pity that the content is (or will be) there, but old links won't work for it. I hope this can be sorted out in the future, otherwise Java EE will become very confusing for developers with all those broken links all over the internet. The is damaging even now and the current state will become catastrophic and unreversible for Java EE in a longer term if not mitigated. --Ondro Started by Ondro Mihályi @ |
| Application Client and Security 1.0? 3 Hi, Looking at Figure EE.2-1 and I see that Security 1.0 is listed as part of the Application Client. I knew about the discussion to include Security 1.0 in the Web Profile. I was not aware of it being included in the App Client. I don't know if I have strong opinions one way or the other on this one... But, if it is meant to be included in the App Client, then don't we also have to include JASPIC in the app client (due to the dependency of Security on JASPIC)? Was the inclusion of Security in the App Client discussed and I missed it? In any case, an update to the Figure will be required to get the App Client definition properly updated. Is this Figure the only location where the specific content of the App Client is defined? Thanks, Kevin Started by Kevin Sutter @ · Most recent @ |
| Location of downloadable files? 7 Hi Linda, Where can we get access to downloadable files? The current groups.io repo doesn't have any files (https://javaee.groups.io/g/javaee-spec/files). And, if I try to go to our old repo on java.net (https://java.net/projects/javaee-spec/downloads), we are no longer allowed access. Not only am I interested in the early drafts of the Java EE 8 specs, javadocs, schemas, etc, but also the older versions. Thanks, Kevin Started by Kevin Sutter @ · Most recent @ |
| Where are we discussing the Interceptor spec? 3 Hi, Are we discussing the updated Interceptor spec here? I know we had some discussions related to this update on the Java EE mailing list, but since it was released as part of the EJB family of specs, should we comment on the EJB mailing list? I ran this update past our CDI EG member and she discussed it with the wider Weld community (RI). It sounds like there is an issue with CDI and some of the proposed updates. Weld opened the following spec issue, but I thought it would be good to post to it to the wider community to ensure that everybody can discuss it. https://github.com/javaee/interceptors-spec/issues/33 Maybe I'm doing that just be posting this message? :-) Thanks, Kevin Started by Kevin Sutter @ · Most recent @ |
| Java EE 8 - Release Date Hi Linda/All, Hope all is well. Earlier this week, Mark Reinhold posted an email proposing to move the release date of JDK 9 back to September 21 (http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html). As such, do you believe that the proposed delay would have any impact on the release date of Java EE 8? Since Java EE 8 is going to align with Java SE 8, I imagine that there should be no major technical impact if Java EE 8 were released prior to Java SE 9, but I'm just not certain of Oracle's release plan. Thanks for your time and insight, it is appreciated. Thanks Josh Juneau juneau001@... Started by Josh Juneau @ |
| Java EE 9? 4 Hi, During last JavaOne I somewhat got the impression (but may have interpreted it wrongly), that the work for Java EE 9 would more or less start in parallel with finalising Java EE 8. Since Java EE 8 is now being being finalised, I wonder what the Java EE 9 plans are at this moment. If it's indeed to be released in about a year after the Java EE 8 release, then shouldn't some JSRs start pretty soon now? Kind regards, Arjan Tijms Started by Arjan Tijms @ · Most recent @ |
| Java EE tutorial sources Hi, The new Java EE site states the tutorial sources have been archived [1]. Github really simplifies contributions over the old java.net site, and I the tutorial is a very valuable piece of the Java EE ecosystem. It may well benefit from community contributions. Could its sources please be made available again? I've cc'ed the EE spec mailing list to get some more visibility. Regards, Guillermo González de Agüero [1] https://javaee.github.io/other-migrated-projects.html Started by Guillermo González de Agüero @ |
| Welcome to the new JSR 366 mailing list 2 Welcome to the new JSR 366 mailing list! This list replaces the Java EE Expert Group mailing lists that were previously hosted on java.net. This is now a single mailing list which includes both experts and users. Our transition from java.net has thus far gone remarkably smoothly, and is expected to result in only a very minimal delay from our previously announced completion target of July. All but one of our Java EE 8 component JSRs are now at the Public Review stage or later, and all but one of our targeted MRs have been posted for review or completed. Among the most recent accomplishments are the Final Releases of JSON-P 1.1 and CDI 2.0, and the submission of JPA and JavaMail for Maintenance Review. The Java EE Security API spec will appear shortly for Public Review and the Interceptors spec for Maintenance Review. The Java EE 8 Platform and the Bean Validation specs will begin their Public Review Ballot phase next week. regards, -Linda Started by Linda DeMichiel @ · Most recent @ |
| Java EE 8 PR review 2 Hi Linda and Bill, Trying out this new javaee.groups.io mailing list... I don't see any existing messages yet, so it's been pretty quiet... I just finished reviewing the PR drafts for the Platform and Web Profile Java EE 8 specifications. Looks good. Not a lot of changes since the EDR2, mainly clean up. A couple of items though... o You still have references to Java Batch 1.1 MR in the TOC, Table EE.6-1, and Section EE.6.18. I know we talked about an MR for Java Batch, but that never became real. So, these references should be reverted to Java Batch 1.0. (BTW, section EE.9.7 is okay. You missed that one.) o I'm still not thrilled with the new dependency on JASPIC for Security 1.0 and, in turn, the Web Profile. I know we already talked about this in the mailing lists and my concern was overruled by the majority, so I'll live with it. But, it still seems kind of backward to require this archaic spec in the Web Profile. (I'll brace myself for the hate mail on that remark. Smile.) Other than that, it looks good. Thanks! Kevin Started by Kevin Sutter @ · Most recent @ |
Image Name
Sat 8:39am