On 26/08/2020 18:43, Christopher Schultz wrote:
<snip/>
> Is there a particular reason we don't just shade the commons-dbcp and
> commons-pool code at build-time rather than manually merging-in
> patches to our private copy?
The short answer is greater flexibility.
The longer answer is that there are various reasons and that the
relative importance of those reasons has varied over time and between
components. They include:
- the ability to remove code we don't need / want
- we only use a small subset of BCEL
- we generally remove deprecated code immediately
- we ignore parts of FileUpload and 8.5.x ignores part of DBCP
- the ability to fix issues / avoid regressions
- there was an 'improvement' in the DBCP abandoned connection tracing
that caused problems so we backed that change out in our copy
- we have applied various fixes / clean-up globally to the Tomcat code
base over time and then contributed them to Commons (there are a few
of those we still need to contribute)
- the ability to handle the Java EE / Jakarta EE transition (both DBCP
and FileUpload have Java EE / Jakarta EE imports)
- the ability to update to any tag or commit
- the ability to skip commits that make use of newer Java features (e.g.
lamdas) that are not available in the Java version we have to compile
with
My sense currently is that setting up shading and then handling the
various edge cases is more work than generating a patch every ~6 months,
applying it and dealing with a small number of conflicts.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
