[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834746#comment-17834746 ] Nick Couchman commented on GUACAMOLE-1325: -- This may be what is required to get things to run under Tomcat 10.x; however, to fully achieve the swap to Jakarta EE there are quite a few classes that need the javax.* items migrated to their jakarta.* counterparts. [~z0rb]: I'm sure there will be a point at which we freeze the feature set, but I'm not sure that will be immediate - I think we probably want to get the 1.6.0 version released, first, before we make such a freeze - depending on how long that takes we can decide if we want to freeze it. Also, with the strategy we have with our branches - patch, main, and next - we should be able to commit changes like the Jakarta transition and Angular migration into the next branch, while still working on other items - patches or features - in main. Obviously the more changes we make the harder it will be to keep up the required migration, so I think a freeze will make sense at some point. > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Major > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834059#comment-17834059 ] Libor Svehlak commented on GUACAMOLE-1325: -- [~z0rb]: No, fork is not publicly available. Nevertheless as I have mentioned in some previous comment for guacamole-common it was needed to change just two files and it was simple search & replace javax.servlet => jakarta.servlet and javax.websocket => jakarta.websocket. If you need more than guacamole-common I expect more changes but they should be quite straightforward. > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Major > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830858#comment-17830858 ] Irmin Okic commented on GUACAMOLE-1325: --- Has any decision been made internally on this topic? Just asking if there is a rough plan which version might be the last with Tomcat 9 and at what point the move to 10 might happen. I am considering doing what Libor has done, forking and modifying guacamole-common. [~libor.svehlak] I suppose your fork is not publicly available somewhere? > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Major > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816923#comment-17816923
]
Irmin Okic commented on GUACAMOLE-1325:
---
[~vnick] My suggestions concerning the process were just to get the ball
rolling and without knowing the actual organization of the project, including
non-existing backporting strategy.
{quote}Why? Why can't you just open a pull request that only updates code in
guacamole-common?
{quote}
Specifically for this case, because of the pom inheritance between
guacamole-client and everything underneath. Starting to update guacamole-common
dependencies and probably java version too might explode in other modules, e.g.
guacamole-ext. If the updates are only done in guacamole-common overwriting the
inherited dependencies and settings, then the parent-child relationship loses
it's purpose anyway. Again, I don't know the implementation details to 100%
claim that this would happen, it's just what I expected from looking at the
poms.
It would indeed make the most sense to:
* avoid any magic rewriting packages
* avoid additional effort of backporting
* just freeze the current feature set for Tomcat 9 and continue development
for versions that will be there in the future. From which exact version of
1.x.x to make the jump again, I can't know. :D
But this is again without knowing what your project strategy and plans are.
Also I am not sure if you have important users/projects in mind that are
waiting for new features and fixes.
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Mathias
>Priority: Major
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816665#comment-17816665
]
Nick Couchman commented on GUACAMOLE-1325:
--
{quote}
This plus the migration away from AngularJS would be great choices for 2.0.
{quote}
After spending some time looking at this today, I think I'm pretty well in
favor of Guacamole 2.0 just making a clean break from the javax.* namespace to
the jakarta.* namespace and not bothering with dynamic loading capabilities. I
was thinking the issue was mainly the Tomcat 10.x servlet, but since *all*
javax namespaces are getting migrated, and since many of the dependencies we
use are starting to move in that direction (Google Guice, for example), it
seems like it may just be better to update everything and make sure we can get
all of the dependencies pulled up to the latest versions where they've migrated
to that space.
I remain pretty solidly opposed to trying to maintain any sort of
backward-compatible version of Guacamole or continue to release updates/fixes
for the 1.x series once we do that. It just creates too much work for this
project to handle. It already takes us quite a while to get some of the bigger
features and versions released, and, barring a large influx of developers
contributing to the project, it's probably more than we can handle.
I suspect most of the dependencies will update without a problem - the RADIUS
extension is the one that I can see being most problematic, since the jRADIUS
library we use hasn't been updated in years, but I think demand for RADIUS is
waning in favor of SSO platforms.
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Mathias
>Priority: Major
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816639#comment-17816639
]
Nick Couchman commented on GUACAMOLE-1325:
--
[~libor.svehlak]
{quote}
1. Switch to Tomcat 10 and drop the support for Tomcat 9 with the next
Guacamole version
Applicable only when there aren't too many Tomcat 9 users.
Has to be available as soon as possible (e.g. till end of 2024).
{quote}
As mentioned in my other reply, above, saying "next Guacamole version" is
problematic, particularly since it won't happen in 1.5.5. Also, how are we
going to determine "when there aren't too many Tomcat 9 users?"
{quote}
Forget about too complicate dynamic handling of two parallel Tomcat versions as
the old version is available just for limited time till EOL.
Split a Guacamole to two versions: one for "javax" (Tomcat 9) and another for
"jakarta" (Tomcat 10). Such approach is already taken by some OSS projects.
{quote}
* I'm firmly opposed to splitting Guacamole into two versions.
* The "too complicate dynamic handling" is already done in other places within
the Guacamole, surely we can make it work in this case, too, if we decide to go
that route rather than just making a clean break.
{quote}
I agree that solution is not very nice from architectural / pure technical
point of view but it is pragmatic approach and in each case the support for
Tomcat 9 will be dropped sooner or later.
{quote}
I don't think it's a good solution from a pragmatic viewpoint, either. It's an
attempt to "solve" the issue of lack of support for Tomcat 10.x very quickly,
but at the expense of work that will have to be done only a little further down
the road (I believe this is what we call "technical debt"). My opposition to
this approach is both architectural and pragmatic.
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Mathias
>Priority: Minor
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816637#comment-17816637
]
Nick Couchman commented on GUACAMOLE-1325:
--
[~z0rb]:
{quote}
Designate the current version (or one soon to be released) as the last version
supporting Tomcat 9, but allow backporting security fixes for vulnerabilities
with a medium to critical severity.
{quote}
No, I am not aligned with this approach, for a couple of different reasons:
* This doesn't specify what "current version" means. The "soon to be released"
version is 1.5.5, which is a bugfix version. We definitely will not designate
that one as the last supporting Tomcat 9 (javax.ee namespace). The next
non-bugfix release after that will _probably_ be 1.6.0, which has a
to-be-determined date, probably sometime this year, but, given Mike's opinion
that we would target the departure from the legacy Java EE framework for 2.0,
that would _not_ necessarily mean that 1.6.0 would be the last version to
support this (there could be a 1.6.1, or a 1.7.x, etc.). I think the best thing
to do is stick with what [~MathiasM] proposed and [~mjumper] (tentatively)
agreed to, which is that version 2.0, whenever that comes out, will make that
break.
* We have to be careful when we talk about "back-porting" fixes to previous
releases, as we don't back-port fixes and don't re-release old versions. We may
release additional "bugfix" releases (1.5.5, 1.5.6, etc.), but back-porting
fixes is not really something we've ever done, and I'm not sure now is a good
time to start - at least not for this particular issue.
* Assuming that we decide to make a clean break and stop supporting Tomcat 9.x
(javax.ee) and exclusively support Tomcat 10.x (jakarta.ee), I'm not sure I'm
in favor of doing any maintenance of versions of Guacamole that remain
compatible with the older namespace. In my opinion, we should choose one of the
two things and go with it - either A) build in the support for both namespaces
so that the software will work in Java Application Servers (Tomcat, etc.) that
support either one, or B) make a clean break and only support one going
forward. I don't like the idea of trying to juggle multiple back-/compatible
versions of Guacamole.
Obviously I'm not the final decision-maker on this, and there may be other
opinions, but those are mine :-).
{quote}
For pull-requests it would also be advantageous to have that in a separate
project. I guess there are many projects using only guacamole-common and may
want to supply fixes and improvements for it, but can't take the load of
properly maintaining the frontend...If I encounter something
unimplemented/unfixed and really want it done I may invest the time and make a
pull-request, but the frontend is completely unknown to me and it would mean
additional work.
{quote}
Why? Why can't you just open a pull request that only updates code in
guacamole-common? I don't think we've ever said that isn't possible or turned
down pull requests that only target the common code, and I don't see how having
a separate project for front-end versus guacamole-common would impact that?
Obviously you can't break the front-end with changes to guacamole-common, but
that's going to be true whether the code is in the same project/repo or not.
{quote}
I understand that most of the work done on guacamole is volunteer work, but
these topics are strategic, how things should be handled to improve project
performance.
{quote}
I know it's been said before, but the best thing to do is jump in and
contribute to the things that matter to you. Yes, some of them are "strategic"
and are going to require that the PMC "buy-in" to the changes you're making,
but opening pull requests and working with the committers for the project on
the changes that matter to you and how they can fit into the project is the
best way to move things along.
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Mathias
>Priority: Minor
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816627#comment-17816627
]
Libor Svehlak commented on GUACAMOLE-1325:
--
My pragmatic suggestion approach would be the following (in constraints like
limited development resources and time in mind):
1. Switch to Tomcat 10 and drop the support for Tomcat 9 with the next
Guacamole version
Applicable only when there aren't too many Tomcat 9 users.
Has to be available as soon as possible (e.g. till end of 2024).
2. Allow to use Tomcat 9 together with Tomcat 10 with a solution with a low
development effort
Forget about too complicate dynamic handling of two parallel Tomcat versions as
the old version is available just for limited time till EOL.
Split a Guacamole to two versions: one for "javax" (Tomcat 9) and another for
"jakarta" (Tomcat 10). Such approach is already taken by some OSS projects.
E.g. the next Gucamole version can be primarly focused on Tomcat 10 ("jakarta")
but a simple pre-compilation task for Tomcat 9 ("javax") can do a simple sed
replacement in sources from "jakarta.servlet" to older "javax.servlet,
"jakarta.websocket" to older "javax.websocket" etc.
Maybe replacement will be more complicate but IMHO it can be implemented much
faster than generic dynamic handling of different versions (which will be then
obsolete when Tomcat 9 reaches EOL).
I agree that solution is not very nice from architectural / pure technical
point of view but it is pragmatic approach and in each case the support for
Tomcat 9 will be dropped sooner or later. Then it is IMHO easier (with this
approach) to drop support for Tomcat 9 and keep just support for Tomcat 10.
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Mathias
>Priority: Minor
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816611#comment-17816611 ] Irmin Okic commented on GUACAMOLE-1325: --- [~libor.svehlak] That was my plan in case the vulnerabilities get to a point where they can't be mitigated. Thanks for confirming that it works! [~vnick] Would the following approach be acceptable: * Since the Tomcat 9 is approaching EOL and assuming guacamole has a good enough feature set as it is now for the projects using it ... Designate the current version (or one soon to be released) as the last version supporting Tomcat 9, but allow backporting security fixes for vulnerabilities with a medium to critical severity. The main branch could then start accepting pull-requests like the one Libor has suggested and moving toward Tomcat 10 and by extension the supported Spring Boot versions. This is kind of the way a lot of other projects handle this situation. There is then the topic of the frontend that [~mjumper] mentioned. For pull-requests it would also be advantageous to have that in a separate project. I guess there are many projects using only guacamole-common and may want to supply fixes and improvements for it, but can't take the load of properly maintaining the frontend. This would be the case for me. If I encounter something unimplemented/unfixed and really want it done I may invest the time and make a pull-request, but the frontend is completely unknown to me and it would mean additional work. I understand that most of the work done on guacamole is volunteer work, but these topics are strategic, how things should be handled to improve project performance. > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Minor > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816477#comment-17816477
]
Mike Jumper commented on GUACAMOLE-1325:
{quote}
Maybe it's a good time to move to Tomcat 10 with Guacamole 2.0 ?
{quote}
I agree. This plus the migration away from AngularJS would be great choices for
2.0.
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Mathias
>Priority: Minor
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812275#comment-17812275 ] Nick Couchman commented on GUACAMOLE-1325: -- Yes, it's true that just converting the javax -> jakarta instances is a simple change and can get Guacamole working under Tomcat 10 without issues. The challenge is that we would like to implement it in a way that is compatible with both namespaces - without maintaining two separate versions of Guacamole - which takes a bit more doing. It is totally doable, and, as has been mentioned before, has been done for other components of Guacamole where we need to support multiple namespaces dynamically, it just hasn't gotten the attention of anyone since Tomcat 9.x is still supported. I don't think we have a solid plan as to when this will happen - obviously getting it knocked out before Tomcat 9 goes EOL would be a good thing, but even prior to that this will become more painful for people as they upgrade and Tomcat 10 (and other platforms that use the jakarta namespace), so I would imagine it'll get more attention as the clamoring becomes louder. In short, the roadmap is: We want implement something that dynamically supports both namespaces, and it'll get done when someone has the time and inclination to get it done. > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Minor > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812180#comment-17812180 ] Libor Svehlak commented on GUACAMOLE-1325: -- [~z0rb]: Maybe this can help you. We use Guacamole 1.5.4 under Tomcat 10. We took original guacamole-common from guacamole-client-1.5.4.tar.gz, made a required changes javax -> jakarta (just two files GuacamoleHTTPTunnelServlet.java and GuacamoleWebSocketTunnelEndpoint.java are needed to patch) and build our own version. Please note that we use just core of the Guacamole with our own web application (integrating just guacamole-common and guacamole-common-js). If you use the whole Guacamole solution you may need to patch more files. But as I can see there are about 50 files which needs to be patched (in the whole guacamole-client-1.5.4.tar.gz) which is IMHO still manageable in a reasonable time. Of course maintaining both versions in parallel is much more work. I don't know the strategy of Guacamole team how long they want to still support Tomcat 9, e.g. till EOL of Tomcat 9? This would mean (without parallel support to Tomcat 10 and upcoming Tomcat 11) very hard times (for next few years?) for users trying to migrate to the newer Tomcat. Maybe [~vnick] can give us some hints about the planned roadmap. > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Minor > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810912#comment-17810912 ] Irmin Okic commented on GUACAMOLE-1325: --- I'm aware of it not necessarily getting picked up once the priority gets raised. I was thinking it may raise the visibility, if someone is picking up a task, might raise the chances of it getting seen. Also since Spring is the defacto standard, not being able to get security patches should warrant a higher priority. Currently I am also not able to fork this and give it a go because of time constraints. Similar with the volunteers no doubt ... Upgrading only guacamole-common would probably not be possible, since it is not a separate project. Looks like all or nothing. >From the README: "Each project contained here is completely independent of >guacamole-client and can be built separately, though the others may have to be >built first. If all projects are built using guacamole-client, Maven will take >care of the proper build order." Can be built, but probably not worked on >separately. :-/ > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Minor > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810507#comment-17810507 ] Irmin Okic commented on GUACAMOLE-1325: --- Hi, this issue should probably have a higher priority. It is not just that the Tomcat 10 support is not present. There is probably a larger issue that it does not support Spring Boot 3. Spring Boot 2 support has ended in November 2023: [https://spring.io/projects/spring-boot/#support] Spring Boot 3 is also not so new with the first version being released in November 2022. Upgrading a project using guacamole-common is not possible and therefore it is also not possible to pull in any transitive (including spring-boot) dependencies with security fixes. Can this ticket be upgraded in priority to maybe help move the upgrade forward? Any hints on how to maybe make this version of guacamole work with Spring Boot 3 would also be appreciated. > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole, guacamole-common, guacamole-ext >Affects Versions: 1.3.0, 1.4.0 >Reporter: Mathias >Priority: Minor > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400342#comment-17400342
]
Mathias commented on GUACAMOLE-1325:
I have used Tomcat 10.0.8 and modify $CATALINA_HOME/conf/context.xml with this
code:
{code:java}
{code}
I get this error into logs:
ERROR o.a.g.rest.RESTExceptionMapper - Unexpected internal error:
'javax.servlet.http.HttpServletRequest
org.apache.guacamole.net.auth.Credentials.getRequest()'
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0
>Reporter: Mathias
>Priority: Minor
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400013#comment-17400013
]
Josh Kayse commented on GUACAMOLE-1325:
---
[https://stackoverflow.com/a/66805452] states that you can modify the
{{context.xml}} or {{VirtualStore.xml}} to dynamic make it compatible with:
{code}
...
{code}
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0
>Reporter: Mathias
>Priority: Minor
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318137#comment-17318137 ] Mike Jumper commented on GUACAMOLE-1325: Welp, that is slightly annoying. With the HTTP tunnel having been written for the older API, a version of the same would need to be written for Servlet 5.0. Just as with WebSocket, that support will need to be dynamically selected based on what the servlet container supports. It sounds like we'll need to: * Provide some more abstract means of dynamically loading supported tunnel implementations within guacamole-ext. * Migrate away from direct reference of any part of the Java Servlet API within guacamole-ext's API, deprecating existing references. > Apache Tomcat 10.0 Servlet API incompatibility > -- > > Key: GUACAMOLE-1325 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Affects Versions: 1.3.0 >Reporter: Mathias >Priority: Minor > > Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat > 10.0.x requires a new Servlet 5.0 API. The Java package has changed from > javax.servlet to jakarta.servlet. > [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
