OK, so what about the
following approach:
First we have to define
some basics:
There are some
API’s (common-lgging, LogSink, Monolog, Sun API, Enhydra API, Barrcuda
API,….some more ?)
There are some
implementations (log4j, Sun implementation, old Enhydra implementation,…)
with different configuration mechanisms and different functions/features
There are configuration
GUIs (JonasAdmin for Monolog,…what else ?)
So if we have the following
scenario:
Some part “A”
(e.g. Tomcat) of my system using
Some logging API
“B” (e.g. common-logging) implemented by
Some adapter
“C” (have to build that ?) for redirecting logging to
The common lowest level
API (e.g. monolog ?, have to decide that) “D”
Implemented by logging
system “E” (e.g. log4j ?) which is configurable by
Configuration/management
GUI “F” (e.g. JonasAdmin ?)
Now lets look at the
requirements again :
We have to provide
adapters “C” for commonly used APIs (that are not the common lowest
level API)…today definitely for common-logging, Enhydra logging API,
Barracuda and may for Jetty-LogSink (if they do not change that…).
Directing output to
different targets is currently very well done by log4j for “E”,
right ? Are there better solutions ? Is there SNMP, Mail, web-service-call, JMS
message, SMS,… ?
Log4j definitely supports
different targets at once…
If we decide for the
above architecture, chances are good to have ONE central way “F”
for configuration of the ONE lowest level API-implementation “D”
and “E”. Of course there could be alternative scenarios but in ONE
running system it should be possible to have ONE “F” and therefore
ONE “D” and “E”.
JonasAdmin is currently
the only GUI I know (but I haven’t looked around yet…)
I think JonasAdmin does
currently NOT allow to configure the output directions…but I think that
could be done, right ?
I think
monolog/JonasAdmin/log4j allow conf changes without restart, right ? Only for
debugging levels or also for output direction ?
What about common logging
levels between e.g. common-logging and monolog / log4j ? Think this would be an
issue of the adapter “C” implementation.
Monolog already seems to
support some kind of “hierarchy” but I think “groups”
and “composition” topics are not there currently, right ?
How about directing
different debugging levels to different targets ? No idea if that can be done
today…
How about directing
different parts to different targets ? No idea if that can be done today…
I think the “automagic”-mode
for new parts / web-apps /etc. will stay a dream, but dreams should be
allowed…! Can live with a one-time manual configuration when installing
something (but ideally with the GUI !).
So currently
“D-E-F” looks good for “monolog-log4j-JonasAdmin” if we
decide to implement some “C”s, right ?
Any ideas for better
architectures or better “D-E-F” combinations ?
Alfred
-----Original
Message-----
From: "P. Déchamboux"
[mailto:pascal.dechamboux@xxxxxxxxxxxxxxxxxxxx]
Sent: Freitag, 24. Oktober 2003
10:38
To: markus.karg@xxxxxxxxx
Cc: architecture@xxxxxxxxxxxxx
Subject: Re: [ObjectWeb
architecture] RE: AW: Enhydra and Jonas
Hi
all,
I am quite in line with the problem Alfred raises. Being pragmatic, even if
there is a standard within Java (indeed having a unique API is the most
rational choice), it has come late and we will need to live with different
logging API for a long time. Reading the interesting list of Alfred, we can
even see that there are still functional requirements that are not covered by
current logging systems. Then, the real problem is not using a unique one or
die! We need to solve the integration problem (i.e., living with different
logging systems). We need to provide some kind of glue, which we can call
something like a logging configuration component, that provides a unique point
for configuring/managing logging with connectors to drive different logging
systems (or even logging system instances). I think that Monolog had started to
investigate this problem but we clearly need to dig further. I am ready to
participate to this investigation... Then do we need some kind of working group
or do we go on discussing it through the architecture mailing list ?
Pascal.
markus.karg@xxxxxxxxx wrote:
Alfred,
indeed each of the mentioned APIs is able to provide this, but has different API to call, so actually it is a question of the API for the implementor of the beans.
So maybe this might be the easist and most flexible solution:
Take a J2EE 1.4 conformant server. Then you'll have java.util.logging for free by guarantee without third party help. Then program your beans to use that API directly without assuming the server to come with any of that other mentioned APIs or not. Using another API would only works if that other server comes with that API OR you bring that API with you and make it run inside of that server (as it is the case with Log4J or Monolog).
Write your own adapter that provides a backend for that API, sending all log information to some of that well known and fully adjustable LAN management solutions (third party closed source; highly flexible and adjustable). Actually most large companies already have such a system and want to use that, and are able to customize it themselves without knowledge on any of that APIs.
Have Fun
Markus
-------- Original Message --------
Subject: [ObjectWeb architecture] RE: AW: Enhydra and Jonas (24-Okt-2003 9:13)
From: A.Madl@xxxxxxxxxxx
To: markus.karg@xxxxxxxxx
Interesting that discussions always tend to be "This OR that"...
But anyway, I'll try again to play some kind of "customer" and define my
requirements (just a first draft, requirements of customers can change :-)):
<requirements state="very early">
I would like to have a Jonas/Enhydra/application-installation containing
Objectweb services, other services, EJBs, web-services and web-apps from
many different sources.
(I do not want to get bothered with different logging APIs, logging
subsystems, etc.)
I want to direct my output to whatever makes sense on my platform or in my
usage scenario (NT Event log, rotating files, XML files, SNMP, Mail, web-
service call, JMS,...). One or many of them at once...
I want a very nice CENTRAL way (ideally a nice GUI) to configure the debug
levels of different parts of my environment (no matter if this is a Jonas
service, another service, an EJB, a web-app,...) and I want to do that for
ALL parts of my environment in the SAME way.
Of course changes in the configuration should be possible at runtime
without restarting anything !
I want to have COMMON logging level definitions / usage for all parts since
otherwise I would get crazy :-) Means: DEBUG is always DEBUG, INFO is
always INFO..., same or very similar meanings...
I want to have a hierarchical view of logging topics to "drill down" to
subcomponents and configure logging on different levels. This solution
should support "inheritance" from top to bottom in the component hierarchy.
Ideally the COMPOSITION of components (C used by A and C used by B) would
be visible so that I can set different logging levels for different usages
of the same component (C used by A has logging level "INFO", C used by B
has logging level "DEBUG").
I would like to define my own "groups" (independent of the hierarchy) of
parts and set logging levels or output direction for whole groups instead
for all parts individually. This would support debugging "scenarios" to
search for problems...
I want to direct logging output (again using the central configuration
application) of different parts to the SAME or to DIFFERENT places (web
application logs to XML, EJB logs to NT Event log,...)
I would like to direct logging output of different levels to different
places. "INFO" goes to the NT Eventlog (watched by my system management
software) "DEBUG" is going to a flat file for temporary use (I do not want
my system management to panic just because I am trying something there...)
If I add new parts to my system because I often search the Internet for new
/ nice building blocks, ideally the configuration application would show up
auto-"magically" new parts that I can configure for logging...(and I really
do NOT care which logging API the programmer was using !)
My supplier or integrator...has to do the rest to enable that for me :-)
</requirements>
So our question should be now: How can we help the poor supplier/integrator
to fulfil these requirements ? If we answer this question nicely, logging
in Jonas / Enhydra /etc. will be a success.
Viewing the issue this way I think it is NOT a question "which logging API
do I use for my new nice component / application / whatever" but more a
question of the "infrastructure" that it is running on and what this
infrastructure provides to "glue" everything together to fulfil these (
maybe still incomplete) requirements.
What could this mean for Objectweb ?
I think we should concentrate on providing the "glue" and maybe other parts
that are necessary to support this scenario instead of discussing pros and
cons of APIs.
Greetings.
Alfred
To: gerard.vandome@xxxxxxxxxxxxx
Cc: christophe.ney@xxxxxxxxxxxxx
I.Raicevic@xxxxxxxxxxx
Francois.Exertier@xxxxxxxx
Andre.Freyssinet@xxxxxxxxxxxx
Jean-Frederic.Mesnil@xxxxxxxxxxxx
architecture@xxxxxxxxxxxxx
--
|
|
|
Pascal DECHAMBOUX
France Télécom R&D (DTL/ASR)
28, chemin du vieux chêne - BP98
38243 MEYLAN Cedex (France)
|
e-mail: pascal.dechamboux@xxxxxxxxxxxxxxxxxxxx
phone: (33) 476 76 44 16
fax: (33) 476 76 45 57
|
