You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2004/06/06 20:18:28 UTC
Starting work on UGLI
Hello,
While working on the internal log4j logging, it occurred to me that it
could be very useful to synthesize log4j's core user interface in its
own package. I'd like to call this package Universal Generic Logging
Interface or UGLI (pun intended).
The word "universal" stands for applicability in all contexts,
including stand alone applications, containers (EJB, Servlet, Nano,
Pico, Avalon, whatever) and most importantly in specialized
libraries. The word generic stands for very simple, with an absolute
separation between the logging interface required to access logging on
one hand and configuration of the logging system on the other.
Given the lessons learned from past experience, in particular wrt
extreme simplicity and generality, it is expected that UGLI will be
quickly adopted by many developers. However, even if that does not
happen and developers chose to ignore UGLI, log4j itself will benefit
from the conceptual clarity it brings to the table.
Note that UGLI will be strictly an addition. Thus, developers could
continue to use the existing log4j API as is. Alternatively, they
would be able to switch to UGLI if they chose to do so. Thus, UGLI is
not expected to impact backward compatibility of existing log4j
deployments.
I am CCing general@logging, avalon-dev and commons-dev to elicit input
for this endeavor. Actual code to follow.
Cheerio,
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Starting work on UGLI
Posted by Paul Smith <ps...@minotaur.apache.org>.
>
> The word "universal" stands for applicability in all contexts,
> including stand alone applications, containers (EJB, Servlet, Nano,
> Pico, Avalon, whatever) and most importantly in specialized
> libraries. The word generic stands for very simple, with an absolute
> separation between the logging interface required to access logging on
> one hand and configuration of the logging system on the other.
>
This would simplify a lot. We should all get behind this if possible. I
am assuming this is THE 'common' Logger interface. Is there any other
scope involved in this suggestion Ceki? (ie. a LoggerFactory discovery
process?)
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Starting work on UGLI
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 08 June 2004 05:44, Jörg Hohwiller wrote:
> Hi Adam,
>
> I hope I am not getting on the nerves of some members of this list, but I
> had to write this.
Please note that the discussion has moved to general@logging.apache.org
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Starting work on UGLI
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Hi Adam,
I hope I am not getting on the nerves of some members of this list, but I had
to write this.
On Monday 07 June 2004 16:07, Adam R. B. Jack wrote:
> > I am CCing general@logging, avalon-dev and commons-dev to elicit input
> > for this endeavor.
>
> I'm no expert in this area, simply an external user (with no insights into
> history/politics/whatever). That said, I'm not shy to provide my input...
Thanks for writing this mail. It hits what I wanted to say with my mail
"commons-configuration and commons-logging". I am an external user as well
and am not the right person to give an answer to your mail, but I want to
emphasise what you wrote.
>
> I've loved logging (log4j, simple), I've hated logging (for becoming a
> pain). I've never had good experiences with commons-logging in my
> environments (not saying I could do better, I recognize the challenge is
> non-trivial), but I accept it is currently a *necessary evil* given
> Javasoft adding to the mix w/ JDK logging. Logging users just ought not
> suffer the pain.
>
> If UGLI is a way to bring /commons-logging/ into the fold of logging
> services & provided as a globally available service, I could be +1 for that
> ..
>
> That said, a few things:
>
> 1) I don't know the two communities, but one thing I like about C-L being
> in 'user space' is it is clearly a user advocate w/o the temptations to
> extend the API. We see (from the recent Gump failures) how many folks
> depend upon C-L already, but maybe putting it into a logging services
> community would open it up to more folks, including container writers.
>
> 2) I know C-L has a hard life, it is trying to sit on top of so much, but I
> find it's need/attempt to call/configure logging packages a problem. I
> don't know if I am expressing some form of IOC thought here, but when
> working on Depot, even C-L falls down. We (as a library) wanted to plug in
> to Ant, and we didn't want to force the C-L to Ant bridge. Basically, we
> wrote our own (yet another) logging that was simply a listener pattern, and
> plugged in an Ant logger listener, or a commons logging listener, as
> appropriate. Works nicely, but I don't want to write that code. I'd like
> UGLI as a logging abstraction that all containers can agree upon (Ant as a
> container, an application as a container) and have the environment provide
> it.
That is what I am dreaming of: "a logging abstraction that all (containers)
can agree upon"
>
> 3) Forgive me, but ... would UGLI (with nose holding) be able to sit under
> JDK logging? Surely folks ought be able to just use that. Ugly or not, the
> JDK solution is going to be there inside any recent Java VM. Is that not
> sufficiently simple?
I agree on both. It is ugly but if all would use it, it is what I am dreaming
of (is that what they call a nightmare - just kidding :) ).
>
> Right now, logging is simple, but real-world logging has become way too
> complex, in too many environments. Something needs to give.
>
> regards,
>
> Adam
Regards
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Starting work on UGLI
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I am CCing general@logging, avalon-dev and commons-dev to elicit input
> for this endeavor.
I'm no expert in this area, simply an external user (with no insights into
history/politics/whatever). That said, I'm not shy to provide my input...
I've loved logging (log4j, simple), I've hated logging (for becoming a
pain). I've never had good experiences with commons-logging in my
environments (not saying I could do better, I recognize the challenge is
non-trivial), but I accept it is currently a *necessary evil* given Javasoft
adding to the mix w/ JDK logging. Logging users just ought not suffer the
pain.
If UGLI is a way to bring /commons-logging/ into the fold of logging
services & provided as a globally available service, I could be +1 for that
..
That said, a few things:
1) I don't know the two communities, but one thing I like about C-L being in
'user space' is it is clearly a user advocate w/o the temptations to extend
the API. We see (from the recent Gump failures) how many folks depend upon
C-L already, but maybe putting it into a logging services community would
open it up to more folks, including container writers.
2) I know C-L has a hard life, it is trying to sit on top of so much, but I
find it's need/attempt to call/configure logging packages a problem. I don't
know if I am expressing some form of IOC thought here, but when working on
Depot, even C-L falls down. We (as a library) wanted to plug in to Ant, and
we didn't want to force the C-L to Ant bridge. Basically, we wrote our own
(yet another) logging that was simply a listener pattern, and plugged in an
Ant logger listener, or a commons logging listener, as appropriate. Works
nicely, but I don't want to write that code. I'd like UGLI as a logging
abstraction that all containers can agree upon (Ant as a container, an
application as a container) and have the environment provide it.
3) Forgive me, but ... would UGLI (with nose holding) be able to sit under
JDK logging? Surely folks ought be able to just use that. Ugly or not, the
JDK solution is going to be there inside any recent Java VM. Is that not
sufficiently simple?
Right now, logging is simple, but real-world logging has become way too
complex, in too many environments. Something needs to give.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Starting work on UGLI
Posted by Paul Smith <ps...@minotaur.apache.org>.
>
> The word "universal" stands for applicability in all contexts,
> including stand alone applications, containers (EJB, Servlet, Nano,
> Pico, Avalon, whatever) and most importantly in specialized
> libraries. The word generic stands for very simple, with an absolute
> separation between the logging interface required to access logging on
> one hand and configuration of the logging system on the other.
>
This would simplify a lot. We should all get behind this if possible. I
am assuming this is THE 'common' Logger interface. Is there any other
scope involved in this suggestion Ceki? (ie. a LoggerFactory discovery
process?)
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Starting work on UGLI
Posted by Alex Karasulu <ao...@bellsouth.net>.
Eric,
On Mon, 2004-06-07 at 09:26, Eric Pugh wrote:
> How is UGLI different from commons-logging? I don't want yet another
> logging api to have to consider when writing my applications/components.
I don't think commons-logging takes into account any of the
configuration aspects associated with specific logging implementations
like log4j or the jdk's logger. What Ceki seems to be proposing is a
superset of the commons-logger where the interfaces are extended to
handle log configuration through a generalized interface. At least that
was my impression - please anyone correct me if I'm off.
> Any thing that makes logging simple would be great.
>
> Eric
+1
>
> > -----Original Message-----
> > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > Sent: Monday, June 07, 2004 9:58 AM
> > To: Avalon Developers List
> > Cc: log4j-dev@logging.apache.org; general@logging.apache.org;
> > commons-dev@jakarta.apache.org
> > Subject: Re: Starting work on UGLI
> >
> >
> >
> > Ceki:
> >
> > Ceki Gülcü wrote:
> >
> > >
> > > Hello,
> > >
> > > While working on the internal log4j logging, it occurred to me that it
> > > could be very useful to synthesize log4j's core user interface in its
> > > own package. I'd like to call this package Universal Generic Logging
> > > Interface or UGLI (pun intended).
> > >
> > > The word "universal" stands for applicability in all contexts,
> > > including stand alone applications, containers (EJB, Servlet, Nano,
> > > Pico, Avalon, whatever) and most importantly in specialized
> > > libraries. The word generic stands for very simple, with an absolute
> > > separation between the logging interface required to access logging on
> > > one hand and configuration of the logging system on the other.
> >
> > Sounds good.
> >
> > I'm presuming that the phrase "logging interface required to access
> > logging" is specifically the client interface against which a logging
> > message is invoked (as opposed to anything related to how an instance of
> > that interface is created). Is that correct?
> >
> > The second phrase "configuration of the logging system" is somewhat
> > broader and I wanted to find out if your thinking about the general area
> > of how plug-in logging targets can be managed in a managed classloader
> > environment. This subject is currently the major obstacle to the use of
> > different logging solutions and a common API for loading, deploying and
> > releasing plug-in target factories would be a big step forward.
> >
> > For reference - Avalon's work in this area is under the Avalon Logging
> > system which is a implementation independent framework for managing a
> > logging system within which we have two plug-in implementation
> >
> > * LogKit
> > * Log4J.
> >
> > http://avalon.apache.org/logging/impl/index.html
> >
> > The actual logging management API is described in the javadoc at
> > http://avalon.apache.org/logging/api/index.html (however keep in mind
> > that each plug-in logging solution has its own particular logging system
> > configuration).
> >
> > As far as the management side is concerned, do you see UGLI covering the
> > spectrum of management APIs and configuration schema (or maybe I'm
> > reading too much into your email)?
> >
> > Cheers, Stephen.
> >
> > --
> >
> > |---------------------------------------|
> > | Magic by Merlin |
> > | Production by Avalon |
> > | |
> > | http://avalon.apache.org |
> > |---------------------------------------|
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Starting work on UGLI
Posted by Eric Pugh <ep...@upstate.com>.
How is UGLI different from commons-logging? I don't want yet another
logging api to have to consider when writing my applications/components.
<begin rant>
I definitly don't want to have to implement another logging interface, and
after all the pain I've gone through attempting to grok various logging
packages, I often find myself going back to System.out.println and
System.err.println since I know they work. Or, spinning my own logging
package that does exactly what I need and no more. Not a great solution,
but a reaction to the complexity of what I think should be really be a very
simple (from the developer perspective) problem to solve.
<end rant>
Any thing that makes logging simple would be great.
Eric
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Monday, June 07, 2004 9:58 AM
> To: Avalon Developers List
> Cc: log4j-dev@logging.apache.org; general@logging.apache.org;
> commons-dev@jakarta.apache.org
> Subject: Re: Starting work on UGLI
>
>
>
> Ceki:
>
> Ceki Gülcü wrote:
>
> >
> > Hello,
> >
> > While working on the internal log4j logging, it occurred to me that it
> > could be very useful to synthesize log4j's core user interface in its
> > own package. I'd like to call this package Universal Generic Logging
> > Interface or UGLI (pun intended).
> >
> > The word "universal" stands for applicability in all contexts,
> > including stand alone applications, containers (EJB, Servlet, Nano,
> > Pico, Avalon, whatever) and most importantly in specialized
> > libraries. The word generic stands for very simple, with an absolute
> > separation between the logging interface required to access logging on
> > one hand and configuration of the logging system on the other.
>
> Sounds good.
>
> I'm presuming that the phrase "logging interface required to access
> logging" is specifically the client interface against which a logging
> message is invoked (as opposed to anything related to how an instance of
> that interface is created). Is that correct?
>
> The second phrase "configuration of the logging system" is somewhat
> broader and I wanted to find out if your thinking about the general area
> of how plug-in logging targets can be managed in a managed classloader
> environment. This subject is currently the major obstacle to the use of
> different logging solutions and a common API for loading, deploying and
> releasing plug-in target factories would be a big step forward.
>
> For reference - Avalon's work in this area is under the Avalon Logging
> system which is a implementation independent framework for managing a
> logging system within which we have two plug-in implementation
>
> * LogKit
> * Log4J.
>
> http://avalon.apache.org/logging/impl/index.html
>
> The actual logging management API is described in the javadoc at
> http://avalon.apache.org/logging/api/index.html (however keep in mind
> that each plug-in logging solution has its own particular logging system
> configuration).
>
> As far as the management side is concerned, do you see UGLI covering the
> spectrum of management APIs and configuration schema (or maybe I'm
> reading too much into your email)?
>
> Cheers, Stephen.
>
> --
>
> |---------------------------------------|
> | Magic by Merlin |
> | Production by Avalon |
> | |
> | http://avalon.apache.org |
> |---------------------------------------|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Starting work on UGLI
Posted by Stephen McConnell <mc...@apache.org>.
Ceki:
Ceki Gülcü wrote:
>
> Hello,
>
> While working on the internal log4j logging, it occurred to me that it
> could be very useful to synthesize log4j's core user interface in its
> own package. I'd like to call this package Universal Generic Logging
> Interface or UGLI (pun intended).
>
> The word "universal" stands for applicability in all contexts,
> including stand alone applications, containers (EJB, Servlet, Nano,
> Pico, Avalon, whatever) and most importantly in specialized
> libraries. The word generic stands for very simple, with an absolute
> separation between the logging interface required to access logging on
> one hand and configuration of the logging system on the other.
Sounds good.
I'm presuming that the phrase "logging interface required to access
logging" is specifically the client interface against which a logging
message is invoked (as opposed to anything related to how an instance of
that interface is created). Is that correct?
The second phrase "configuration of the logging system" is somewhat
broader and I wanted to find out if your thinking about the general area
of how plug-in logging targets can be managed in a managed classloader
environment. This subject is currently the major obstacle to the use of
different logging solutions and a common API for loading, deploying and
releasing plug-in target factories would be a big step forward.
For reference - Avalon's work in this area is under the Avalon Logging
system which is a implementation independent framework for managing a
logging system within which we have two plug-in implementation
* LogKit
* Log4J.
http://avalon.apache.org/logging/impl/index.html
The actual logging management API is described in the javadoc at
http://avalon.apache.org/logging/api/index.html (however keep in mind
that each plug-in logging solution has its own particular logging system
configuration).
As far as the management side is concerned, do you see UGLI covering the
spectrum of management APIs and configuration schema (or maybe I'm
reading too much into your email)?
Cheers, Stephen.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Starting work on UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
Is it OK if we move this conversation to general@logging.apache.org? Having
a thread spread over 5 lists is not very practical.
At 05:31 PM 6/7/2004, Niclas Hedhman wrote:
>On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
>
> > Given the lessons learned from past experience, in particular wrt
> > extreme simplicity and generality, it is expected that UGLI will be
> > quickly adopted by many developers.
>
>Ceki has previously asked about the so called "No Logging" strategy, which
>can
>be found on the Avalon Wiki site;
>http://wiki.apache.org/avalon/AvalonNoLogging
>
>"No Logging" in its core addresses the concern "Logging! For WHO?", and turn
>the table around, saying 'The component can express itself in this way. Who
>is interested?"
>
>Now, this solves some issues but raises some new ones;
>
>1. Each object that wants to 'express itself', needs to fire events
>instead of
>calling the logger methods. Effectively the same thing, except there may be
>many listeners, and the 'expression' is done from the object's PoV and not
>the logging system's.
>
>2. The 'Logger' somehow need to be registered as a listener to the object
>instance. For IoC frameworks that is already in place, but in many POJO
>scenarios, support for 'discovery' has to be made available.
>
>3. The Logging framework do exist, and has a good purpose, and that means
>that
>an adapter is required between the object's so called Monitor and the logging
>framework. The custom monitor, which defines the 'expression' end's up being
>responsible to tie this expressiveness into one or more interested parties.
>
>
>It could look something like;
>
>
> | Custom +------------------
> | Monitor concern | Logging concern
>+--------+ | +---------+ +---------+ | +-----------+
>| User |-|->| Custom |-->| Log |-|->| Logger |
>| Object | | | Monitor | | Adapter | | | Framework |
>+--------+ | +---------+ +---------+ | +-----------+
> | | | |
> | | | +------------------
> | | |
> | | | +----------------
> | | | | Performance concern
> | | | +---------+ | +-------------+
> User | | +---->| Perform |-|->| Performance |
> concern | | | Adapter | | | Monitor |
> | | +---------+ | +-------------+
> | | |
> | | +----------------
> | |
> | | +----------------
> | | | Fault concern
> | | +---------+ | +---------+
> | +--------->| Fault |-|->| Fault |
> | | Adapter |-|->| Monitor |
> | +---------+ | +---------+
> | |
> | +-------------
>
>The examples of other Monitors are hypothetical, just to show some
>'reasonable' use-cases.
>
>What I am trying to show is that the "Logging Concern" is somewhat
>intersected
>with other monitoring concerns, and that there is a 'space' between the
>"Logging Concern" and the "User Concern". (We at Avalon are
>Concern-Separation-fanatics!)
>
>The challenge now would be;
>
>1. Convince everyone here (first) that this is a useful pattern.
>2. Figure out how the "Monitor Concern" is managed.
>3. Create necessary 'ease-of-use' support for the average user.
>4. Establish an exchange of re-usable Monitors.
>5. Implement it all.
>
>Does anything of the above make any sense to anyone ??
>
>
>Cheers
>Niclas
>--
> +------//-------------------+
> / http://www.bali.ac /
> / http://niclas.hedhman.org /
>+------//-------------------+
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Starting work on UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
Is it OK if we move this conversation to general@logging.apache.org? Having
a thread spread over 5 lists is not very practical.
At 05:31 PM 6/7/2004, Niclas Hedhman wrote:
>On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
>
> > Given the lessons learned from past experience, in particular wrt
> > extreme simplicity and generality, it is expected that UGLI will be
> > quickly adopted by many developers.
>
>Ceki has previously asked about the so called "No Logging" strategy, which
>can
>be found on the Avalon Wiki site;
>http://wiki.apache.org/avalon/AvalonNoLogging
>
>"No Logging" in its core addresses the concern "Logging! For WHO?", and turn
>the table around, saying 'The component can express itself in this way. Who
>is interested?"
>
>Now, this solves some issues but raises some new ones;
>
>1. Each object that wants to 'express itself', needs to fire events
>instead of
>calling the logger methods. Effectively the same thing, except there may be
>many listeners, and the 'expression' is done from the object's PoV and not
>the logging system's.
>
>2. The 'Logger' somehow need to be registered as a listener to the object
>instance. For IoC frameworks that is already in place, but in many POJO
>scenarios, support for 'discovery' has to be made available.
>
>3. The Logging framework do exist, and has a good purpose, and that means
>that
>an adapter is required between the object's so called Monitor and the logging
>framework. The custom monitor, which defines the 'expression' end's up being
>responsible to tie this expressiveness into one or more interested parties.
>
>
>It could look something like;
>
>
> | Custom +------------------
> | Monitor concern | Logging concern
>+--------+ | +---------+ +---------+ | +-----------+
>| User |-|->| Custom |-->| Log |-|->| Logger |
>| Object | | | Monitor | | Adapter | | | Framework |
>+--------+ | +---------+ +---------+ | +-----------+
> | | | |
> | | | +------------------
> | | |
> | | | +----------------
> | | | | Performance concern
> | | | +---------+ | +-------------+
> User | | +---->| Perform |-|->| Performance |
> concern | | | Adapter | | | Monitor |
> | | +---------+ | +-------------+
> | | |
> | | +----------------
> | |
> | | +----------------
> | | | Fault concern
> | | +---------+ | +---------+
> | +--------->| Fault |-|->| Fault |
> | | Adapter |-|->| Monitor |
> | +---------+ | +---------+
> | |
> | +-------------
>
>The examples of other Monitors are hypothetical, just to show some
>'reasonable' use-cases.
>
>What I am trying to show is that the "Logging Concern" is somewhat
>intersected
>with other monitoring concerns, and that there is a 'space' between the
>"Logging Concern" and the "User Concern". (We at Avalon are
>Concern-Separation-fanatics!)
>
>The challenge now would be;
>
>1. Convince everyone here (first) that this is a useful pattern.
>2. Figure out how the "Monitor Concern" is managed.
>3. Create necessary 'ease-of-use' support for the average user.
>4. Establish an exchange of re-usable Monitors.
>5. Implement it all.
>
>Does anything of the above make any sense to anyone ??
>
>
>Cheers
>Niclas
>--
> +------//-------------------+
> / http://www.bali.ac /
> / http://niclas.hedhman.org /
>+------//-------------------+
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Starting work on UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
Is it OK if we move this conversation to general@logging.apache.org? Having
a thread spread over 5 lists is not very practical.
At 05:31 PM 6/7/2004, Niclas Hedhman wrote:
>On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
>
> > Given the lessons learned from past experience, in particular wrt
> > extreme simplicity and generality, it is expected that UGLI will be
> > quickly adopted by many developers.
>
>Ceki has previously asked about the so called "No Logging" strategy, which
>can
>be found on the Avalon Wiki site;
>http://wiki.apache.org/avalon/AvalonNoLogging
>
>"No Logging" in its core addresses the concern "Logging! For WHO?", and turn
>the table around, saying 'The component can express itself in this way. Who
>is interested?"
>
>Now, this solves some issues but raises some new ones;
>
>1. Each object that wants to 'express itself', needs to fire events
>instead of
>calling the logger methods. Effectively the same thing, except there may be
>many listeners, and the 'expression' is done from the object's PoV and not
>the logging system's.
>
>2. The 'Logger' somehow need to be registered as a listener to the object
>instance. For IoC frameworks that is already in place, but in many POJO
>scenarios, support for 'discovery' has to be made available.
>
>3. The Logging framework do exist, and has a good purpose, and that means
>that
>an adapter is required between the object's so called Monitor and the logging
>framework. The custom monitor, which defines the 'expression' end's up being
>responsible to tie this expressiveness into one or more interested parties.
>
>
>It could look something like;
>
>
> | Custom +------------------
> | Monitor concern | Logging concern
>+--------+ | +---------+ +---------+ | +-----------+
>| User |-|->| Custom |-->| Log |-|->| Logger |
>| Object | | | Monitor | | Adapter | | | Framework |
>+--------+ | +---------+ +---------+ | +-----------+
> | | | |
> | | | +------------------
> | | |
> | | | +----------------
> | | | | Performance concern
> | | | +---------+ | +-------------+
> User | | +---->| Perform |-|->| Performance |
> concern | | | Adapter | | | Monitor |
> | | +---------+ | +-------------+
> | | |
> | | +----------------
> | |
> | | +----------------
> | | | Fault concern
> | | +---------+ | +---------+
> | +--------->| Fault |-|->| Fault |
> | | Adapter |-|->| Monitor |
> | +---------+ | +---------+
> | |
> | +-------------
>
>The examples of other Monitors are hypothetical, just to show some
>'reasonable' use-cases.
>
>What I am trying to show is that the "Logging Concern" is somewhat
>intersected
>with other monitoring concerns, and that there is a 'space' between the
>"Logging Concern" and the "User Concern". (We at Avalon are
>Concern-Separation-fanatics!)
>
>The challenge now would be;
>
>1. Convince everyone here (first) that this is a useful pattern.
>2. Figure out how the "Monitor Concern" is managed.
>3. Create necessary 'ease-of-use' support for the average user.
>4. Establish an exchange of re-usable Monitors.
>5. Implement it all.
>
>Does anything of the above make any sense to anyone ??
>
>
>Cheers
>Niclas
>--
> +------//-------------------+
> / http://www.bali.ac /
> / http://niclas.hedhman.org /
>+------//-------------------+
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Starting work on UGLI
Posted by Ceki Gülcü <ce...@qos.ch>.
Is it OK if we move this conversation to general@logging.apache.org? Having
a thread spread over 5 lists is not very practical.
At 05:31 PM 6/7/2004, Niclas Hedhman wrote:
>On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
>
> > Given the lessons learned from past experience, in particular wrt
> > extreme simplicity and generality, it is expected that UGLI will be
> > quickly adopted by many developers.
>
>Ceki has previously asked about the so called "No Logging" strategy, which
>can
>be found on the Avalon Wiki site;
>http://wiki.apache.org/avalon/AvalonNoLogging
>
>"No Logging" in its core addresses the concern "Logging! For WHO?", and turn
>the table around, saying 'The component can express itself in this way. Who
>is interested?"
>
>Now, this solves some issues but raises some new ones;
>
>1. Each object that wants to 'express itself', needs to fire events
>instead of
>calling the logger methods. Effectively the same thing, except there may be
>many listeners, and the 'expression' is done from the object's PoV and not
>the logging system's.
>
>2. The 'Logger' somehow need to be registered as a listener to the object
>instance. For IoC frameworks that is already in place, but in many POJO
>scenarios, support for 'discovery' has to be made available.
>
>3. The Logging framework do exist, and has a good purpose, and that means
>that
>an adapter is required between the object's so called Monitor and the logging
>framework. The custom monitor, which defines the 'expression' end's up being
>responsible to tie this expressiveness into one or more interested parties.
>
>
>It could look something like;
>
>
> | Custom +------------------
> | Monitor concern | Logging concern
>+--------+ | +---------+ +---------+ | +-----------+
>| User |-|->| Custom |-->| Log |-|->| Logger |
>| Object | | | Monitor | | Adapter | | | Framework |
>+--------+ | +---------+ +---------+ | +-----------+
> | | | |
> | | | +------------------
> | | |
> | | | +----------------
> | | | | Performance concern
> | | | +---------+ | +-------------+
> User | | +---->| Perform |-|->| Performance |
> concern | | | Adapter | | | Monitor |
> | | +---------+ | +-------------+
> | | |
> | | +----------------
> | |
> | | +----------------
> | | | Fault concern
> | | +---------+ | +---------+
> | +--------->| Fault |-|->| Fault |
> | | Adapter |-|->| Monitor |
> | +---------+ | +---------+
> | |
> | +-------------
>
>The examples of other Monitors are hypothetical, just to show some
>'reasonable' use-cases.
>
>What I am trying to show is that the "Logging Concern" is somewhat
>intersected
>with other monitoring concerns, and that there is a 'space' between the
>"Logging Concern" and the "User Concern". (We at Avalon are
>Concern-Separation-fanatics!)
>
>The challenge now would be;
>
>1. Convince everyone here (first) that this is a useful pattern.
>2. Figure out how the "Monitor Concern" is managed.
>3. Create necessary 'ease-of-use' support for the average user.
>4. Establish an exchange of re-usable Monitors.
>5. Implement it all.
>
>Does anything of the above make any sense to anyone ??
>
>
>Cheers
>Niclas
>--
> +------//-------------------+
> / http://www.bali.ac /
> / http://niclas.hedhman.org /
>+------//-------------------+
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
Re: Starting work on UGLI
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
> Given the lessons learned from past experience, in particular wrt
> extreme simplicity and generality, it is expected that UGLI will be
> quickly adopted by many developers.
Ceki has previously asked about the so called "No Logging" strategy, which can
be found on the Avalon Wiki site;
http://wiki.apache.org/avalon/AvalonNoLogging
"No Logging" in its core addresses the concern "Logging! For WHO?", and turn
the table around, saying 'The component can express itself in this way. Who
is interested?"
Now, this solves some issues but raises some new ones;
1. Each object that wants to 'express itself', needs to fire events instead of
calling the logger methods. Effectively the same thing, except there may be
many listeners, and the 'expression' is done from the object's PoV and not
the logging system's.
2. The 'Logger' somehow need to be registered as a listener to the object
instance. For IoC frameworks that is already in place, but in many POJO
scenarios, support for 'discovery' has to be made available.
3. The Logging framework do exist, and has a good purpose, and that means that
an adapter is required between the object's so called Monitor and the logging
framework. The custom monitor, which defines the 'expression' end's up being
responsible to tie this expressiveness into one or more interested parties.
It could look something like;
| Custom +------------------
| Monitor concern | Logging concern
+--------+ | +---------+ +---------+ | +-----------+
| User |-|->| Custom |-->| Log |-|->| Logger |
| Object | | | Monitor | | Adapter | | | Framework |
+--------+ | +---------+ +---------+ | +-----------+
| | | |
| | | +------------------
| | |
| | | +----------------
| | | | Performance concern
| | | +---------+ | +-------------+
User | | +---->| Perform |-|->| Performance |
concern | | | Adapter | | | Monitor |
| | +---------+ | +-------------+
| | |
| | +----------------
| |
| | +----------------
| | | Fault concern
| | +---------+ | +---------+
| +--------->| Fault |-|->| Fault |
| | Adapter |-|->| Monitor |
| +---------+ | +---------+
| |
| +-------------
The examples of other Monitors are hypothetical, just to show some
'reasonable' use-cases.
What I am trying to show is that the "Logging Concern" is somewhat intersected
with other monitoring concerns, and that there is a 'space' between the
"Logging Concern" and the "User Concern". (We at Avalon are
Concern-Separation-fanatics!)
The challenge now would be;
1. Convince everyone here (first) that this is a useful pattern.
2. Figure out how the "Monitor Concern" is managed.
3. Create necessary 'ease-of-use' support for the average user.
4. Establish an exchange of re-usable Monitors.
5. Implement it all.
Does anything of the above make any sense to anyone ??
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Starting work on UGLI
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> I am CCing general@logging, avalon-dev and commons-dev to elicit input
> for this endeavor.
I'm no expert in this area, simply an external user (with no insights into
history/politics/whatever). That said, I'm not shy to provide my input...
I've loved logging (log4j, simple), I've hated logging (for becoming a
pain). I've never had good experiences with commons-logging in my
environments (not saying I could do better, I recognize the challenge is
non-trivial), but I accept it is currently a *necessary evil* given Javasoft
adding to the mix w/ JDK logging. Logging users just ought not suffer the
pain.
If UGLI is a way to bring /commons-logging/ into the fold of logging
services & provided as a globally available service, I could be +1 for that
..
That said, a few things:
1) I don't know the two communities, but one thing I like about C-L being in
'user space' is it is clearly a user advocate w/o the temptations to extend
the API. We see (from the recent Gump failures) how many folks depend upon
C-L already, but maybe putting it into a logging services community would
open it up to more folks, including container writers.
2) I know C-L has a hard life, it is trying to sit on top of so much, but I
find it's need/attempt to call/configure logging packages a problem. I don't
know if I am expressing some form of IOC thought here, but when working on
Depot, even C-L falls down. We (as a library) wanted to plug in to Ant, and
we didn't want to force the C-L to Ant bridge. Basically, we wrote our own
(yet another) logging that was simply a listener pattern, and plugged in an
Ant logger listener, or a commons logging listener, as appropriate. Works
nicely, but I don't want to write that code. I'd like UGLI as a logging
abstraction that all containers can agree upon (Ant as a container, an
application as a container) and have the environment provide it.
3) Forgive me, but ... would UGLI (with nose holding) be able to sit under
JDK logging? Surely folks ought be able to just use that. Ugly or not, the
JDK solution is going to be there inside any recent Java VM. Is that not
sufficiently simple?
Right now, logging is simple, but real-world logging has become way too
complex, in too many environments. Something needs to give.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Starting work on UGLI
Posted by Stephen McConnell <mc...@apache.org>.
Ceki:
Ceki Gülcü wrote:
>
> Hello,
>
> While working on the internal log4j logging, it occurred to me that it
> could be very useful to synthesize log4j's core user interface in its
> own package. I'd like to call this package Universal Generic Logging
> Interface or UGLI (pun intended).
>
> The word "universal" stands for applicability in all contexts,
> including stand alone applications, containers (EJB, Servlet, Nano,
> Pico, Avalon, whatever) and most importantly in specialized
> libraries. The word generic stands for very simple, with an absolute
> separation between the logging interface required to access logging on
> one hand and configuration of the logging system on the other.
Sounds good.
I'm presuming that the phrase "logging interface required to access
logging" is specifically the client interface against which a logging
message is invoked (as opposed to anything related to how an instance of
that interface is created). Is that correct?
The second phrase "configuration of the logging system" is somewhat
broader and I wanted to find out if your thinking about the general area
of how plug-in logging targets can be managed in a managed classloader
environment. This subject is currently the major obstacle to the use of
different logging solutions and a common API for loading, deploying and
releasing plug-in target factories would be a big step forward.
For reference - Avalon's work in this area is under the Avalon Logging
system which is a implementation independent framework for managing a
logging system within which we have two plug-in implementation
* LogKit
* Log4J.
http://avalon.apache.org/logging/impl/index.html
The actual logging management API is described in the javadoc at
http://avalon.apache.org/logging/api/index.html (however keep in mind
that each plug-in logging solution has its own particular logging system
configuration).
As far as the management side is concerned, do you see UGLI covering the
spectrum of management APIs and configuration schema (or maybe I'm
reading too much into your email)?
Cheers, Stephen.
--
|---------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org |
|---------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Starting work on UGLI
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
> Given the lessons learned from past experience, in particular wrt
> extreme simplicity and generality, it is expected that UGLI will be
> quickly adopted by many developers.
Ceki has previously asked about the so called "No Logging" strategy, which can
be found on the Avalon Wiki site;
http://wiki.apache.org/avalon/AvalonNoLogging
"No Logging" in its core addresses the concern "Logging! For WHO?", and turn
the table around, saying 'The component can express itself in this way. Who
is interested?"
Now, this solves some issues but raises some new ones;
1. Each object that wants to 'express itself', needs to fire events instead of
calling the logger methods. Effectively the same thing, except there may be
many listeners, and the 'expression' is done from the object's PoV and not
the logging system's.
2. The 'Logger' somehow need to be registered as a listener to the object
instance. For IoC frameworks that is already in place, but in many POJO
scenarios, support for 'discovery' has to be made available.
3. The Logging framework do exist, and has a good purpose, and that means that
an adapter is required between the object's so called Monitor and the logging
framework. The custom monitor, which defines the 'expression' end's up being
responsible to tie this expressiveness into one or more interested parties.
It could look something like;
| Custom +------------------
| Monitor concern | Logging concern
+--------+ | +---------+ +---------+ | +-----------+
| User |-|->| Custom |-->| Log |-|->| Logger |
| Object | | | Monitor | | Adapter | | | Framework |
+--------+ | +---------+ +---------+ | +-----------+
| | | |
| | | +------------------
| | |
| | | +----------------
| | | | Performance concern
| | | +---------+ | +-------------+
User | | +---->| Perform |-|->| Performance |
concern | | | Adapter | | | Monitor |
| | +---------+ | +-------------+
| | |
| | +----------------
| |
| | +----------------
| | | Fault concern
| | +---------+ | +---------+
| +--------->| Fault |-|->| Fault |
| | Adapter |-|->| Monitor |
| +---------+ | +---------+
| |
| +-------------
The examples of other Monitors are hypothetical, just to show some
'reasonable' use-cases.
What I am trying to show is that the "Logging Concern" is somewhat intersected
with other monitoring concerns, and that there is a 'space' between the
"Logging Concern" and the "User Concern". (We at Avalon are
Concern-Separation-fanatics!)
The challenge now would be;
1. Convince everyone here (first) that this is a useful pattern.
2. Figure out how the "Monitor Concern" is managed.
3. Create necessary 'ease-of-use' support for the average user.
4. Establish an exchange of re-usable Monitors.
5. Implement it all.
Does anything of the above make any sense to anyone ??
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org