On 03/05/2023 20:02, Christopher Schultz wrote:
<snip/>
But my question is whether or not this is something that Tomcat should
be working-around. IMO the parent ClassLoader is buggy and should be
fixed, but it may be difficult or impossible to fix the parent, so it
may be worth it.
We could even log it including the class name of the offending ClassLoader.
WDYT?
The general approach we have taken is that we don't work-around bugs in
third-party products unless:
- the third-party vendor is (known to be) slow to respond to bugs
- there is no other viable workaround (including switching vendors)
- the bug impacts a reasonable proportion of Tomcat users
The complexity of the workaround in Tomcat vs the severity of the issue
is also a consideration.
We also want to encourage adherence to the relevant specifications.
All of the above is subjective.
For commercial software, the general idea is to encourage users to put
pressure on vendors to fix the bugs rather than expect us to - just
because we are more responsive. This is especially true for commercial
organizations using commercial software where there should be a support
contract in place.
For open source software, the general idea is to encourage users to
engage with the project concerned. Open a bug, provide a PR, contribute
and support that project.
The GitHub project in question hasn't had any activity since 2017 and
the GitHub organization hasn't had any activity since 2019. There are no
forks of the project.
It looks like the code has never been released so I am assuming the OP
has compiled it locally.
The fix in Tomcat is simple, but so is the fix in the problematic library.
I think the initial position is that the OP needs to try and get this
fixed. Whether that means creating a fork (it is ALv2 so that is easy),
seeing if the CodeGerm team can be persuaded to accept a PR, finding an
alternative library or something else is up to the OP.
Given the options the OP has for addressing this - including a (private)
fork, I don't think this is something that should be fixed in Tomcat.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
