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

[Gérard Vandome <gerard.vandome@xxxxxxxxxxxxx>]

I fully agree that we have to take into account application developper 
requirements which will use java.util.logging  (as mentionned by Markus) and 
adminstrator requirements (as mentionned by by Alfred).
Another thing to be include in the picture for J2EE is Apache server (and 
mod_jk).

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
>
>   ------------------------------------------------------------------------
>
> --
> You receive this message as a subscriber of the architecture@xxxxxxxxxxxxx 
> mailing list.
> To unsubscribe: mailto:architecture-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service homepage: http://www.objectweb.org/wws

--
Gérard Vandôme
ObjectWeb Consortium www.objectweb.org
Gerard.Vandome@xxxxxxxxxxxxx +33 (0)4 76 29 76 25