Noel J. Bergman wrote:
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.You won't get the exception unless someone actually tries to use theugh. 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.
incorrect behavior.
Or do you believe that silently accepting requestswell, 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.
without honoring them is OK?
Define non-critical for a logging tool in athe listener mechanism is non-critical to smooth operation of the logging tool.
server environment?
Is the API intended to be public?
yep.
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.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?
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]