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?

(...)

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]

Reply via email to