Regression: felix log growing

Hi . This is a chance, but we’ll have to address that in the July sprint, as we can’t hold up the current RC any longer. Stay tuned.

Thank you for your wizardry, !

Is there a chance that this could be backported to the release series?

#2 is also not possible because that class would the be loaded by the core and the loader cannot cannot have a reference to the core, as long any class of the core is referenced somewhere, the core cannot be flushed and replaced when necessary. that means the core must also remove that reference when unloaded. i think the better solutions is #3, that way we simply update the class on bytecode level and the class and classloader remains.

actually #1 is already in place in the loader and the core

yes we could do that, but only for upcoming Lucee versions. Problem is Lucee does not (yet) provide the loader version to the REST service.

I personally don’t like that at all, for me is important that an update of the loader is optional and never required and a message like this would suggest otherwise.

if you think this is an important fix for everybody to have, we should invest that time to have a patch in the core for this, i see 3 approaches to “solve” this in the core

1. the controller should check the size of the felix.log and if necessary rotate the file and delete if necessary older versions. so we do not reduce the amount of entries, but we clean up if necessary, as we do for all lucee logs.

2. we will check if we can modify the logger after loading felix from the core, i actually checked this when i was implementing the fix and could not find anything, but i will dig a little deeper

3. with help of java bytecode rewriting we rewrite the class in question dynamically on the fly, actually that would be the easiest solution and sounds like fun to do