> 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.
Consistent logging throughout James and the Mailets. This includes log destinations, formatting, filtering etc. > -----Original Message----- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 2:51 PM > To: James Developers List > Subject: RE: [Mailet API] Logging Proposal > > > > 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. > > Any mailet application built according to the API and in > spirit with it, according to the specification document as > well as the code, will be interoperable with any container > similarly built and any other application. > > Logging is a "leaf" on the tree of dependance, I can see how > other services, such as repository or spool providers need to > be controled in order to ensure interoperability, being > "nodes" on that tree. The solution to providing logging is > that the mailet application developer distributes their > preferred logging classes with their application, because in > that situation interoperability is not compromised, the > central purpose of the API is still served in spirit and in > detail. There must be zillions of servlet applications that > provide 100% of the logging service they require, and still > comply with the API. > > I'm actually coming to the conclusion that providing logging > in the API would make logging more cumbersome for > sophisticated users, over engineered for trivial uses and > discourage many users from making their own architectural > decison on a matter which is of *no* relevance to us. > > 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. > > d. > > > -- > To unsubscribe, e-mail: > <mailto:james-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
