Jakarta package change
Hi, Background information: https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ So this is obviously a large breaking change. While there are plenty of options, there is a simple one too: - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the APIs in Tomcat 9 can remain javax.* and users with "old" applications will still have an up to date fully compatible container for them. - Have a Tomcat 10 with all API packages renamed to jakarta.*, which would provide a container for users who want to move to the new "incompatible" Jakarta specifications. This way, there's an appropriate container for everyone. Mark Struberg proposed more elaborate strategies using classloader tricks on the ASF members list, but I'm not sure this is even needed for Tomcat. Overall, the impact for Tomcat seems rather minimal given the maturity of Tomcat and its expected support lifecycle for 9.x. Comments ? Rémy
Re: Jakarta package change
Le 07/05/2019 à 09:05, Rémy Maucherat a écrit : > - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the > APIs in Tomcat 9 can remain javax.* and users with "old" applications will > still have an up to date fully compatible container for them. +1 > - Have a Tomcat 10 with all API packages renamed to jakarta.*, which would > provide a container for users who want to move to the new "incompatible" > Jakarta specifications. +1 for deferring the package changes to Tomcat 10. The actual impact isn't clear though, the specifications may evolve in a way that maintains a form of backward compatibility as outlined by Mark Struberg (for example jakarta.* classes the extending javax.* ones). It's a bit early to know how this could be handled in Tomcat 10. Once we know how the specs will evolve, I suggest releasing a prototype as soon as possible so everyone can start experimenting with the new namespace. The return of Jakarta Tomcat ;) I wonder if the specifications could be slightly refactored in the process to erase some mistakes, for example renaming ServletRequest.getContentLengthLong() to getContentLength(). The package change could be a great opportunity to tidy up the APIs. > This way, there's an appropriate container for everyone. Mark Struberg > proposed more elaborate strategies using classloader tricks on the ASF > members list, but I'm not sure this is even needed for Tomcat. Would such a classloader work with a native application using GraalVM ? If not I guess we'll rather see build time tools doing the bytecode processing than runtime tools. In this case the actual conversion would indeed be out of scope for Tomcat. > Comments ? Not really happy to waste so much time for a silly trademark policy... Let's hope Oracle's lawyers don't impose the same mess to OpenJDK someday. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
On 07/05/2019 08:05, Rémy Maucherat wrote: > Hi, > > Background information: > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > > So this is obviously a large breaking change. While there are plenty of > options, there is a simple one too: > - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the > APIs in Tomcat 9 can remain javax.* and users with "old" applications will > still have an up to date fully compatible container for them. > - Have a Tomcat 10 with all API packages renamed to jakarta.*, which would > provide a container for users who want to move to the new "incompatible" > Jakarta specifications. > > This way, there's an appropriate container for everyone. Mark Struberg > proposed more elaborate strategies using classloader tricks on the ASF > members list, but I'm not sure this is even needed for Tomcat. > > Overall, the impact for Tomcat seems rather minimal given the maturity of > Tomcat and its expected support lifecycle for 9.x. > > Comments ? I think it is good we are thinking about options but too early to settle on any one solution. The solution we adopt is going to be largely dependent on what the API projects at Eclipse decide to do. Rather than announcing a solution, how about we announce that we will continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that means supporting all the older versions of those specs as well. Exactly how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is just one possible option. Mark * Insert date of choice here. I picked first Tomcat 9 release + 10 years for typical support period + 5 years extension and rounded to the end of the year. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
On Tue, May 7, 2019 at 10:31 AM Emmanuel Bourg wrote: > Le 07/05/2019 à 09:05, Rémy Maucherat a écrit : > > > - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the > > APIs in Tomcat 9 can remain javax.* and users with "old" applications > will > > still have an up to date fully compatible container for them. > > +1 > > > - Have a Tomcat 10 with all API packages renamed to jakarta.*, which > would > > provide a container for users who want to move to the new "incompatible" > > Jakarta specifications. > > +1 for deferring the package changes to Tomcat 10. > > The actual impact isn't clear though, the specifications may evolve in a > way that maintains a form of backward compatibility as outlined by Mark > Struberg (for example jakarta.* classes the extending javax.* ones). > It's a bit early to know how this could be handled in Tomcat 10. > > Once we know how the specs will evolve, I suggest releasing a prototype > as soon as possible so everyone can start experimenting with the new > namespace. The return of Jakarta Tomcat ;) > > I wonder if the specifications could be slightly refactored in the > process to erase some mistakes, for example renaming > ServletRequest.getContentLengthLong() to getContentLength(). The package > change could be a great opportunity to tidy up the APIs. > That could be good. So we'll see. > > > > This way, there's an appropriate container for everyone. Mark Struberg > > proposed more elaborate strategies using classloader tricks on the ASF > > members list, but I'm not sure this is even needed for Tomcat. > > Would such a classloader work with a native application using GraalVM ? > If not I guess we'll rather see build time tools doing the bytecode > processing than runtime tools. In this case the actual conversion would > indeed be out of scope for Tomcat. > It is unlikely classloader tricks are Graal compatible. You are right this can be a real issue in the future. > > > > Comments ? > > Not really happy to waste so much time for a silly trademark policy... > Let's hope Oracle's lawyers don't impose the same mess to OpenJDK someday. > +1 Rémy
Re: Jakarta package change
On Tue, May 7, 2019 at 12:31 PM Mark Thomas wrote: > On 07/05/2019 08:05, Rémy Maucherat wrote: > > Hi, > > > > Background information: > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > > > > So this is obviously a large breaking change. While there are plenty of > > options, there is a simple one too: > > - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the > > APIs in Tomcat 9 can remain javax.* and users with "old" applications > will > > still have an up to date fully compatible container for them. > > - Have a Tomcat 10 with all API packages renamed to jakarta.*, which > would > > provide a container for users who want to move to the new "incompatible" > > Jakarta specifications. > > > > This way, there's an appropriate container for everyone. Mark Struberg > > proposed more elaborate strategies using classloader tricks on the ASF > > members list, but I'm not sure this is even needed for Tomcat. > > > > Overall, the impact for Tomcat seems rather minimal given the maturity of > > Tomcat and its expected support lifecycle for 9.x. > > > > Comments ? > > I think it is good we are thinking about options but too early to settle > on any one solution. The solution we adopt is going to be largely > dependent on what the API projects at Eclipse decide to do. > > Rather than announcing a solution, how about we announce that we will > I agree, it is too early to decide and announce. Still, discussion is fine (IMO) and unless the announced Jakarta change ends up not happening. We'll indeed see what happens at Jakarta. > continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, > WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that > means supporting all the older versions of those specs as well. Exactly > how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is > just one possible option. > +1, I was also thinking about "2030 at least" when I wrote "forever" because it makes for a nice impressive announcement ! > > Mark > > * Insert date of choice here. I picked first Tomcat 9 release + 10 years > for typical support period + 5 years extension and rounded to the end of > the year. > Rémy
[tomcat] branch master updated: Restore normal logging level
This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new e5c56fc Restore normal logging level e5c56fc is described below commit e5c56fc9a98c02cc0d36fe75bfdc246b47774e33 Author: remm AuthorDate: Tue May 7 14:28:59 2019 +0200 Restore normal logging level --- conf/logging.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/logging.properties b/conf/logging.properties index fc52083..e8b7b16 100644 --- a/conf/logging.properties +++ b/conf/logging.properties @@ -73,7 +73,7 @@ org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].ha #org.apache.jasper.compiler.TldLocationsCache.level = FINE # To see debug messages for HTTP/2 handling, uncomment the following line: -org.apache.coyote.http2.level = FINE +#org.apache.coyote.http2.level = FINE # To see debug messages for WebSocket handling, uncomment the following line: #org.apache.tomcat.websocket.level = FINE - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Fix Graal VM check as it is static
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 2ccf1e3 Fix Graal VM check as it is static
2ccf1e3 is described below
commit 2ccf1e3ac4a40e344e7c249f2486ed4cf4076509
Author: remm
AuthorDate: Tue May 7 16:29:25 2019 +0200
Fix Graal VM check as it is static
---
java/org/apache/tomcat/util/compat/GraalCompat.java | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java
b/java/org/apache/tomcat/util/compat/GraalCompat.java
index 0ad3a40..f6a7fce 100644
--- a/java/org/apache/tomcat/util/compat/GraalCompat.java
+++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
@@ -23,7 +23,8 @@ class GraalCompat extends JreCompat {
private static final boolean GRAAL;
static {
-GRAAL = (System.getProperty("java.runtime.version") == null);
+String runtime = System.getProperty("java.runtime.version");
+GRAAL = (runtime != null && (runtime.indexOf(".buildslave.jdk8u") !=
-1));
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
Hi folks! Yes, I'm right now playing with it. For a little more background and overview I've written up a blog post: https://struberg.wordpress.com/2019/05/06/the-way-forward-for-jakartaee-packages/ I've also already started to migrate a few spec packages. The current work in progress is available here: https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ I've already test-migrated over Apache OpenWebBeans CDI container. Of course with TCK and servlet integration disabled for now as Arquillian and Tomcat first needs to be ported. https://github.com/struberg/openwebbeans/tree/jakarta I'm right now tinkering with Tomcat. And boy, tomcat has way more dependencies than I'd like. And it would help if it would finally be migrated to use Maven, but I spare you that ;) As soon as I've something decently working then I'll share! LieGrue, strub > Am 07.05.2019 um 14:09 schrieb Rémy Maucherat : > > On Tue, May 7, 2019 at 12:31 PM Mark Thomas wrote: > >> On 07/05/2019 08:05, Rémy Maucherat wrote: >>> Hi, >>> >>> Background information: >>> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ >>> >>> So this is obviously a large breaking change. While there are plenty of >>> options, there is a simple one too: >>> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all the >>> APIs in Tomcat 9 can remain javax.* and users with "old" applications >> will >>> still have an up to date fully compatible container for them. >>> - Have a Tomcat 10 with all API packages renamed to jakarta.*, which >> would >>> provide a container for users who want to move to the new "incompatible" >>> Jakarta specifications. >>> >>> This way, there's an appropriate container for everyone. Mark Struberg >>> proposed more elaborate strategies using classloader tricks on the ASF >>> members list, but I'm not sure this is even needed for Tomcat. >>> >>> Overall, the impact for Tomcat seems rather minimal given the maturity of >>> Tomcat and its expected support lifecycle for 9.x. >>> >>> Comments ? >> >> I think it is good we are thinking about options but too early to settle >> on any one solution. The solution we adopt is going to be largely >> dependent on what the API projects at Eclipse decide to do. >> >> Rather than announcing a solution, how about we announce that we will >> > > I agree, it is too early to decide and announce. Still, discussion is fine > (IMO) and unless the announced Jakarta change ends up not happening. We'll > indeed see what happens at Jakarta. > > >> continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, >> WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that >> means supporting all the older versions of those specs as well. Exactly >> how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is >> just one possible option. >> > > +1, I was also thinking about "2030 at least" when I wrote "forever" > because it makes for a nice impressive announcement ! > > >> >> Mark >> >> * Insert date of choice here. I picked first Tomcat 9 release + 10 years >> for typical support period + 5 years extension and rounded to the end of >> the year. >> > > Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
I agree with the 2030 statement but it also means not replacing javax by jakarta is saner because it avoids to duplicate and make ambiguous the API and also reduce maintenance cost. It also keeps tomcat embedded working - classloader hacks or javaagent can be tricky to keep performing well with recent java versions. Any servlet evolution under the radar? Anything not doable already or are we fighting ghosts? Le mar. 7 mai 2019 à 19:33, Mark Struberg a écrit : > Hi folks! > > Yes, I'm right now playing with it. > For a little more background and overview I've written up a blog post: > > https://struberg.wordpress.com/2019/05/06/the-way-forward-for-jakartaee-packages/ > > I've also already started to migrate a few spec packages. > The current work in progress is available here: > https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ > > I've already test-migrated over Apache OpenWebBeans CDI container. > Of course with TCK and servlet integration disabled for now as Arquillian > and Tomcat first needs to be ported. > https://github.com/struberg/openwebbeans/tree/jakarta > > I'm right now tinkering with Tomcat. > And boy, tomcat has way more dependencies than I'd like. > And it would help if it would finally be migrated to use Maven, but I > spare you that ;) > > As soon as I've something decently working then I'll share! > > LieGrue, > strub > > > Am 07.05.2019 um 14:09 schrieb Rémy Maucherat : > > > > On Tue, May 7, 2019 at 12:31 PM Mark Thomas wrote: > > > >> On 07/05/2019 08:05, Rémy Maucherat wrote: > >>> Hi, > >>> > >>> Background information: > >>> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > >>> > >>> So this is obviously a large breaking change. While there are plenty of > >>> options, there is a simple one too: > >>> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all > the > >>> APIs in Tomcat 9 can remain javax.* and users with "old" applications > >> will > >>> still have an up to date fully compatible container for them. > >>> - Have a Tomcat 10 with all API packages renamed to jakarta.*, which > >> would > >>> provide a container for users who want to move to the new > "incompatible" > >>> Jakarta specifications. > >>> > >>> This way, there's an appropriate container for everyone. Mark Struberg > >>> proposed more elaborate strategies using classloader tricks on the ASF > >>> members list, but I'm not sure this is even needed for Tomcat. > >>> > >>> Overall, the impact for Tomcat seems rather minimal given the maturity > of > >>> Tomcat and its expected support lifecycle for 9.x. > >>> > >>> Comments ? > >> > >> I think it is good we are thinking about options but too early to settle > >> on any one solution. The solution we adopt is going to be largely > >> dependent on what the API projects at Eclipse decide to do. > >> > >> Rather than announcing a solution, how about we announce that we will > >> > > > > I agree, it is too early to decide and announce. Still, discussion is > fine > > (IMO) and unless the announced Jakarta change ends up not happening. > We'll > > indeed see what happens at Jakarta. > > > > > >> continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, > >> WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that > >> means supporting all the older versions of those specs as well. Exactly > >> how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is > >> just one possible option. > >> > > > > +1, I was also thinking about "2030 at least" when I wrote "forever" > > because it makes for a nice impressive announcement ! > > > > > >> > >> Mark > >> > >> * Insert date of choice here. I picked first Tomcat 9 release + 10 years > >> for typical support period + 5 years extension and rounded to the end of > >> the year. > >> > > > > Rémy > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Jakarta package change
On Tue, May 7, 2019 at 7:33 PM Mark Struberg wrote: > Hi folks! > > Yes, I'm right now playing with it. > For a little more background and overview I've written up a blog post: > > https://struberg.wordpress.com/2019/05/06/the-way-forward-for-jakartaee-packages/ > > I've also already started to migrate a few spec packages. > The current work in progress is available here: > https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ > > I've already test-migrated over Apache OpenWebBeans CDI container. > Of course with TCK and servlet integration disabled for now as Arquillian > and Tomcat first needs to be ported. > https://github.com/struberg/openwebbeans/tree/jakarta > > I'm right now tinkering with Tomcat. > And boy, tomcat has way more dependencies than I'd like. > And it would help if it would finally be migrated to use Maven, but I > spare you that ;) > > As soon as I've something decently working then I'll share! > Just so that things are clear, I think I am against any jakarta.* related changes in Tomcat 9. It will stay on JakartaEE 8 no matter what, so it can use javax.* and it should stay that way since this means guaranteed zero impact for users. As is customary, the next major Tomcat version would however have support for the next relevant specifications, so that in turn would have to be jakarta.* (unless things change). I am not so sure this next version would need dual support at all, but this is completely undecided at this point. And I agree with Mark (T) that there are too many unknowns and it's too early to make a decision. Rémy > > LieGrue, > strub > > > Am 07.05.2019 um 14:09 schrieb Rémy Maucherat : > > > > On Tue, May 7, 2019 at 12:31 PM Mark Thomas wrote: > > > >> On 07/05/2019 08:05, Rémy Maucherat wrote: > >>> Hi, > >>> > >>> Background information: > >>> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > >>> > >>> So this is obviously a large breaking change. While there are plenty of > >>> options, there is a simple one too: > >>> - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all > the > >>> APIs in Tomcat 9 can remain javax.* and users with "old" applications > >> will > >>> still have an up to date fully compatible container for them. > >>> - Have a Tomcat 10 with all API packages renamed to jakarta.*, which > >> would > >>> provide a container for users who want to move to the new > "incompatible" > >>> Jakarta specifications. > >>> > >>> This way, there's an appropriate container for everyone. Mark Struberg > >>> proposed more elaborate strategies using classloader tricks on the ASF > >>> members list, but I'm not sure this is even needed for Tomcat. > >>> > >>> Overall, the impact for Tomcat seems rather minimal given the maturity > of > >>> Tomcat and its expected support lifecycle for 9.x. > >>> > >>> Comments ? > >> > >> I think it is good we are thinking about options but too early to settle > >> on any one solution. The solution we adopt is going to be largely > >> dependent on what the API projects at Eclipse decide to do. > >> > >> Rather than announcing a solution, how about we announce that we will > >> > > > > I agree, it is too early to decide and announce. Still, discussion is > fine > > (IMO) and unless the announced Jakarta change ends up not happening. > We'll > > indeed see what happens at Jakarta. > > > > > >> continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, > >> WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that > >> means supporting all the older versions of those specs as well. Exactly > >> how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is > >> just one possible option. > >> > > > > +1, I was also thinking about "2030 at least" when I wrote "forever" > > because it makes for a nice impressive announcement ! > > > > > >> > >> Mark > >> > >> * Insert date of choice here. I picked first Tomcat 9 release + 10 years > >> for typical support period + 5 years extension and rounded to the end of > >> the year. > >> > > > > Rémy > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[tomcat] branch master updated: Use the Graal API
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new e6c8f8a Use the Graal API
e6c8f8a is described below
commit e6c8f8ac932750f05a767084b85b11b4b8a5f490
Author: remm
AuthorDate: Tue May 7 21:00:01 2019 +0200
Use the Graal API
Also update instructions.
---
java/org/apache/tomcat/util/compat/GraalCompat.java | 12 ++--
res/tomcat-maven/README.md | 8 +---
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/java/org/apache/tomcat/util/compat/GraalCompat.java
b/java/org/apache/tomcat/util/compat/GraalCompat.java
index f6a7fce..f6636c7 100644
--- a/java/org/apache/tomcat/util/compat/GraalCompat.java
+++ b/java/org/apache/tomcat/util/compat/GraalCompat.java
@@ -23,8 +23,16 @@ class GraalCompat extends JreCompat {
private static final boolean GRAAL;
static {
-String runtime = System.getProperty("java.runtime.version");
-GRAAL = (runtime != null && (runtime.indexOf(".buildslave.jdk8u") !=
-1));
+boolean result = false;
+try {
+Class nativeImageClazz =
Class.forName("org.graalvm.nativeimage");
+result = (nativeImageClazz.getMethod("inImageCode").invoke(null)
== Boolean.TRUE);
+} catch (ClassNotFoundException e) {
+// Must be Java 8
+} catch (ReflectiveOperationException | IllegalArgumentException e) {
+// Should never happen
+}
+GRAAL = result;
}
diff --git a/res/tomcat-maven/README.md b/res/tomcat-maven/README.md
index 12389a2..095c3fd 100644
--- a/res/tomcat-maven/README.md
+++ b/res/tomcat-maven/README.md
@@ -96,7 +96,9 @@ Then exercise necessary paths of your service with the Tomcat
configuration.
Generate the final json using native-image-configuration then use native image
using the generated reflection metadata.
```
-cd target
-$JAVA_HOME/jre/tools/native-image-configure/native-image-configure generate
--trace-input=trace-file.json --output-dir=.
-$JAVA_HOME/bin/native-image -H:+ReportUnsupportedElementsAtRuntime
-H:ConfigurationFileDirectories=./
-H:ReflectionConfigurationFiles=../tomcat-reflection.json -jar
tomcat-maven-1.0.jar
+$JAVA_HOME/jre/tools/native-image-configure/native-image-configure generate
--trace-input=./target/trace-file.json --output-dir=./target
+$JAVA_HOME/bin/native-image -H:+ReportUnsupportedElementsAtRuntime
-H:ConfigurationFileDirectories=./target/
-H:ReflectionConfigurationFiles=./tomcat-reflection.json -jar
target/tomcat-maven-1.0.jar
+./tomcat-maven-1.0 -Dcatalina.base=.
-Djava.util.logging.config.file=conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
```
+Note: -H:ConfigurationFileDirectories does not appear to work properly, so it
could be needed to add the content of reflect-config.json
+ to tomcat-reflection.json.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Jakarta package change
Yes, the first step is just trying out what we could have missed. And of course this would be tc-10. The first quick and dirty hack is alive: https://github.com/struberg/tomcat/tree/jakarta You first need to compile the geronimo-jakarta specs locally from https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ Then (don't slap me!) you have to run a mvn clean install in tomcat. This will just fire up the dependency resolution for those jakarta specs missing and copy them to target/dependency/*.jar Then run a standard ant There are really dirty parts in the change. mostly around everything XAResource related. Like LocalXAConnectionFactory and DataSourceXAConnectionFactory. Attention: I'm totally tired already and I've not run any tests yet. But at least it compiles again. have fun! LieGrue, strub > Am 07.05.2019 um 20:38 schrieb Rémy Maucherat : > > On Tue, May 7, 2019 at 7:33 PM Mark Struberg > wrote: > >> Hi folks! >> >> Yes, I'm right now playing with it. >> For a little more background and overview I've written up a blog post: >> >> https://struberg.wordpress.com/2019/05/06/the-way-forward-for-jakartaee-packages/ >> >> I've also already started to migrate a few spec packages. >> The current work in progress is available here: >> https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ >> >> I've already test-migrated over Apache OpenWebBeans CDI container. >> Of course with TCK and servlet integration disabled for now as Arquillian >> and Tomcat first needs to be ported. >> https://github.com/struberg/openwebbeans/tree/jakarta >> >> I'm right now tinkering with Tomcat. >> And boy, tomcat has way more dependencies than I'd like. >> And it would help if it would finally be migrated to use Maven, but I >> spare you that ;) >> >> As soon as I've something decently working then I'll share! >> > > Just so that things are clear, I think I am against any jakarta.* related > changes in Tomcat 9. It will stay on JakartaEE 8 no matter what, so it can > use javax.* and it should stay that way since this means guaranteed zero > impact for users. As is customary, the next major Tomcat version would > however have support for the next relevant specifications, so that in turn > would have to be jakarta.* (unless things change). I am not so sure this > next version would need dual support at all, but this is completely > undecided at this point. And I agree with Mark (T) that there are too many > unknowns and it's too early to make a decision. > > Rémy > > >> >> LieGrue, >> strub >> >>> Am 07.05.2019 um 14:09 schrieb Rémy Maucherat : >>> >>> On Tue, May 7, 2019 at 12:31 PM Mark Thomas wrote: >>> On 07/05/2019 08:05, Rémy Maucherat wrote: > Hi, > > Background information: > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > > So this is obviously a large breaking change. While there are plenty of > options, there is a simple one too: > - Maintain a Tomcat 9.x "forever" with Servlet 4.0. As a result, all >> the > APIs in Tomcat 9 can remain javax.* and users with "old" applications will > still have an up to date fully compatible container for them. > - Have a Tomcat 10 with all API packages renamed to jakarta.*, which would > provide a container for users who want to move to the new >> "incompatible" > Jakarta specifications. > > This way, there's an appropriate container for everyone. Mark Struberg > proposed more elaborate strategies using classloader tricks on the ASF > members list, but I'm not sure this is even needed for Tomcat. > > Overall, the impact for Tomcat seems rather minimal given the maturity >> of > Tomcat and its expected support lifecycle for 9.x. > > Comments ? I think it is good we are thinking about options but too early to settle on any one solution. The solution we adopt is going to be largely dependent on what the API projects at Eclipse decide to do. Rather than announcing a solution, how about we announce that we will >>> >>> I agree, it is too early to decide and announce. Still, discussion is >> fine >>> (IMO) and unless the announced Jakarta change ends up not happening. >> We'll >>> indeed see what happens at Jakarta. >>> >>> continue to support the javax.* APIS (Servlet 4.0, JSP 2.3, EL 3.0, WebSocket 1.1 and JASPIC 1.1) until at least 31 Dec 2030*. Note: that means supporting all the older versions of those specs as well. Exactly how we do that is TBD. Extending Tomcat 9 support to the end of 2030 is just one possible option. >>> >>> +1, I was also thinking about "2030 at least" when I wrote "forever" >>> because it makes for a nice impressive announcement ! >>> >>> Mark * Insert date of choice here. I picked first Tomcat 9 release + 10 years for typical support period + 5 years extension and rounded to the en
[tomcat] branch master updated: Avoid useless exception wrapping in async IO
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 256e9a0 Avoid useless exception wrapping in async IO
256e9a0 is described below
commit 256e9a03005fa421a1924d0d33942436c5ca20e5
Author: remm
AuthorDate: Wed May 8 00:36:50 2019 +0200
Avoid useless exception wrapping in async IO
---
java/org/apache/coyote/http2/Http2AsyncParser.java | 2 ++
java/org/apache/tomcat/util/net/Nio2Endpoint.java | 7 +++
java/org/apache/tomcat/util/net/NioEndpoint.java | 7 +++
webapps/docs/changelog.xml | 3 +++
4 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/java/org/apache/coyote/http2/Http2AsyncParser.java
b/java/org/apache/coyote/http2/Http2AsyncParser.java
index 92bf09f..827105a 100644
--- a/java/org/apache/coyote/http2/Http2AsyncParser.java
+++ b/java/org/apache/coyote/http2/Http2AsyncParser.java
@@ -152,6 +152,8 @@ class Http2AsyncParser extends Http2Parser {
throw (Http2Exception) error;
} else if (error instanceof IOException) {
throw (IOException) error;
+} else if (error instanceof RuntimeException) {
+throw (RuntimeException) error;
} else {
throw new RuntimeException(error);
}
diff --git a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
index 815713a..a4844bc 100644
--- a/java/org/apache/tomcat/util/net/Nio2Endpoint.java
+++ b/java/org/apache/tomcat/util/net/Nio2Endpoint.java
@@ -1189,13 +1189,12 @@ public class Nio2Endpoint extends
AbstractJsseEndpoint state) {
-IOException ioe;
+IOException ioe = null;
if (exc instanceof InterruptedByTimeoutException) {
ioe = new SocketTimeoutException();
+exc = ioe;
} else if (exc instanceof IOException) {
ioe = (IOException) exc;
-} else {
-ioe = new IOException(exc);
}
setError(ioe);
boolean notify = false;
@@ -1206,7 +1205,7 @@ public class Nio2Endpoint extends
AbstractJsseEndpoint
}
@Override
public void failed(Throwable exc, OperationState state) {
-IOException ioe;
+IOException ioe = null;
if (exc instanceof InterruptedByTimeoutException) {
ioe = new SocketTimeoutException();
+exc = ioe;
} else if (exc instanceof IOException) {
ioe = (IOException) exc;
-} else {
-ioe = new IOException(exc);
}
setError(ioe);
boolean notify = false;
@@ -1785,7 +1784,7 @@ public class NioEndpoint extends
AbstractJsseEndpoint
state.state = state.inline ? CompletionState.ERROR :
CompletionState.DONE;
}
if (state.handler != null) {
-state.handler.failed(ioe, state.attachment);
+state.handler.failed(exc, state.attachment);
}
synchronized (state) {
state.completionDone = true;
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index be3a473..1a2085c 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -77,6 +77,9 @@
63403: Fix TestHttp2InitialConnection test failures when
running with a non-English locale. (kkolinko)
+
+Avoid useless exception wrapping in async IO. (remm)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
