You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Adam Rauch <ad...@labkey.com> on 2019/12/21 06:36:35 UTC
javax -> jakarta rename
I've watched with great interest the recent list discussions surrounding
javax -> jakarta renaming and the draft release numbering plan. I'm
curious: Would the Tomcat team consider making a Tomcat release that
supports BOTH the javax and jakarta package names?
Please hear me out before dismissing this as completely insane. Shortly
after Mark published his Tomcat "jakarta" branch, I built it and fired
up our very large webapp (LabKey Server). Of course, it didn't run,
given it was compiled against the javax API (I see approximately 25,000
references to javax.servlet.* in our code). As an experiment, I then
built a jar that restores javax.* implementation classes that we care
about and added some new classes that adapt the jakarta packaged objects
coming from Tomcat to the javax packaged objects that our webapp
expects. I dropped that jar into <tomcat>/lib, without touching any
Tomcat or LabKey code, and our webapp started up, with Filters initing
and filtering, Servlets servicing, requests being served, pages
rendering, etc. The work is incomplete (e.g., most of our pre-compiled
JSPs were unhappy with this initial attempt... though I have ideas
there), but it provides a reasonable proof of concept, IMO. You can
inspect the prototype layer here:
https://github.com/labkey-adam/jakarta-javax
Why bother offering a Tomcat release that supports both package names?
To provide a much needed transition option for those who deploy Tomcat
webapps. I'm not particularly concerned about my team's development
effort to accommodate the rename (search & replace, upgrade Spring and
other dependencies). I'm much more concerned about the hundreds of
organizations that deploy our webapp. As we've transitioned our clients
through all previous Tomcat upgrades, we've never required a
simultaneous upgrade of both Tomcat and LabKey; we've always offered
them the ability to upgrade our product and its dependencies
independently, over the course of months or even years. A major Tomcat
release upgrade may be a fairly trivial task to you and me, but it's a
very big deal to the research organizations that use our system,
particularly given their need to adhere to strict healthcare compliance
regulations and validation procedures.
I'd be curious to hear if other developers have concerns about their
customers' ability to make this transition and if there's interest in
exploring a dual-package release (or sanctioned add-on). I'd be happy to
help with the development and testing of such a solution.
Thanks,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: javax -> jakarta rename
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Adam,
Did you evaluate a class transformer added to tomcat classloader?
This can stay quite light and enables the same while not using app loader -
standard tomcat mode. For app loader case integrations can do the work
easily (spring and friends) since they all have asm or equivalent.
Hope it makes sense.
Le sam. 21 déc. 2019 à 07:36, Adam Rauch <ad...@labkey.com> a écrit :
> I've watched with great interest the recent list discussions surrounding
> javax -> jakarta renaming and the draft release numbering plan. I'm
> curious: Would the Tomcat team consider making a Tomcat release that
> supports BOTH the javax and jakarta package names?
>
> Please hear me out before dismissing this as completely insane. Shortly
> after Mark published his Tomcat "jakarta" branch, I built it and fired
> up our very large webapp (LabKey Server). Of course, it didn't run,
> given it was compiled against the javax API (I see approximately 25,000
> references to javax.servlet.* in our code). As an experiment, I then
> built a jar that restores javax.* implementation classes that we care
> about and added some new classes that adapt the jakarta packaged objects
> coming from Tomcat to the javax packaged objects that our webapp
> expects. I dropped that jar into <tomcat>/lib, without touching any
> Tomcat or LabKey code, and our webapp started up, with Filters initing
> and filtering, Servlets servicing, requests being served, pages
> rendering, etc. The work is incomplete (e.g., most of our pre-compiled
> JSPs were unhappy with this initial attempt... though I have ideas
> there), but it provides a reasonable proof of concept, IMO. You can
> inspect the prototype layer here:
> https://github.com/labkey-adam/jakarta-javax
>
> Why bother offering a Tomcat release that supports both package names?
> To provide a much needed transition option for those who deploy Tomcat
> webapps. I'm not particularly concerned about my team's development
> effort to accommodate the rename (search & replace, upgrade Spring and
> other dependencies). I'm much more concerned about the hundreds of
> organizations that deploy our webapp. As we've transitioned our clients
> through all previous Tomcat upgrades, we've never required a
> simultaneous upgrade of both Tomcat and LabKey; we've always offered
> them the ability to upgrade our product and its dependencies
> independently, over the course of months or even years. A major Tomcat
> release upgrade may be a fairly trivial task to you and me, but it's a
> very big deal to the research organizations that use our system,
> particularly given their need to adhere to strict healthcare compliance
> regulations and validation procedures.
>
> I'd be curious to hear if other developers have concerns about their
> customers' ability to make this transition and if there's interest in
> exploring a dual-package release (or sanctioned add-on). I'd be happy to
> help with the development and testing of such a solution.
>
> Thanks,
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: javax -> jakarta rename
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
There are imo 3 ways we can deal with the migration. All of them assume that all of our ASF projects migrate the affected packages from javax.* to jakarta.*.
A.) of course have all the customer code and libs migrated to jakarta.*.
B.) ClassTransformer + ClassLoader. The ClassTransformer transforms all usage of affected packages from javax.* to jakarta.*. when the classes get loaded. The ClassLoader redirects any META-INF/services/javax.* java.util.ServiceLoader files and serves them as META-INF/services/jakarta.*
C.) pretty much like B.) but as Apache Maven plugin at build time. It could provide the auto-migrated parts as attached artifact.
Btw, I've done plenty of test migration a year ago already
http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/
https://github.com/struberg/tomcat/tree/jakarta
https://github.com/struberg/openwebbeans/tree/jakarta
LieGrue,
strub
> Am 25.12.2019 um 09:26 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> I see a lot of value to the runtime solution cause it is the only one enabling an ops only migration so for all the softwares in "run only" phase it is the only option. However the agent or transformer is the least invasive solution cause it does not require to patch core libs and will avoid app dependencies conflicts/issues (assuming asm is already there as in tomee/meecrowave or shaded with relocation).
>
> Just my 2 cts
>
> Le mer. 25 déc. 2019 à 04:47, Adam Rauch <ad...@labkey.com> a écrit :
>
> On 12/21/2019 11:49 AM, Mark Thomas wrote:
> > On 21/12/2019 17:45, Adam Rauch wrote:
> >
> > <snip/>
> >
> >> Yes, I see that 9.x javax.* will be supported for a long time and I'm
> >> all in favor of killing off deprecated EE libraries. I want to encourage
> >> our users to migrate to Tomcat 10.x and future releases as quickly as
> >> possible, but I'm concerned that 9.x to 10.x will be a very difficult
> >> transition for those who deploy webapps like the one we develop. With
> >> the current plan, I don't see a scenario where our users can upgrade to
> >> the next release of Tomcat, test that change, and then upgrade our
> >> webapp. Because of the package rename, they will need to be upgraded in
> >> lockstep, which has never been the case before. I see the value of a
> >> short-term "transition" release that helps ease this burden by
> >> supporting webapps using either package, but if others don't, then never
> >> mind.
> > I think the ideal migration strategy is going to vary for different
> > users. Personally, I think an approach that largely mirrors what the
> > Jakarta projects are going (i.e. just the package rename, nothing else)
> > and doing that for the container and the app at the same time is the way
> > to go in the majority of cases but I appreciate that that is just my view.
> >
> >> Maybe I've misunderstood the migration tool, but it looks like a great
> >> tool for developers like me, not a tool that will directly help
> >> non-developers who deploy pre-built Tomcat webapps.
> > The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9,
> > run it through this migration tool and then run the migrated app on
> > Tomcat 10. We aren't there yet (I've only tested a JSTL API and
> > implementation) but my intention is to use apps like Jira to test it.
> >
> >> As for Romain's question about doing the transformations in the
> >> classloader, I started with a classloader approach (my classloader
> >> responded to requests for "javax.servlet.*" classes with their
> >> "jakarta.servlet.*" counterparts). I backed away because these classes
> >> then needed to be manipulated so they'd match the javax interfaces'
> >> expectations, but I haven't used ASM before.
> > This is one of the approaches considered in previous discussions. It is,
> > essentially, what the migration tool does. I think it is better to do
> > this conversion in advance rather than take the performance hit in a
> > running application. It is actually fairly simple to do as you only need
> > to modify the String constants.
> >
> >> And this part of the
> >> problem (my webapp requesting javax classes that no longer exist in
> >> Tomcat) was easily solved by simply including those classes in my jar.
> >> The more interesting problem was adapting the objects passed in the
> >> hand-offs between jakarta-only Tomcat and javax-only webapp (e.g.,
> >> Filter, Servlet, FilterChain); I'm not sure a classloader would help
> >> there. But if someone can come up with a simpler classloader (or dynamic
> >> proxy, et al)-based approach, then I'm all for it.
> > I spent a bit of time thinking about this but didn't get as far as
> > coding it. I came to the conclusion it could get very messy once you
> > start wrapping requests and dispatching them and decided to focus on the
> > migration tool instead.
> >
> > Overall, I think it is good that there are a range of tools supporting a
> > range of approaches. As users start the migration progress, hopefully
> > we'll get some feedback and we can refine the tools and/or the approaches.
> >
> > I'd encourage you to put your code somewhere where others can look at it
> > (GitHub being the obvious choice these days) and I'd ask you to consider
> > using the Apache License v2 as that makes it very easy to integrate into
> > Tomcat at some point in the future if that turns out to be the best
> > thing to do.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail:dev-help@tomcat.apache.org
>
> Mark,
>
> Thanks very much for your response. I agree the ideal migration strategy
> will vary and a build-based (or post-build) tool should work for most
> developers. But if there's sufficient demand for a run-time migration
> layer, I believe the implementation would be fairly straightforward and
> the result reasonably efficient.
>
> All of my proof-of-concept code is available on Github:
> https://github.com/labkey-adam/jakarta-javax
>
> Most of the code carries the Apache 2.0 license already (e.g., the
> javax.servlet and javax.el classes copied from Tomcat sources), but I'll
> add a top-level license file to clarify that the entire repo is Apache 2.0.
>
> FilterChainAdapter illustrates the simple approach:
> https://github.com/labkey-adam/jakarta-javax/blob/master/src/javax/servlet/FilterChainAdapter.java
>
> Objects are wrapped, but the Adapters helper class unwraps known
> wrappers to minimize object creation. If we were to move forward with
> this approach, I'd want to restructure the code, moving the new classes
> out of javax.servlet into their own package. And, of course, adding the
> rest of javax.servlet and wiring up other adapters as needed.
>
> Adam
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: javax -> jakarta rename
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I see a lot of value to the runtime solution cause it is the only one
enabling an ops only migration so for all the softwares in "run only" phase
it is the only option. However the agent or transformer is the least
invasive solution cause it does not require to patch core libs and will
avoid app dependencies conflicts/issues (assuming asm is already there as
in tomee/meecrowave or shaded with relocation).
Just my 2 cts
Le mer. 25 déc. 2019 à 04:47, Adam Rauch <ad...@labkey.com> a écrit :
>
> On 12/21/2019 11:49 AM, Mark Thomas wrote:
> > On 21/12/2019 17:45, Adam Rauch wrote:
> >
> > <snip/>
> >
> >> Yes, I see that 9.x javax.* will be supported for a long time and I'm
> >> all in favor of killing off deprecated EE libraries. I want to encourage
> >> our users to migrate to Tomcat 10.x and future releases as quickly as
> >> possible, but I'm concerned that 9.x to 10.x will be a very difficult
> >> transition for those who deploy webapps like the one we develop. With
> >> the current plan, I don't see a scenario where our users can upgrade to
> >> the next release of Tomcat, test that change, and then upgrade our
> >> webapp. Because of the package rename, they will need to be upgraded in
> >> lockstep, which has never been the case before. I see the value of a
> >> short-term "transition" release that helps ease this burden by
> >> supporting webapps using either package, but if others don't, then never
> >> mind.
> > I think the ideal migration strategy is going to vary for different
> > users. Personally, I think an approach that largely mirrors what the
> > Jakarta projects are going (i.e. just the package rename, nothing else)
> > and doing that for the container and the app at the same time is the way
> > to go in the majority of cases but I appreciate that that is just my
> view.
> >
> >> Maybe I've misunderstood the migration tool, but it looks like a great
> >> tool for developers like me, not a tool that will directly help
> >> non-developers who deploy pre-built Tomcat webapps.
> > The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9,
> > run it through this migration tool and then run the migrated app on
> > Tomcat 10. We aren't there yet (I've only tested a JSTL API and
> > implementation) but my intention is to use apps like Jira to test it.
> >
> >> As for Romain's question about doing the transformations in the
> >> classloader, I started with a classloader approach (my classloader
> >> responded to requests for "javax.servlet.*" classes with their
> >> "jakarta.servlet.*" counterparts). I backed away because these classes
> >> then needed to be manipulated so they'd match the javax interfaces'
> >> expectations, but I haven't used ASM before.
> > This is one of the approaches considered in previous discussions. It is,
> > essentially, what the migration tool does. I think it is better to do
> > this conversion in advance rather than take the performance hit in a
> > running application. It is actually fairly simple to do as you only need
> > to modify the String constants.
> >
> >> And this part of the
> >> problem (my webapp requesting javax classes that no longer exist in
> >> Tomcat) was easily solved by simply including those classes in my jar.
> >> The more interesting problem was adapting the objects passed in the
> >> hand-offs between jakarta-only Tomcat and javax-only webapp (e.g.,
> >> Filter, Servlet, FilterChain); I'm not sure a classloader would help
> >> there. But if someone can come up with a simpler classloader (or dynamic
> >> proxy, et al)-based approach, then I'm all for it.
> > I spent a bit of time thinking about this but didn't get as far as
> > coding it. I came to the conclusion it could get very messy once you
> > start wrapping requests and dispatching them and decided to focus on the
> > migration tool instead.
> >
> > Overall, I think it is good that there are a range of tools supporting a
> > range of approaches. As users start the migration progress, hopefully
> > we'll get some feedback and we can refine the tools and/or the
> approaches.
> >
> > I'd encourage you to put your code somewhere where others can look at it
> > (GitHub being the obvious choice these days) and I'd ask you to consider
> > using the Apache License v2 as that makes it very easy to integrate into
> > Tomcat at some point in the future if that turns out to be the best
> > thing to do.
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail:dev-help@tomcat.apache.org
>
> Mark,
>
> Thanks very much for your response. I agree the ideal migration strategy
> will vary and a build-based (or post-build) tool should work for most
> developers. But if there's sufficient demand for a run-time migration
> layer, I believe the implementation would be fairly straightforward and
> the result reasonably efficient.
>
> All of my proof-of-concept code is available on Github:
> https://github.com/labkey-adam/jakarta-javax
>
> Most of the code carries the Apache 2.0 license already (e.g., the
> javax.servlet and javax.el classes copied from Tomcat sources), but I'll
> add a top-level license file to clarify that the entire repo is Apache 2.0.
>
> FilterChainAdapter illustrates the simple approach:
>
> https://github.com/labkey-adam/jakarta-javax/blob/master/src/javax/servlet/FilterChainAdapter.java
>
> Objects are wrapped, but the Adapters helper class unwraps known
> wrappers to minimize object creation. If we were to move forward with
> this approach, I'd want to restructure the code, moving the new classes
> out of javax.servlet into their own package. And, of course, adding the
> rest of javax.servlet and wiring up other adapters as needed.
>
> Adam
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: javax -> jakarta rename
Posted by Adam Rauch <ad...@labkey.com>.
On 12/21/2019 11:49 AM, Mark Thomas wrote:
> On 21/12/2019 17:45, Adam Rauch wrote:
>
> <snip/>
>
>> Yes, I see that 9.x javax.* will be supported for a long time and I'm
>> all in favor of killing off deprecated EE libraries. I want to encourage
>> our users to migrate to Tomcat 10.x and future releases as quickly as
>> possible, but I'm concerned that 9.x to 10.x will be a very difficult
>> transition for those who deploy webapps like the one we develop. With
>> the current plan, I don't see a scenario where our users can upgrade to
>> the next release of Tomcat, test that change, and then upgrade our
>> webapp. Because of the package rename, they will need to be upgraded in
>> lockstep, which has never been the case before. I see the value of a
>> short-term "transition" release that helps ease this burden by
>> supporting webapps using either package, but if others don't, then never
>> mind.
> I think the ideal migration strategy is going to vary for different
> users. Personally, I think an approach that largely mirrors what the
> Jakarta projects are going (i.e. just the package rename, nothing else)
> and doing that for the container and the app at the same time is the way
> to go in the majority of cases but I appreciate that that is just my view.
>
>> Maybe I've misunderstood the migration tool, but it looks like a great
>> tool for developers like me, not a tool that will directly help
>> non-developers who deploy pre-built Tomcat webapps.
> The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9,
> run it through this migration tool and then run the migrated app on
> Tomcat 10. We aren't there yet (I've only tested a JSTL API and
> implementation) but my intention is to use apps like Jira to test it.
>
>> As for Romain's question about doing the transformations in the
>> classloader, I started with a classloader approach (my classloader
>> responded to requests for "javax.servlet.*" classes with their
>> "jakarta.servlet.*" counterparts). I backed away because these classes
>> then needed to be manipulated so they'd match the javax interfaces'
>> expectations, but I haven't used ASM before.
> This is one of the approaches considered in previous discussions. It is,
> essentially, what the migration tool does. I think it is better to do
> this conversion in advance rather than take the performance hit in a
> running application. It is actually fairly simple to do as you only need
> to modify the String constants.
>
>> And this part of the
>> problem (my webapp requesting javax classes that no longer exist in
>> Tomcat) was easily solved by simply including those classes in my jar.
>> The more interesting problem was adapting the objects passed in the
>> hand-offs between jakarta-only Tomcat and javax-only webapp (e.g.,
>> Filter, Servlet, FilterChain); I'm not sure a classloader would help
>> there. But if someone can come up with a simpler classloader (or dynamic
>> proxy, et al)-based approach, then I'm all for it.
> I spent a bit of time thinking about this but didn't get as far as
> coding it. I came to the conclusion it could get very messy once you
> start wrapping requests and dispatching them and decided to focus on the
> migration tool instead.
>
> Overall, I think it is good that there are a range of tools supporting a
> range of approaches. As users start the migration progress, hopefully
> we'll get some feedback and we can refine the tools and/or the approaches.
>
> I'd encourage you to put your code somewhere where others can look at it
> (GitHub being the obvious choice these days) and I'd ask you to consider
> using the Apache License v2 as that makes it very easy to integrate into
> Tomcat at some point in the future if that turns out to be the best
> thing to do.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:dev-help@tomcat.apache.org
Mark,
Thanks very much for your response. I agree the ideal migration strategy
will vary and a build-based (or post-build) tool should work for most
developers. But if there's sufficient demand for a run-time migration
layer, I believe the implementation would be fairly straightforward and
the result reasonably efficient.
All of my proof-of-concept code is available on Github:
https://github.com/labkey-adam/jakarta-javax
Most of the code carries the Apache 2.0 license already (e.g., the
javax.servlet and javax.el classes copied from Tomcat sources), but I'll
add a top-level license file to clarify that the entire repo is Apache 2.0.
FilterChainAdapter illustrates the simple approach:
https://github.com/labkey-adam/jakarta-javax/blob/master/src/javax/servlet/FilterChainAdapter.java
Objects are wrapped, but the Adapters helper class unwraps known
wrappers to minimize object creation. If we were to move forward with
this approach, I'd want to restructure the code, moving the new classes
out of javax.servlet into their own package. And, of course, adding the
rest of javax.servlet and wiring up other adapters as needed.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: javax -> jakarta rename
Posted by Mark Thomas <ma...@apache.org>.
On 21/12/2019 17:45, Adam Rauch wrote:
<snip/>
> Yes, I see that 9.x javax.* will be supported for a long time and I'm
> all in favor of killing off deprecated EE libraries. I want to encourage
> our users to migrate to Tomcat 10.x and future releases as quickly as
> possible, but I'm concerned that 9.x to 10.x will be a very difficult
> transition for those who deploy webapps like the one we develop. With
> the current plan, I don't see a scenario where our users can upgrade to
> the next release of Tomcat, test that change, and then upgrade our
> webapp. Because of the package rename, they will need to be upgraded in
> lockstep, which has never been the case before. I see the value of a
> short-term "transition" release that helps ease this burden by
> supporting webapps using either package, but if others don't, then never
> mind.
I think the ideal migration strategy is going to vary for different
users. Personally, I think an approach that largely mirrors what the
Jakarta projects are going (i.e. just the package rename, nothing else)
and doing that for the container and the app at the same time is the way
to go in the majority of cases but I appreciate that that is just my view.
> Maybe I've misunderstood the migration tool, but it looks like a great
> tool for developers like me, not a tool that will directly help
> non-developers who deploy pre-built Tomcat webapps.
The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9,
run it through this migration tool and then run the migrated app on
Tomcat 10. We aren't there yet (I've only tested a JSTL API and
implementation) but my intention is to use apps like Jira to test it.
> As for Romain's question about doing the transformations in the
> classloader, I started with a classloader approach (my classloader
> responded to requests for "javax.servlet.*" classes with their
> "jakarta.servlet.*" counterparts). I backed away because these classes
> then needed to be manipulated so they'd match the javax interfaces'
> expectations, but I haven't used ASM before.
This is one of the approaches considered in previous discussions. It is,
essentially, what the migration tool does. I think it is better to do
this conversion in advance rather than take the performance hit in a
running application. It is actually fairly simple to do as you only need
to modify the String constants.
> And this part of the
> problem (my webapp requesting javax classes that no longer exist in
> Tomcat) was easily solved by simply including those classes in my jar.
> The more interesting problem was adapting the objects passed in the
> hand-offs between jakarta-only Tomcat and javax-only webapp (e.g.,
> Filter, Servlet, FilterChain); I'm not sure a classloader would help
> there. But if someone can come up with a simpler classloader (or dynamic
> proxy, et al)-based approach, then I'm all for it.
I spent a bit of time thinking about this but didn't get as far as
coding it. I came to the conclusion it could get very messy once you
start wrapping requests and dispatching them and decided to focus on the
migration tool instead.
Overall, I think it is good that there are a range of tools supporting a
range of approaches. As users start the migration progress, hopefully
we'll get some feedback and we can refine the tools and/or the approaches.
I'd encourage you to put your code somewhere where others can look at it
(GitHub being the obvious choice these days) and I'd ask you to consider
using the Apache License v2 as that makes it very easy to integrate into
Tomcat at some point in the future if that turns out to be the best
thing to do.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: javax -> jakarta rename
Posted by Adam Rauch <ad...@labkey.com>.
On 12/21/2019 3:11 AM, Rémy Maucherat wrote:
> On Sat, Dec 21, 2019 at 7:36 AM Adam Rauch <adam@labkey.com
> <ma...@labkey.com>> wrote:
>
> I've watched with great interest the recent list discussions
> surrounding
> javax -> jakarta renaming and the draft release numbering plan. I'm
> curious: Would the Tomcat team consider making a Tomcat release that
> supports BOTH the javax and jakarta package names?
>
>
> If you've read the discussions, then you can see the current plan is
> to provide a deployment tool.
>
> So as you can see in the plan, we will have a 9.x release branch for
> javax.* supported "forever", and branches for jakarta.* support moving
> forward (including a tool for javax.* -> jakarta.* conversion).
>
> Now, there's no plan *right now* for a Tomcat which allows
> Frankenstein webapps. Personally, I think there will always be
> problems, and that it's a good time at some point to kill off the long
> deprecated and unsupported EE libraries that are still out there. If
> unintrusive classloader magic can happen easily, then why not I guess.
>
> Other Apache projects like TomEE and Meecrowave have the exact same
> "need", and most likely all will use the same code for that javax.* ->
> jakarta.* support.
>
> Rémy
>
Hi Rémy,
Yes, I see that 9.x javax.* will be supported for a long time and I'm
all in favor of killing off deprecated EE libraries. I want to encourage
our users to migrate to Tomcat 10.x and future releases as quickly as
possible, but I'm concerned that 9.x to 10.x will be a very difficult
transition for those who deploy webapps like the one we develop. With
the current plan, I don't see a scenario where our users can upgrade to
the next release of Tomcat, test that change, and then upgrade our
webapp. Because of the package rename, they will need to be upgraded in
lockstep, which has never been the case before. I see the value of a
short-term "transition" release that helps ease this burden by
supporting webapps using either package, but if others don't, then never
mind.
Maybe I've misunderstood the migration tool, but it looks like a great
tool for developers like me, not a tool that will directly help
non-developers who deploy pre-built Tomcat webapps.
As for Romain's question about doing the transformations in the
classloader, I started with a classloader approach (my classloader
responded to requests for "javax.servlet.*" classes with their
"jakarta.servlet.*" counterparts). I backed away because these classes
then needed to be manipulated so they'd match the javax interfaces'
expectations, but I haven't used ASM before. And this part of the
problem (my webapp requesting javax classes that no longer exist in
Tomcat) was easily solved by simply including those classes in my jar.
The more interesting problem was adapting the objects passed in the
hand-offs between jakarta-only Tomcat and javax-only webapp (e.g.,
Filter, Servlet, FilterChain); I'm not sure a classloader would help
there. But if someone can come up with a simpler classloader (or dynamic
proxy, et al)-based approach, then I'm all for it.
Adam
Re: javax -> jakarta rename
Posted by Rémy Maucherat <re...@apache.org>.
On Sat, Dec 21, 2019 at 7:36 AM Adam Rauch <ad...@labkey.com> wrote:
> I've watched with great interest the recent list discussions surrounding
> javax -> jakarta renaming and the draft release numbering plan. I'm
> curious: Would the Tomcat team consider making a Tomcat release that
> supports BOTH the javax and jakarta package names?
>
If you've read the discussions, then you can see the current plan is to
provide a deployment tool.
So as you can see in the plan, we will have a 9.x release branch for
javax.* supported "forever", and branches for jakarta.* support moving
forward (including a tool for javax.* -> jakarta.* conversion).
Now, there's no plan *right now* for a Tomcat which allows Frankenstein
webapps. Personally, I think there will always be problems, and that it's a
good time at some point to kill off the long deprecated and unsupported EE
libraries that are still out there. If unintrusive classloader magic can
happen easily, then why not I guess.
Other Apache projects like TomEE and Meecrowave have the exact same "need",
and most likely all will use the same code for that javax.* -> jakarta.*
support.
Rémy