Stefano Bagnara wrote:
> Currently I cast my veto on this change (I also wrote I didn't like this
> change in a previous message).
"Like" is not a technical justification. I don't like Maven (which actually
HAS issues, unlike this change). And I don't like memory leaks, even ones that
I am told should be closed without being fixed because they are a figment of my
imagination.
> This patch introduce new hardcoded dependencies between components and
> we worked hard to remove them everywhere.
So what? It is the simplest fix. The alternative is to backport the more
complex changes from trunk, but as Norman says, the full fix in trunk is more
complex than people wanted to backport. If we were going to keep development
v2.3 extensively, I'd agree on backporting the more complex changes from trunk,
but this is a dead-end fix that addresses the problem in exactly the same
manner.
> Have you tested the solution using the system property or the security
> property? I think we should fix it using that solution.
Why? This is the same fix that is in trunk, except for the silly debate over
static vs assembly, and no one is proposing to keep this around in future major
releases. We know that this fix works, and does not have any side-effects.
Why would I want to use a un-bounded, time-based, cache when everywhere else we
use a bounded, properly managed, DNS cache? And why would I want BOTH? This
change is the one that we have made everywhere else, and missed in these spots.
So I see two choices: we keep it or we backport the more complex code from
trunk.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
