[
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)
