On Tue, 31 Jul 2001 22:42, Berin Loritsch wrote: > Peter Donald wrote: > > Hi, > > > > I would like to deprecate ContextStack. As I have said before I regret > > ever putting it in there because it encourage extremely bad practices ;) > > Now that we have ContextMap object (which is more secure/safe) most of > > the use cases of ContextStack have been removed. > > > > While we probably can't ever remove ContextStack because it would cause > > too many incompatible changes we can at least deprecate it so that users > > will be discouraged from using it. Thoughts? > > > > BTW I just updated whitepaper to describes uses of ContextMap which may > > be useful to reference (and tell me about all my spelling/gramatical > > mistakes ;]). > > How many more changes do you forsee in the near future?
locally I have hacked up version of DB log targets, JMS topic and JMS queue log targets, an extremely crappy rmi log target aswell. None of these are production ready or even tested extensively so I don't want to commit them just yet. > I propose that once LogKit is stable again, we release it as 1.0 final > (with ContextStack deprecated). I think the only unstable thing atm momment is FileTarget which I may have to modify in near future. (Testing synchronization on hotspot is a PITA and may prove to point out weaknesses). As I am currently ... errr ... looking for work ;) ... and thus have a bit of spare time I may be able to get it stable by next weekend (then again I may not ... ). Melbournes got a crappy contracting environment atm ;( > Next, I suggest we each describe what we like and dislike about the LogKit, > with a focus on moving toward 2.0. This redesign will allow us to remove > all the cruft. hmmm ... maybe I should commit my TODO list. My pet hates are currently * have to extend PatternHandler to add extra "options" instead you should be able to provide any object that implements OptionHandler (or similar). * extend above point to all "serialization" mechanisms (ie MessageBuilder and MessageAttributes for JMS, SQLBuilder and SQLColumn for DB and various serialization strategies for socket based comms). * don't have stable versions of JMS/DB/RMI or socket based targets and thus unless you can use syslogd you can not use logkit from EJBs or embedded in other app servers. * A few synchronization errors potentially exist in some LogTargets (need more research). Will only occur on symantec JVMs and Suns server hotspot JVMs though ... neither of which I use regularly. Mainly occurs because of the crazy optimizations that they can do that completely discard operation order unless guarded with a synchronized section. The only problem is fixing it will slow down 1.2 JVMs ;( * think about bringing semantics into line with standard java terminology. ie LogEventListener instead of LogTarget, LogEventProcessor for things that modify on way through LogSink/Serializer for writing of log events * Rolling files that have configurable roll conditions (time based or size of log file based) and pluggable destinations (how big is "cycle" or "rotation" of logs files, how do we name log files (ie use PatterFormatter or similar), etc * LogDecorators that add information to ContextMap (like method called or thread id or ...) * Heartbeat LogEvents to distributed listeners (ie basically to test JMS/Socket/DB/whatever is still alive and also to tell listener that the application is still alive). * Finish making all of LogEvent serializable (for better RMI and serialization schemes) * throw away ContextStack * Consider the implications and possibility of making Logger serializable so that we can support JINI * Consider adding sequence numbers to LogEvents. The sequence could be generated per logger, per hierarchy, global or other. The start id and increment should be configurable. * Create a LogProvider interface that can determine topology more effectively. Currently we require a hierarchial topology but using a Provider would allow other alternate implementations. * parasitic stealing of ErrorHandler from Log4j ;) and safer implementation * better documentation for whitepaper * a getting started document * a short list of targets Some of them are wishes and some are things that I think will/should be done with current iteration. > Another alternative is to have a "compatibility layer" in an additional jar > so that the deprecated way of doing things can still be supported, but the > main distribution is uncluttered. Thats what I have done atm and was going to keep around for ages. Basically everything in src/compat is for backwards compatability purposes only. > I do not advise moving forward in either of those directions without a > Final Release first. That would be bad. Agreed. I want two more releases before final though. One to make sure everything inside LogKit is backwards compatible and stable. Another to add a stable logtarget for use in EJBs (JMS is easiest but high resource usage so DB may be best method). If both of those are succesful then release a final version. Most of these things are based on my experience trying to build Ottolith. For those who are not familiar with it, Ottolith was a centralized logging server that collected Log events from multiple clients and then used rules/strategies to deal with them. It could also do things like send SMS/ICQ/Pager/Jabber messages when critical failures occured. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
