Mail Archive Home | architecture List | October 2003 Index
| <-- Date Index --> | <-- Thread Index --> |
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@xxxxxxxxxInteresting 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
| <-- Date Index --> | <-- Thread Index --> |
Powered by MHonArc.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.