Re-2: [ObjectWeb architecture] RE: AW: Enhydra and Jonas

[<markus.karg@xxxxxxxxx>]

But ain't each of that APIs provide that glue? At least I know that at least Monolog and java.util.logging both provide that customization glue: Both systems allow to customize multiple backens to any logging system as long as there is an adapter (maybe written manually) for that backend for that API.

 

Have Fun

Markus

 

 

Original Message	processed by Tobit InfoCenter
Subject:	Re: [ObjectWeb architecture] RE: AW: Enhydra and Jonas (24-Okt-2003 10:31)
From:	pascal.dechamboux@xxxxxxxxxxxxxxxxxxxx
To:	markus.karg@xxxxxxxxx

 

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

To: pascal.dechamboux@xxxxxxxxxxxxxxxxxxxx Cc: architecture@xxxxxxxxxxxxx