LDEV-3028 - “The servlet context has already been initialized” error in Application.log of Undertow deployments LDEV-3975 - ESAPI functions result in “CTOR threw exception” error with 22.214.171.124 extension LDEV-3978 - regression: Cflog stops writing to files LDEV-3980 - jdbc commit issues using transactions and hibernate LDEV-3976 - RamCache out of memory ignored LDEV-3979 - Regression: Custom cookie parsing now used over servlet’s cookies
Just one small fix since the 126.96.36.199-RC LDEV-3680 race condition in getRPCClassLoader
Give them a go and let us know here if you have any problems
In it, version numbers are mentioned as being a manual process
I did not imagine there would be a difference between 188.8.131.52-RC (what we tested) and the release (what I applied to production without testing) and I did not double check. That’s on me although a new rev number would have been a helpful indicator.
As we (the community) learn and improve - it would be my preference/vote to increment the version number when there are changes. Are there technical reasons this isn’t feasible if automated?
The meta question is how things like this keep slipping through ? I didn’t have time to test the RCs (sorry !), but the last time logging broke I produced a two-file repo case, for instance, and this time it’s even simpler because it seems there is no output at all for any logs that don’t specify the optional file argument.
Are these not being added to a test suite ? Can we (the community) help maintain a test suite some where ?
Depends on what “v6” means. Is it like Chrome/FireFox where v5.4 is arbitrarily bumped to v6 or is it more like semver where it has breaking changes ? If the latter then I think it’s worth fixing 5.x because who know what other bugs v6 has…