You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael B Allen <io...@gmail.com> on 2021/12/28 00:34:48 UTC
javax.servlet vs jakarta.servlet?
Hello Tomcat Users,
Does anyone have a sense of how many people are using the jakarta.servlet API?
I have a product that includes some classes that use javax.servlet and
I'm trying to figure out how to support people who want to use
jakarta.servlet. I plan to install Tomcat 10 momentarily but I assume
one just has to add whatever javax.servlet jar to make Tomcat 10 work
with a javax.servlet lib or app?
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Jason Wee <pe...@gmail.com>.
yeap, also take note libs that depend on the new namespace and taglibs
On Tue, Dec 28, 2021 at 8:35 AM Michael B Allen <io...@gmail.com> wrote:
>
> Hello Tomcat Users,
>
> Does anyone have a sense of how many people are using the jakarta.servlet API?
>
> I have a product that includes some classes that use javax.servlet and
> I'm trying to figure out how to support people who want to use
> jakarta.servlet. I plan to install Tomcat 10 momentarily but I assume
> one just has to add whatever javax.servlet jar to make Tomcat 10 work
> with a javax.servlet lib or app?
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by David Kerber <dc...@verizon.net.INVALID>.
On 12/29/2021 2:54 PM, Michael B Allen wrote:
> On Wed, Dec 29, 2021 at 2:07 PM Mark Thomas <ma...@apache.org> wrote:
>> One of the advantages of moving to Eclipse is that everyone involved in
>> the spec, not just the spec lead, has an equal say in what goes into the
>> spec.
> That sounds like design by committee which is my concern. IMO the only
> way to design a really good API is for one individual with a vision to
> just write it, use it, exercise it and then see what works and what
> does not. I routinely re-write things multiple times very slooooowly
> before settling on an API. It's exponentially harder for multiple
> people to have the same vision. Design by committee can easily
> degenerate into an overly-OOP set of interfaces and classes and enums
> to define an API that doesn't actually do that much. Once you lock
> into an API, that could be used for decades. So even the slightest
> mistake can create seams that transcend every codebase that uses it
> with long term consequences.
I think the chances of a single person missing something useful or
important are greater than the chance of a *small* committee
over-designing the API. You are correct that CORBA was a big mess due to
its design by a huge committee, but a smaller group has done will with
most java APIs.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by "Mark H. Wood" <mw...@iupui.edu>.
On Thu, Dec 30, 2021 at 03:16:51PM -0500, Michael B Allen wrote:
> On Thu, Dec 30, 2021 at 10:57 AM Christopher Schultz
> <ch...@christopherschultz.net> wrote:
> >
> > You mean like ServletContext.getRealPath?
>
> Honestly I'm not sure how I feel about getRealPath. On the one hand, I
> don't think it's reasonable to just pretend that applications only
> exist in the vacuum of space. There are many practical reasons why an
> application might want to interact with the filesystem but without
> requiring absolute paths. Just because there might not be a file
> system is a weak excuse to not properly account for one. Being able to
> update a file of properties for example and have the application see
> that the file is updated without reloading the webapp (maybe even if
> the app is packaged as a war) is very useful. On the other hand I
> don't think I would want another 10 classes just to create some kind
> of ancillary webapp storage abstraction.
I would say that servlet code should, in general, assume that nothing
exists outside of the container except that which it is told about.
It should not care where it is. If it needs to interact with a
filesystem, it should be given paths into that filesystem as context
parameters or environment objects.
If I intended to make changes to an application's configuration
without re-deploying, I would put the configuration elsewhere and
configure the context with a path (or a Path) to it.
You may wish to have a look at https://stackoverflow.com/a/12160863/2916377
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
Re: javax.servlet vs jakarta.servlet?
Posted by Michael B Allen <io...@gmail.com>.
On Thu, Dec 30, 2021 at 10:57 AM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> You mean like ServletContext.getRealPath?
Honestly I'm not sure how I feel about getRealPath. On the one hand, I
don't think it's reasonable to just pretend that applications only
exist in the vacuum of space. There are many practical reasons why an
application might want to interact with the filesystem but without
requiring absolute paths. Just because there might not be a file
system is a weak excuse to not properly account for one. Being able to
update a file of properties for example and have the application see
that the file is updated without reloading the webapp (maybe even if
the app is packaged as a war) is very useful. On the other hand I
don't think I would want another 10 classes just to create some kind
of ancillary webapp storage abstraction.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Michael,
On 12/29/21 14:54, Michael B Allen wrote:
> On Wed, Dec 29, 2021 at 2:07 PM Mark Thomas <ma...@apache.org> wrote:
>> One of the advantages of moving to Eclipse is that everyone involved in
>> the spec, not just the spec lead, has an equal say in what goes into the
>> spec.
>
> That sounds like design by committee which is my concern. IMO the only
> way to design a really good API is for one individual with a vision to
> just write it, use it, exercise it and then see what works and what
> does not. I routinely re-write things multiple times very slooooowly
> before settling on an API. It's exponentially harder for multiple
> people to have the same vision. Design by committee can easily
> degenerate into an overly-OOP set of interfaces and classes and enums
> to define an API that doesn't actually do that much. Once you lock
> into an API, that could be used for decades. So even the slightest
> mistake can create seams that transcend every codebase that uses it
> with long term consequences.
You mean like ServletContext.getRealPath?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Michael B Allen <io...@gmail.com>.
On Wed, Dec 29, 2021 at 2:07 PM Mark Thomas <ma...@apache.org> wrote:
> One of the advantages of moving to Eclipse is that everyone involved in
> the spec, not just the spec lead, has an equal say in what goes into the
> spec.
That sounds like design by committee which is my concern. IMO the only
way to design a really good API is for one individual with a vision to
just write it, use it, exercise it and then see what works and what
does not. I routinely re-write things multiple times very slooooowly
before settling on an API. It's exponentially harder for multiple
people to have the same vision. Design by committee can easily
degenerate into an overly-OOP set of interfaces and classes and enums
to define an API that doesn't actually do that much. Once you lock
into an API, that could be used for decades. So even the slightest
mistake can create seams that transcend every codebase that uses it
with long term consequences.
But I suppose this is thoroughly off topic at this point.
Thanks for your help,
Mike
--
Java Active Directory Integration
http://www.ioplex.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Mark Thomas <ma...@apache.org>.
On 29/12/2021 15:55, Michael B Allen wrote:
> On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas <ma...@apache.org> wrote:
<snip/>
> Actually it seems the migration tool behind this feature:
>
> https://github.com/apache/tomcat-jakartaee-migration
>
> is a better and more general solution. If it's just re-writing package
> names, can any jar converted using the tomcat-jakartaee-migration tool
> be used with another app server like Jetty 11?
Yes.
<snip/>
>> When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop
>> and 9.11.x releases will start. These will essentially track Tomcat 11.x
>> releases but with the Java EE API rather than the Jakarta EE API.
>>
>> And so on for as long as there is community demand for the Java EE
>> support and there are 3 Tomcat PMC members willing to vote for the release.
>
> That is encouraging. So just to be crystal clear, Tomcat 9 will get
> security fixes as if Tomcat 10 didn't exist?
9.10.x, 9.11.x etc will continue to get security fixes. It will be no
different from any other supported Tomcat version in that regard.
> Is there a page on apache.org that explains what you say or are you
> speaking authoritatively?
There have been variations of this on the mailing lists, presented at
conferences and on the wiki:
https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
The main variation is whether we start 9.10.x now and and keep 9.Y.x
aligned with the latest Tomcat version that supports Jakarta EE or
whether we start 9.10.x after 9.0.x is EOL and keep 9.Y.x aligned with
the oldest Tomcat version that supports Jakarta EE. Either way, Java EE
support will continue.
>> No need for any build process changes if you don't want to. Just use
>> webapps-javaee and the automatic conversion.
>
> Well the webapps-javaee dir is good for an existing application that
> you don't want to touch but maybe there should also be a
> WEB-INF/lib-javaee/ directory to convert individual jars? That seems
> like a more likely scenario where people want to use JakartaEE but
> there are a few libs that haven't made the leap.
No need. If you deploy an app with mixed libraries, Tomcat will just
convert the ones that need converting. The hard part will be building
the app as the IDE won't do the conversion. Probably simpler to use the
tool to convert the libraries, deploy them to your local Maven repo and
build from there.
> Ok so the classes don't cascade effortlessly. That doesn't mean you
> couldn't create a wrapper that just operates on a member.
But that means the app can't just code to one API or the other. It has
to do the wrapping. If you are prepared to that in the app you would be
better to to code to the new API as the search and replace is lot simpler.
My point was that a container, like Tomcat, can't - without a lot of
plumbing that I'm not 100% is even possible for all use cases - support
both Java EE and Jakarta EE concurrently.
>> Ignoring the package change, the biggest difference in Servlet 6 and the
>> other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated
>> code has been removed.
>
> Just an aside, I must say the community process worries me a little.
> Say what you want about Oracle but they have provided a stable
> platform for many years. Contrarily, there have historically been
> community driven efforts that have produced some, lets say,
> "extraneous" results. Look into the history of X.500. Or Oasis
> standards like CORBA. HttpServletRequest.login() is misplaced IMO.
> When people start designing by committee at conferences, I get a
> twitch in my eye.
It depends a lot on how the committee is run and who is on the
committee. There are lots of good examples as well such as the HTTP specs.
For the record, HttpServletRequest.login() was defined when Oracle were
controlling the Servlet spec.
One of the advantages of moving to Eclipse is that everyone involved in
the spec, not just the spec lead, has an equal say in what goes into the
spec. A lot of long standing issues have been resolved for Jakarta EE 10
although for Servlet there are so many such issues only some could be
tackled with the time and resources available.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Michael B Allen <io...@gmail.com>.
On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas <ma...@apache.org> wrote:
>
> On 28/12/2021 14:58, Michael B Allen wrote:
> > On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner <jc...@servoy.com> wrote:
> >>
> >> Will that really work?
> >
> > No.
> >
> > Clearly I'm not paying attention because after reading surprisingly
> > little information about this fundamental incompatibility and
> > downloading and trying Tomcat 10, there is no way to use a
> > javax.servlet library or application with a jakarta.servlet app server
> > like Tomcat 10.
>
> Yes there is. Just place the Java EE web application in the
> webapps-javaee directory and Tomcat will convert automatically to
> Jakarta EE and then deploy it.
Hi Mark,
Thanks for the detailed answer.
I will try this (actually I already did but I'm getting 404 so I
probably have some other unrelated problem).
Actually it seems the migration tool behind this feature:
https://github.com/apache/tomcat-jakartaee-migration
is a better and more general solution. If it's just re-writing package
names, can any jar converted using the tomcat-jakartaee-migration tool
be used with another app server like Jetty 11?
> > So now I REALLY want to know if people actually use
> > Tomcat 10 and what the release policy will be going forward for Tomcat
> > 9. Is Tomcat 9 going to be maintained separately with security fixes
> > and such?
>
> It is the intention of the Tomcat community to continue to support
> Tomcat 9 for as long as there are users that want a supported Java EE
> platform.
>
> Normally, we support 3 versions in parallel with a major version
> reaching EOL every ~3 years. Typically a major version will be supported
> for ~10 years.
>
> Tomcat 9 will be different. When Tomcat 9 reaches the normal EOL point
> (roughly 2027) 9.0.x releases will stop but Tomcat 9.10.x releases will
> start. These will essentially track Tomcat 10.x releases but with the
> Java EE API rather than the Jakarta EE API.
>
> When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop
> and 9.11.x releases will start. These will essentially track Tomcat 11.x
> releases but with the Java EE API rather than the Jakarta EE API.
>
> And so on for as long as there is community demand for the Java EE
> support and there are 3 Tomcat PMC members willing to vote for the release.
That is encouraging. So just to be crystal clear, Tomcat 9 will get
security fixes as if Tomcat 10 didn't exist?
Is there a page on apache.org that explains what you say or are you
speaking authoritatively?
> If anyone has an app that the conversion tool doesn't handle correctly,
> open a bug, tell us what it isn't getting right and we should be able to
> fix it.
Will do.
> No need for any build process changes if you don't want to. Just use
> webapps-javaee and the automatic conversion.
Well the webapps-javaee dir is good for an existing application that
you don't want to touch but maybe there should also be a
WEB-INF/lib-javaee/ directory to convert individual jars? That seems
like a more likely scenario where people want to use JakartaEE but
there are a few libs that haven't made the leap.
> > package javax.servlet.http;
> >
> > public class HttpServletRequestWrapper extends
> > jakarta.servlet.http.ServletRequestWrapper implements
> > HttpServletRequest
> > {
> > // nothing to see here
> > }
>
> This illustrates the my point. You would not be able to cast an instance
> of javax.servlet.http.HttpServletRequestWrapper to
> javax.servlet.http.ServletRequestWrapper
Ok so the classes don't cascade effortlessly. That doesn't mean you
couldn't create a wrapper that just operates on a member.
> Alternatively, just try and write a class (that compiles) that
> implements javax.servlet.http.HttpServletRequest and
> jakarta.servlet.http.HttpServletRequest
I wasn't suggesting that the javax classes had to actually be jakarta
instances under the hood.
But no matter. If the migration tool actually does what it looks like
it's supposed to do, I would say that's the best option. People can
either call it in their build to make two jars or the operator can use
it to convert a jar at their end.
> Ignoring the package change, the biggest difference in Servlet 6 and the
> other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated
> code has been removed.
Just an aside, I must say the community process worries me a little.
Say what you want about Oracle but they have provided a stable
platform for many years. Contrarily, there have historically been
community driven efforts that have produced some, lets say,
"extraneous" results. Look into the history of X.500. Or Oasis
standards like CORBA. HttpServletRequest.login() is misplaced IMO.
When people start designing by committee at conferences, I get a
twitch in my eye.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Mark Thomas <ma...@apache.org>.
On 28/12/2021 14:58, Michael B Allen wrote:
> On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner <jc...@servoy.com> wrote:
>>
>> Will that really work?
>
> No.
>
> Clearly I'm not paying attention because after reading surprisingly
> little information about this fundamental incompatibility and
> downloading and trying Tomcat 10, there is no way to use a
> javax.servlet library or application with a jakarta.servlet app server
> like Tomcat 10.
Yes there is. Just place the Java EE web application in the
webapps-javaee directory and Tomcat will convert automatically to
Jakarta EE and then deploy it.
> So now I REALLY want to know if people actually use
> Tomcat 10 and what the release policy will be going forward for Tomcat
> 9. Is Tomcat 9 going to be maintained separately with security fixes
> and such?
It is the intention of the Tomcat community to continue to support
Tomcat 9 for as long as there are users that want a supported Java EE
platform.
Normally, we support 3 versions in parallel with a major version
reaching EOL every ~3 years. Typically a major version will be supported
for ~10 years.
Tomcat 9 will be different. When Tomcat 9 reaches the normal EOL point
(roughly 2027) 9.0.x releases will stop but Tomcat 9.10.x releases will
start. These will essentially track Tomcat 10.x releases but with the
Java EE API rather than the Jakarta EE API.
When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop
and 9.11.x releases will start. These will essentially track Tomcat 11.x
releases but with the Java EE API rather than the Jakarta EE API.
And so on for as long as there is community demand for the Java EE
support and there are 3 Tomcat PMC members willing to vote for the release.
> There must be thousands of libraries and applications that cannot be
> converted for various reasons.
The only application I haven't been able to convert so far was Jira -
primarily because the error messages when Jira failed to start were
extremely unhelpful. I'm fairly sure the conversion process was missing
some OSGI config somewhere but I couldn't figure out what it was.
If anyone has an app that the conversion tool doesn't handle correctly,
open a bug, tell us what it isn't getting right and we should be able to
fix it.
> Even active open source projects are
> probably going to punt on this. Think about how many github projects
> there are with one guy using it for some thing at work and so he
> doesn't want to make up some screwy build process that creates two
> jars. This basically guarantees that people will be using Tomcat 9 for
> many years.
No need for any build process changes if you don't want to. Just use
webapps-javaee and the automatic conversion.
If there are apps that genuinely can't migrate (and I have a hard time
believing there are really any apps in this category) then Tomcat 9 will
continue to be available.
> Also, correct me if I'm wrong but it seems to me that the two
> interfaces should easily coexist.
Consider yourself corrected.
> The Servlet interface is just that -
> an interface. So just create an implementation of javax.servlet that
> uses the jakarta.servlet code as it's implementation. In many cases
> the code could literally be like:
>
> package javax.servlet.http;
>
> public class HttpServletRequestWrapper extends
> jakarta.servlet.http.ServletRequestWrapper implements
> HttpServletRequest
> {
> // nothing to see here
> }
This illustrates the my point. You would not be able to cast an instance
of javax.servlet.http.HttpServletRequestWrapper to
javax.servlet.http.ServletRequestWrapper
Alternatively, just try and write a class (that compiles) that
implements javax.servlet.http.HttpServletRequest and
jakarta.servlet.http.HttpServletRequest
You can't. Well, you might be able to do get it to work with dynamic
proxies but the complexity would not be pretty - and I don't think you
could hide it from the web application which defeats the point of trying.
> The only code that might be different is details about sessions or
> something that jakarta.servlet wants to do a little differently. But
> in that case, the ability of OOP to override methods to selectively
> change some behavior can be utilized well here. Unless something in
> jakarta.servlet changes that fundamentally breaks compatibility with
> javax.servlet, code using javax.servlet shouldn't know the difference.
It is much, much more complicated than that.
> And if something does change that breaks backward compatibility, that
> would be a slightly frightening change in policy regarding backward
> compatibility of Java code in general since just about any piece of
> Java code written in literally the last 20 years will run on the
> latest platform with only minor tweaks.
Yes and no. The Java team is making some more invasive changes. The
removal of the security manager is the one that jumps immediately to mind.
Ignoring the package change, the biggest difference in Servlet 6 and the
other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated
code has been removed.
> The effort required for every product and project in the universe to
> create a build process that generates two jars is massive compared to
> the effort that would be required for Tomcat to support both
> javax.servlet and jakarta.servlet even if it were difficult to do for
> some reason I'm not seeing.
Yes, a Tomcat (or any container) based solution is more efficient. Hence
webapps-javaee and automatic conversion.
The solution you are proposing isn't viable.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Johan Compagner <jc...@servoy.com>.
i think the whole point was that they had to break with the "javax" naming
because oracle doesn't allow that outside it stuff.
not sure if Tomcat 10 would be allowed to just have both classes/interfaces
for compatibility
Also this would be a big hurdle moving forwards (and not sure if everything
is really an interface and if there are no concrete classes in the spec)
But for tomcat 10 and maybe for tomcat 11 this would be a good migration
path that it would just run both of them just as easy.
But anyway we kind of have this
Apache Tomcat® - Apache Tomcat Migration Tool for Jakarta EE Software
Downloads <https://tomcat.apache.org/download-migration.cgi>
or:
"Applications that run on Tomcat 9 and earlier will not run on Tomcat 10
without changes. Java EE based applications designed for Tomcat 9 and
earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and
Tomcat will automatically convert them to Jakarta EE and copy them to the
webapps directory. This conversion is performed using the Apache Tomcat
migration tool for Jakarta EE tool
<https://github.com/apache/tomcat-jakartaee-migration> which is also
available as a separate download
<https://tomcat.apache.org/download-migration.cgi> for off-line use."
but i agree a bit with your sentiment, this is a major break, its kind of a
new spec (they versioned it 4.0 to 5.0 but it kind of just a 1.0 again,
starting over)
So i also do think that the maintenance window of Tomcat 9 will be quite
long, but tomcat versions are supported for quite some time, 8.5 is still
supported and the first release was beginning of 2014.
Tomcat 9 was 3 years later or so, so i guess it will be supported maybe
even close to 2030...
On Tue, 28 Dec 2021 at 16:00, Michael B Allen <io...@gmail.com> wrote:
> On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner <jc...@servoy.com>
> wrote:
> >
> > Will that really work?
>
> No.
>
> Clearly I'm not paying attention because after reading surprisingly
> little information about this fundamental incompatibility and
> downloading and trying Tomcat 10, there is no way to use a
> javax.servlet library or application with a jakarta.servlet app server
> like Tomcat 10. So now I REALLY want to know if people actually use
> Tomcat 10 and what the release policy will be going forward for Tomcat
> 9. Is Tomcat 9 going to be maintained separately with security fixes
> and such?
>
> There must be thousands of libraries and applications that cannot be
> converted for various reasons. Even active open source projects are
> probably going to punt on this. Think about how many github projects
> there are with one guy using it for some thing at work and so he
> doesn't want to make up some screwy build process that creates two
> jars. This basically guarantees that people will be using Tomcat 9 for
> many years.
>
> Also, correct me if I'm wrong but it seems to me that the two
> interfaces should easily coexist. The Servlet interface is just that -
> an interface. So just create an implementation of javax.servlet that
> uses the jakarta.servlet code as it's implementation. In many cases
> the code could literally be like:
>
> package javax.servlet.http;
>
> public class HttpServletRequestWrapper extends
> jakarta.servlet.http.ServletRequestWrapper implements
> HttpServletRequest
> {
> // nothing to see here
> }
>
> The only code that might be different is details about sessions or
> something that jakarta.servlet wants to do a little differently. But
> in that case, the ability of OOP to override methods to selectively
> change some behavior can be utilized well here. Unless something in
> jakarta.servlet changes that fundamentally breaks compatibility with
> javax.servlet, code using javax.servlet shouldn't know the difference.
> And if something does change that breaks backward compatibility, that
> would be a slightly frightening change in policy regarding backward
> compatibility of Java code in general since just about any piece of
> Java code written in literally the last 20 years will run on the
> latest platform with only minor tweaks.
>
> The effort required for every product and project in the universe to
> create a build process that generates two jars is massive compared to
> the effort that would be required for Tomcat to support both
> javax.servlet and jakarta.servlet even if it were difficult to do for
> some reason I'm not seeing.
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Johan Compagner
Servoy
Re: javax.servlet vs jakarta.servlet?
Posted by Michael B Allen <io...@gmail.com>.
On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner <jc...@servoy.com> wrote:
>
> Will that really work?
No.
Clearly I'm not paying attention because after reading surprisingly
little information about this fundamental incompatibility and
downloading and trying Tomcat 10, there is no way to use a
javax.servlet library or application with a jakarta.servlet app server
like Tomcat 10. So now I REALLY want to know if people actually use
Tomcat 10 and what the release policy will be going forward for Tomcat
9. Is Tomcat 9 going to be maintained separately with security fixes
and such?
There must be thousands of libraries and applications that cannot be
converted for various reasons. Even active open source projects are
probably going to punt on this. Think about how many github projects
there are with one guy using it for some thing at work and so he
doesn't want to make up some screwy build process that creates two
jars. This basically guarantees that people will be using Tomcat 9 for
many years.
Also, correct me if I'm wrong but it seems to me that the two
interfaces should easily coexist. The Servlet interface is just that -
an interface. So just create an implementation of javax.servlet that
uses the jakarta.servlet code as it's implementation. In many cases
the code could literally be like:
package javax.servlet.http;
public class HttpServletRequestWrapper extends
jakarta.servlet.http.ServletRequestWrapper implements
HttpServletRequest
{
// nothing to see here
}
The only code that might be different is details about sessions or
something that jakarta.servlet wants to do a little differently. But
in that case, the ability of OOP to override methods to selectively
change some behavior can be utilized well here. Unless something in
jakarta.servlet changes that fundamentally breaks compatibility with
javax.servlet, code using javax.servlet shouldn't know the difference.
And if something does change that breaks backward compatibility, that
would be a slightly frightening change in policy regarding backward
compatibility of Java code in general since just about any piece of
Java code written in literally the last 20 years will run on the
latest platform with only minor tweaks.
The effort required for every product and project in the universe to
create a build process that generates two jars is massive compared to
the effort that would be required for Tomcat to support both
javax.servlet and jakarta.servlet even if it were difficult to do for
some reason I'm not seeing.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: javax.servlet vs jakarta.servlet?
Posted by Johan Compagner <jc...@servoy.com>.
Will that really work?
tomcat 10 internally really expects jakarta.xxx now right?
so if you have a class MyServlet extends javax.Servlet
i don't think tomcat 10 will do anything with that (if that is not
converted first through the migration tool)
I have a feeling that you really can't mix, but i can be wrong
johan
On Tue, 28 Dec 2021 at 01:35, Michael B Allen <io...@gmail.com> wrote:
> Hello Tomcat Users,
>
> Does anyone have a sense of how many people are using the jakarta.servlet
> API?
>
> I have a product that includes some classes that use javax.servlet and
> I'm trying to figure out how to support people who want to use
> jakarta.servlet. I plan to install Tomcat 10 momentarily but I assume
> one just has to add whatever javax.servlet jar to make Tomcat 10 work
> with a javax.servlet lib or app?
>
> Mike
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Johan Compagner
Servoy