> Is commons-logging actually done? If I recall, it just showed up? Paulo, > any chance we can see what you are thinking about?
Sorry, I was trying to finish the configuration stuff and add some samples
to make its use clear, but my "other" project and Christmas got in the way.
(Suddenly I realized that today was the last chance to buy my girlfriend's
presents and how it would be such a bad idea to skip it.)
I am attaching what I have, still in my current internal packaging
(krankikom.log). I will change the package name it this goes further in the
commons.
The packages I have at the moment are:
- krankikom.log
Common interface and other common use classes;
- krankikom.log.wrappers
The wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
- krankikom.log.simple
A very simple logger I use. It is still here because of the "Primordial
Logger" idea that Geir implemented at Velocity.
*** Status on the other "features" I promised:
> >> - Log4J has its own XML configuration and LogKit gets one;
I am not sure I should include LogKit XML configuration here. This is
what
I will do for my company work but I think this should an extra package
for
LogKit instead of part of Avalon's Excalibur project. So, after I finish
taking it out of Excalibur (already started) I will try to talk with the
Avalon guys about this idea (could use some help).
> >> - Ability to use a hierarchy of loggers in an API independent way.
> >> Only the configuration is API dependent.
This is what I am working on. It is a very simple properties based
configuration scheme with which you can configure in a simple way some
common features of each logging API (and maybe some specific ones).
All the logging APIs allow you at least to define a hierarchy, to log
to a file with a rotating scheme, etc.
It is a little step further of what you can find at Velocity: you give
an ordered list of Logger factories (one for each Logging API supported)
and the system will try (following the list's order) to get one of them
working. The first factory to successfully load its API will then try to
build the given configuration.
> >> Will soon (next week) include simple property configuration.
As stated above I already started it and wanted to have it ready before
delivering this... before Christmas took over. =;o)
> >> Still no plans on evolving the JDK 1.4 Logging API.
It is a piece of crap (I was reading the Javadocs yesterday) but I
think I can include it in the property based configuration thing.
<rant>
Man, according to the Javadocs that Logger is bloated with crap! Loads
of helper methods. A mess! And then, after bloating the logger they
had no time to provide more logging targets and formatting. Formatting
documentation looks rather incomplete.
I sure hope that the final stuff is better than what I saw in the online
Javadocs.
</rant>
Should I look at the specs? Do those promise anything a bit better?
*** The krankikom.simple package and the primordial logger:
The idea is to log whatever happens before the logger is initialized to an
in memory log event list that will than be dumped on whatever logger is
loaded. There is something like this in Velocity and I find it useful.
I use the rest of the SimpleLogger stuff to perform simple logging if no
other logger is there. For me it works fine (for a large framework it is a
small addition) but I am not sure this makes sense for the commons.
I can cut it to the essential for the Primordial Logger to work.
*** Other Logging stuff I have:
- AbstractLoggable with i18n:
I have an "AbstractLoggable" (see the code to understand what this is)
with simple i18n support using the older (property based) i18n stuff
at Avalon. It is interesting but it is connected to the i18n stuff.
- AbstractLoggable with further information on the "logged Object":
This one prefixes each message with the logged object class name and
an integer identifier. I added it to check if my database connection
pool and other related classes were not "forgetting" any database
Connection.
Any interest in things like this?
*** Conclusion
As you will see, most of it is Avalon code. The Commons-Avalon-Turbine
synergy is obvious (I will go to that thread too).
IMHO, Avalon can still improve on separating components from some
framework dependencies. Notice however that there is already a trend
in that direction and that MANY components are really easy to "extract".
What I see is that with a bit of wrapping here and better separation of
concerns there it can still improve. However, they should not have to
change their priorities and, as Peter says, we can always do it
ourselves when convenient.
It may sound like having duplicate work, but it might be the only way
to check if the Commons evolution of some components is compatible with
the Avalon evolution. If it is, I am sure we will find a way to reduce
this duplication, otherwise it will have to evolve separately.
I hope this is useful to you.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 22, 2001 3:17 PM
> To: Jakarta Commons Developers List
> Subject: Re: (Logging)[Proposal] A little refactoring
>
>
> On 12/21/01 12:48 PM, "robert burrell donkin"
> <[EMAIL PROTECTED]> wrote:
>
> > commons-logging is currently broken. i think that it shound be fixed.
> >
> > maybe paulo's suggestion would make more sense as a competing branch -
> > commons-logging 2.0? that way, people can take a look at the actual code
> > but we don't have to stop development on other components until it's
> > finished.
> >
>
>
> Is commons-logging actually done? If I recall, it just showed up? Paulo,
> any chance we can see what you are thinking about?
>
>
> > - robert
> >
> >
> > On Thursday, December 20, 2001, at 11:23 PM, Paulo Gaspar wrote:
> >
> >> That was THE reason why I adopted Avalon new wrappers instead. I ported
> >> them out of Avalon and they work just fine. There are NO dependencies
> >> from the rest of the framework except for a formatter that can be
> >> dropped.
> >>
> >> I also improved (IMHO) an existing AbstractLoggable class and I am now
> >> porting an XML based configurator for LogKit from Avalon
> Excalibur. This
> >> one has more dependencies but it is ok.
> >>
> >> Next I will adapt the simple property configuration code for LogKit and
> >> Log4J used at Velocity, (will looking at Turbine too).
> >>
> >> So, this set includes:
> >> - Wrappers for Log4J, LogKit and the JDK 1.4 Logging API;
> >> - Really simple internal logger + NoOp logger;
> >> - Log4J has its own XML configuration and LogKit gets one;
> >> - Ability to use a hierarchy of loggers in an API independent way.
> >> Only the configuration is API dependent.
> >>
> >> Will soon (next week) include simple property configuration.
> >>
> >> Still no plans on evolving the JDK 1.4 Logging API.
> >>
> >>
> >> This is the best logging code I found around Jakarta. It just picked
> >> it from several projects and would like to see it together in the
> >> Commons where it would have a wider use. And it is working fine
> >> across a 500 class and 75 Kloc piece of code.
.........
<<attachment: AnyLogger.zip>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
