FYI An interesting read from another java mailing list. I apologise for duplication for those that receive this twice. Scott ----------------------------------------------------------- This e-mail is solely for the use of the intended recepient and may contain information which is confidential or privileged. Unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and then delete the original e-mail. -----------------------------------------------------------
With particular reference to Section 2.18, Remote access and serialization, automatically converting parameters to Strings is wrong. If the user logs something which is not Serializable, and then tries to serialize it, that's their problem. OTOH, if the user deliberately logs something which is Serializable, and you turn it into a String, that's vandalism. Handlers and Formatters should be Serializable so that you can get information about where to log to from another process or read it from a file. How is RMI ever going to be useful if everybody decides serialization is too hard? It is not necessary to preserve the entire state of (for example) a Handler. The SocketHandler could be Serialized with a host and port number, then the socket could be reopened after deserialization. That's what writeObject and readObject are for. If Handler and Formatter were interfaces, I could rewrite the standard ones to do what I want, but they're not. This design decision is beyond me. There is a lot of stuff in the Handler class which I don't much like and would rather not have: Handler(Formatter) / setFormatter(Formatter) - if this handler doesn't do output (as many may not), what will it use this for? getEncoding() / setEncoding(String) - shouldn't these be attributes of the Formatter? getException() / setException(Exception) - are these present merely to make the Handler non re-entrant? getFilter() / setFilter(Filter) - only required if the Handler actually does filtering. isLoggable(LogRecord) - I can understand that getLevel() is useful to allow discarding of messages earlier down the Handler chain, but why would you ask a Handler if it was going to log something. Just publish the LogRecord and mind your own business. Similarly, Logger is a bit of a horror of a class. Firstly, all of the log levels are enshrined as methods, which means that if you do redefine the levels (and everybody always does), then too bad, Logger doesn't support them. The getFilter() / getHandlers() and related methods worry me as well, because it's not really any business of the user of logging what happens to the messages after they are published. Which reminds me, I am surprised there's no publish(LogRecord) in Logger. That means that even if you do care enough about levels / content / whatever to subclass LogRecord, you can't publish it anyway. Everything is conspiring to stop you from doing what you need to! It worries me that the only way to pass extra information into the Logger is in the Object[] parameter. When we released our Logging package to the rest of Mincom, the first thing other groups asked for was the ability to log different messages to different files. This means they had to add a parameter which you could use to figure out the file. OK, so the way to do this in JSR047 would be to use a different Logger attached to a different Handler for each of the destinations that you wanted. This effectively duplicates the logging topology once for each destination, and gets complicated if the destinations are not fixed. It would be easier to allow the extra parameter to ride along with the LogRecord and let the Handler look at it to decide what to do. For this reason, all of the methods on our Logger equivalent take an optional parameter which is a Map, so you can tack on any information you will need later on, no matter what it is. LogRecord has support for plenty of fields, but no support for any that I want to add. (Similarly, the DTD for the XMLFormatter doesn't support adding arbitrary values.) Reading the APIs for the LogManager and Handler classes, I get the impression that this is pretty much a two-tier architecture - usually, Loggers send their LogRecords to global Handlers. Our system allows an arbitrary graph of Handlers, which process LogRecords in some way (including adding data, filtering them out, caching them), and forward them to other Handlers, as defined by the graph. At the moment the graph is statically built in code, but we have a plan to One Day define it in XML, so that a new logging system can be installed simply by swapping in a file. JSR 047 may be able to be made to fit this model, but given that there are no obvious methods to support it (for example, Handler has no addHandler(Handler) method); and plenty of methods which explicitly don't support it (for example, LogManager.addGlobalHandler(Handler)), I doubt that it would be easy. THAT'S WHAT I REALLY DON'T LIKE ABOUT THIS API - if you don't like it, it's not easy to change it. And I know it is not so good that everybody will decide it is everything they need. The designers have to understand that although they can imagine a lot of things, they cannot imagine all of the things that people will want to use the API for, and I believe they have been negligent in failing to allow room for additional functionality to be added on. In particular, use of large and complicated abstract classes rather than small interfaces is pretty poor design. Perhaps the best analogy I can draw to existing APIs is that of java.text.MessageFormat. That class initially assumed that you would use no more than 10 substitution patterns, and that you would only use them once each. I couldn't believe it when I read the source code trying to debug my program. This API is similar in the naive assumptions it makes about the limited way in which people will try to use it. John -- Dr John Farrell - Research Architect - Mincom Limited I don't suffer from stress, I suffer from idiots. ----------------------------- Mincom wants no credit for anything I say: This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please delete it and notify the sender. The contents of this E-mail are the opinion of the writer only and are not endorsed by Mincom Limited unless expressly stated otherwise. To unsubscribe, send a message to [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ----------------------------------------------------------- This message has been scanned by MailSweeper. -----------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
