Hi, Yes, all or almost all projects will go for rename-only indeed. For Faces we had started too with new features, but will explicitly exclude those. Security and its foundational specs will do

If most other projects are making their EE9 release a rename only release, then I think that servlet-api should follow and not try to be special. However, it will be a hassle for vendors managing

Hi, My understanding is that if we absolutely want, we can. But then we do have to diverge from the EE 9 release plan and create our own plan (and engage in review for that etc). As we can followup

Dear ee spec group. The servlet-api project is trying to come up with our project plan for our 5.0 and 5.1 releases. The 5.0 release will be our javax->jakarta rename release and the key question we

Please be aware that this repository has been archived as this project is now part of the EE4J initiative. All activities are now happening in the corresponding Eclipse repository

Hi, I don't see an application of MR to EAR, but EARs don't package classes directly, so that seems natural. (But are there any resource loading cases for EAR files?) Reasons that I'm finding that

I agree with Mark, I don't believe that MR behaviour should necessarily apply to WAR and EAR files. Sure if you give war file to a java9 ClassLoader, it will happily version WEB-INF/web.xml. However

My starting position is the opposite. The summary in JEP 238 starts: "Extend the JAR file format to allow multiple, Java-release-specific versions of class files to coexist in a single

Hi, Looking over the JEP238 and JavaDoc, the focus is on resource lookup. I don't see any behavior which distinguishes a class type resource from a non-class type resource. Once a resource is

Hi, I've just discovered that the archives for this list (and the other Java EE lists) before it was migrated from java.net to a Google group may be found

All, I've had a conversations regarding this issue on jigsaw-dev and core-libs-dev. While there was some acknowledgement that the JarFile API is incomplete regarding support for Multi Release jars,

Likewise. We (Tomcat) haven't had any reports of problems in this area yet. It is on the list of things to worry about (and thanks for setting out the problems so clearly) but we haven't looked at a

All, We are a bit concerned with providing reasonable support for annotation scanning in java 9 multi version jars. We are already seeing these jars in our java 8 deployments (from some logging

Congratulations! -- http://ensode.net - A Guide to Java, Linux and Other Technology Topics My Books: http://www.packtpub.com/authors/profiles/david-heffelfinger My Video Training:

Very nice! Congrats to everyone involved, and additionally a big thanks for listening to the feedback from the community :)

Hello Volunteers, We are happy to report that we passed Final Approval Ballot with all yes votes, no abstains, and one non-vote. It has been an honor and a privilige to work with you all on

EB> Due to one final TCK change and a small spec wording change we had to EB> delay handing the FAB to JCP by one week. The revised schedule is: EB> 2017-07-25 Hand FAB materials to JCP EB>

Hello Volunteers, Due to one final TCK change and a small spec wording change we had to delay handing the FAB to JCP by one week. The revised schedule is: 2017-07-25 Hand FAB materials to

Hello Experts, In Servlet 3.1, one can reference the ejb in web.xml. The intent of section 8.1 is to enumerate the annotations for which there is corresponding XML syntax. EJB and EJBS were

Hello Experts, More refinement for the text from the TCK team. I suggest we add the following advisory text, which we agreed in one of the previous EG discussion, at the end of the description of