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]
