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
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
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
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
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
> >
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
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
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
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
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
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
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
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
13 matches
Mail list logo
