Leo Simons wrote:
Noel J. Bergman wrote:
ugh. With a logging tool, you want as little exceptions as possible, as
"not completely correct" behaviour of the logging toolkit in
non-critical areas like this is ok.
You won't get the exception unless someone actually tries to use the
incorrect behavior.
granted. But is it incorrect? It's good to be able to override the
listener in use. The contract is that the last listener put in is the
listener used.
Or do you believe that silently accepting requests
without honoring them is OK?
well, my line of thought is that anyone who will call addListener for
a second time will have knowledge of whether a listener was already
added, and will know that it is acceptable to override that listener
with a replacement listener.
Define non-critical for a logging tool in a
server environment?
the listener mechanism is non-critical to smooth operation of the
logging tool.
Is the API intended to be public?
yep.
What is the expected
behavior in an environment assembled from independent units if two
people
attempt to use the the same resource, in this case a unicast listener?
it'll stink (in public API terms, the behaviour is unspecified), but
it should also not happen. For each "independent unit", you need an
independent hierarchy.
And here we have the implicit assumption that a logkit-using
environment will follow IoC patterns properly. Is that a bad assumption?
Yes.
Cheers, Steve.
(...)
it's late, I'm not thinking too well anymore. C ya tomorrow!
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
