> > The downside of (2) is that since logging, etc... are *always*
> > needed, every implementor will put in his, and you can say
> > goodbye to interoperability.
> Ok, this is just Not True.
> Interoperability will be provided by the API, logging won't affect this.
I disagree. If we say that access to logging is important for mailets, and
we do not provide access to logging in the API, then his statement is
correct, because a mailet that accesses logging services will have to do so
by means that are not guaranteed to be provided by other mailet containers.
> The solution to providing logging is that the mailet application developer
> distributes their preferred logging classes
Yes, they distribute the implementation, but there must be a standard
INTERFACE that mailet code can rely upon to access logging services,
otherwise logging is platform specific.
> I'm actually coming to the conclusion that providing logging in the API
> would make logging more cumbersome for sophisticated users
The lack of it would be worse.
> I'd like to know why anyone would expect sophistcated logging service to
be
> provided by the API, and what stories or use cases they can advance to
> support this.
Uh ... because every component in a server product ought to have access to
logging services? For stories and use cases, I refer you to James, Tomcat,
and the myriad logging implementations currently available. They exist to
address needs, not because people had time on their hands.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
