[
https://issues.apache.org/jira/browse/SOLR-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890974#comment-17890974
]
Gus Heck commented on SOLR-17503:
---------------------------------
{quote}"Jetty 12.x supports multiple servlet versions and we could stick with
javax.servlet instead of all the changes required to go to Jetty 11.x in
SOLR-16441 PR"
{quote}
I am not sure I understand exactly how that is possible. A key issue was the
use of the test framework and the creation of a MiniCloudSolrCluster that
expected javax.servlet.Request objects... if this "support" involves special
actions to mark things or anything like that it's not going to solve the issues
easily. A cleaner simple cut over seems preferable if possible.
> Umbrella: Move to Jakarta J2EE packages
> ---------------------------------------
>
> Key: SOLR-17503
> URL: https://issues.apache.org/jira/browse/SOLR-17503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 10.x
> Reporter: Gus Heck
> Priority: Blocker
> Fix For: 10.x
>
>
> In a recent migration from 8x to 9x I encountered a lot of issues where a
> client with a repository containing custom solr components and fixes was
> *still* unable to migrate to latest versions of critical packages like
> dropwizard and hibernate validator because those packages rely on jakarta
> packages, and even if it might be possible to re-arrange the decade plus old
> repository and builds to avoid conflict the work to do so is prohibitive.
> Solr needs to not be the stick in the mud holding folks back. This ticket is
> to collect/track tickets relating our dependency on the legacy javax classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
