ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | architecture List | October 2003 Index

<--  Date Index  --> <--  Thread Index  -->

RE: AW: Enhydra and Jonas


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



<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.