> I agree that it is a good idea to have a lighter weight abstraction, but
> that should not prevent replacing a current broken implementation (not
> abstraction) esp. as it has already been tested and does not exhibit the
> leak. Sure, can hold off...
But you did introduce an entirely new abstraction, the
ResettableTimeGuardedCommandMap. Or am I mixing proposals?
>
> Fails to address the already stated logging/validation concerns that
> should be localized in the server class, as per my earlier post.
> Logging can be in one log file per protocol or one log file per
> server.
How are you defining the terms? By server do you mean James? Within James,
server == service == protocol.
> > Exposes member variables directly, rather than by 'getter' methods.
> Isn't a final variable in a package scoped immutable object better
> than calling n getters ?
Not in my mind. The expense of a simple getter is not significant, and
certainly not worth tossing off implementation hiding. Also, it is a fun
activity for some friends of mine to demonstrate that final isn't. If you
really want immutable data, you do it with read-only properties.
The bigger win in this change is that Peter adopted the single configuration
object that you, yourself, have promoted several times. He changed the
interface from calling n setters to calling a single method, passing an
interface to the immutable service-wide configuration data. This brings it
back closer to the Configure approach, but with an optimized config.
> n getter would make handlers more heavyweight(orig. concern)
> and may end up being a sizable chunk of code
This is backwards. The getters are on the config, not the handler. From
the handler's perspective, there is one configuration method for setting the
shared data. The only question thereafter is does it do:
serviceConfig.X or serviceConfig.getX()
> There is one Params object for n handlers and it is passed into the
handler
> constructor.
Regardless of where it is passed, what you're suggesting is that it should
be:
serviceConfig.timeout instead of serviceConfig.getTimeout()
As I said, I don't see a justification to abandon implementation hiding.
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
