You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2002/04/03 15:46:07 UTC
[logging] Need interface...
Ok, I haven't been a big fan of Yet Another Logging Impl, but I'll leave
that behind me, and propose we crib an idea from avalon, and hop on the
bandwagon.
The problem is this - we are doing a set of tools in velocity's tool
subproject, and some may want a logger. In the spirit of Jakarta, we are
reinventing the wheel again ("look Og, round! Burns too!" - I guess we got
fire as part of the bargain) and I don't want to.
What we need is a marker interface that indicates a tool wants a logger, and
of course a method to give it the logger... I did a quick scan of the
public API, and there doesn't seem to be one.
So what I propose is to add an interface 'LogUser' or something like it (we
can quibble about the name...)
public interface LogUser
{
public void setCommonsLogger(Log log)
}
So we have a common way to plant a logger. I am guessing this is probably
yet another thing stolen from Avalon, so I'll be up front now about that :)
As I personally believe that just being a commons committer doesn't give me
the 'spirit-of-the-law' right to commit to the logger, I'll ask for some
even vague hint of approval from the logger people before moving forward.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Maven & Gump are friends
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Paul Hammant" <Pa...@yahoo.com>
> >In other words, you also want a 'push' model for the logger. Curently
each
> >component is supposed to 'pull' the logger.
> >
> Not wishing to be political, just to furnish you with info, the 'push'
> model is described as 'Inversion of Control' -->
>
> http://jakarta.apache.org/avalon/framework/inversion-of-control.html
>
Avalon has such an interface:
http://cvs.apache.org/viewcvs/jakarta-avalon/src/java/org/apache/avalon/fram
ework/logger/LogEnabled.java?rev=1.4&content-type=text/vnd.viewcvs-markup
The logging stuff in Avalon that wraps logging is here:
http://cvs.apache.org/viewcvs/jakarta-avalon/src/java/org/apache/avalon/fram
ework/logger/
Is there still room for a single logging wrapper or must we all have to deal
with everchanging interfaces? >8-/
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...: should we use interfaces for configuraiton?
Posted by Tomasz Pik <pi...@ais.pl>.
Maybe it will be useful to put such a summary of a long discussion
somewhere at 'Commons'site?
Tomek Pik
pikus@ais.pl
James Strachan wrote:
> It took me a while but I finally caught up with this thread I think. Wow
> logging seems to generate nearly as much mail as discussions on coding
> styles ;-)
.....
> James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...: should we use interfaces for configuraiton?
Posted by James Strachan <ja...@yahoo.co.uk>.
It took me a while but I finally caught up with this thread I think. Wow
logging seems to generate nearly as much mail as discussions on coding
styles ;-)
I hear Geir's concerns and requirements of the LogUser and agree with
various other posters, particularly Costin's points. It got me thinking.
Should we make marker interfaces for setter methods for configuration stuff?
e.g. the Digester uses the pull approach (JAXP) to get a SAX XMLReader; yet
it also provides a setter method, setXMLReader(XMLReader) so that something
else can configure the Digester instance explicitly. So should there be a
XMLReaderEnabled marker interface to indentify components that can have
their XMLReader configured?
My gut feel is no, just use regular bean setters, otherwise it gets messy in
general. A component might have 2 Log instances (like Digester) and so might
need 2 setter methods. If a component needs 2 logs then any 'framework'
wishing to configure it should be able to do so, in which case the marker
interface seems to have little value.
So how about we
(i) agree on a standard method signature(s) we should try to use for setting
log-related information in components (though we don't have to use them).
Then this can be a naming convention or design pattern we follow, then
there's no huge need for a
marker interfade.
e.g.
void setLog(Log)
(which I've seen in a few commons components already)
or
void setLogFactory(LogFactory)
(ii) any 'framework / app' thingy that wants to explicitly set Log objects
can use introspection.
So in Velocity land Geir could use this...
Log log = myLogThingy;
Object someComponent = ...;
PropertyUtils.setProperty(
someComponent
"log",
myLogThingy
);
rather than...
Log log = myLogThingy;
Object someComponent = ...;
if ( someComponent instanceof LogUser ) {
((LogUser) someComponent).setLog( someLogComponent );
}
(iii) it might be nice to write MBeans for some components which will allow
JMX to manage them nicely which provides a standard hook to configure
components in a much more general way than the LogUser proposal.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Paul Hammant" <Pa...@yahoo.com>
> >In other words, you also want a 'push' model for the logger. Curently
each
> >component is supposed to 'pull' the logger.
> >
> Not wishing to be political, just to furnish you with info, the 'push'
> model is described as 'Inversion of Control' -->
>
> http://jakarta.apache.org/avalon/framework/inversion-of-control.html
>
Avalon has such an interface:
http://cvs.apache.org/viewcvs/jakarta-avalon/src/java/org/apache/avalon/fram
ework/logger/LogEnabled.java?rev=1.4&content-type=text/vnd.viewcvs-markup
The logging stuff in Avalon that wraps logging is here:
http://cvs.apache.org/viewcvs/jakarta-avalon/src/java/org/apache/avalon/fram
ework/logger/
Is there still room for a single logging wrapper or must we all have to deal
with everchanging interfaces? >8-/
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 1:33 PM, "Andrew C. Oliver" <ac...@apache.org> wrote:
> I find myself in agreement. Secondly, I conceptualize interface
> implementation as a form of inheritance (interface inheritance).
It's not. In this case, it's a contract.
> Therefore, you must ask: Is this an appropriate situation for
> inheritance or containment. Most object technology "experts" profess
> you should favor containment versus inheritance. This is a sign of good
> encapsulation.
>
> Avalon's logging solution might be appropriate for one conceptualization
> of logging which is "component level" logging.
Did you read the thread? That's what I'm talking about. (and in commons,
that¹s what it should be right?)
> In truth logging is used
> to refer to multiple types of logging (tracing, error reporting, etc),
> and most of the differentiation of this is the message importance or
> type. Its where or when you want the message to be viewable and in some
> cases created.
>
> As for configuration, is the logging a service or a class assignable
> property? Generally I think its a service used by your application or
> API. Avalon's logic is that your "component" need to be "configured"
> with this "aspect". I see the logic but I'm not sure I agree with it.
>
> Security is a consideration with calling a static wrapper (the general
> approach to logging that most folks use) but I would question the
> supposition that security cannot be a service called by or implemented
> by the logging service/static wrapper in such a situation where its
> required.
Sorry? There is no security issue here whatesoever as this is IOC - the
container/app/framework/woogie calls the setCommonsLog() if it *wants* to -
the component can do nothing to 'grab' it.
The contract is that the component has to be defensive - it can't assume it
has a logger, and that if it doesn't get a logger, it has to deal...
>
> Lastly, its just a pain in the butt to do it the way Avalon does it. I
> think its the case of working around a mismatch between Java and the
> "Aspect Oriented Programming" that they seem to be going after.
This changes *nothing* at all *anywhere* but simply adds to the logger
package a new interface, implemented by components, that means "I can use a
configured Commons logger if you want me to".
> There are many things about Avalon that are increadibly likeable and
> there are situations where I would use this kind of logging. Just, I
> don't see it as a "hammer" and am not sure that the same thing can't be
> accomplished through containment.
>
> And that's all I have to say about that.
I suspect that you don't quite grasp what I am asking for... I'll be happy
to explain if I haven't been clear...
> -Andy
>
> Jon Scott Stevens wrote:
>
>> on 4/3/02 10:09 AM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>>
>>> Now, if the parent instantiates MyComponent and forgets to call
>>> enableLogging() *before* myMethod() is called, an NPE will be thrown and it
>>> will not be clear as to why that NPE was thrown unless you go and look at
>>> the source code. There is no open coding contract that says that
>>> enableLogging() needs to be called first.
>>>
>>
>> I should also add that I don't like the fact that a parent is required.
>>
>> If a parent is required, then it requires a framework to support the
>> children (ie: that is what a parent really is).
>>
>> Sure, sometimes frameworks are appropriate, but I don't think they are
>> necessary for Velocity tools which are just objects stuck in the context...
>>
>> -jon
>>
>>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Age and treachery will always triumph over youth and talent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Andrew C. Oliver" <ac...@apache.org>.
I find myself in agreement. Secondly, I conceptualize interface
implementation as a form of inheritance (interface inheritance).
Therefore, you must ask: Is this an appropriate situation for
inheritance or containment. Most object technology "experts" profess
you should favor containment versus inheritance. This is a sign of good
encapsulation.
Avalon's logging solution might be appropriate for one conceptualization
of logging which is "component level" logging. In truth logging is used
to refer to multiple types of logging (tracing, error reporting, etc),
and most of the differentiation of this is the message importance or
type. Its where or when you want the message to be viewable and in some
cases created.
As for configuration, is the logging a service or a class assignable
property? Generally I think its a service used by your application or
API. Avalon's logic is that your "component" need to be "configured"
with this "aspect". I see the logic but I'm not sure I agree with it.
Security is a consideration with calling a static wrapper (the general
approach to logging that most folks use) but I would question the
supposition that security cannot be a service called by or implemented
by the logging service/static wrapper in such a situation where its
required.
Lastly, its just a pain in the butt to do it the way Avalon does it. I
think its the case of working around a mismatch between Java and the
"Aspect Oriented Programming" that they seem to be going after.
There are many things about Avalon that are increadibly likeable and
there are situations where I would use this kind of logging. Just, I
don't see it as a "hammer" and am not sure that the same thing can't be
accomplished through containment.
And that's all I have to say about that.
-Andy
Jon Scott Stevens wrote:
>on 4/3/02 10:09 AM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>
>>Now, if the parent instantiates MyComponent and forgets to call
>>enableLogging() *before* myMethod() is called, an NPE will be thrown and it
>>will not be clear as to why that NPE was thrown unless you go and look at
>>the source code. There is no open coding contract that says that
>>enableLogging() needs to be called first.
>>
>
>I should also add that I don't like the fact that a parent is required.
>
>If a parent is required, then it requires a framework to support the
>children (ie: that is what a parent really is).
>
>Sure, sometimes frameworks are appropriate, but I don't think they are
>necessary for Velocity tools which are just objects stuck in the context...
>
>-jon
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 1:54 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> on 4/3/02 10:49 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>> On 4/3/02 1:12 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>>
>>> on 4/3/02 10:09 AM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>>>
>>>> Now, if the parent instantiates MyComponent and forgets to call
>>>> enableLogging() *before* myMethod() is called, an NPE will be thrown and it
>>>> will not be clear as to why that NPE was thrown unless you go and look at
>>>> the source code. There is no open coding contract that says that
>>>> enableLogging() needs to be called first.
>>>
>>> I should also add that I don't like the fact that a parent is required.
>>>
>>
>> I'm not being clear - it doesn't *require* anything. If the method isn't
>> called by the 'parent', it doesn't log. Very simple.
>
> Look at the example code I posted. It was:
>
> class
> {
> }
>
> Who is going to be able to instantiate that class outside of the package?
No one - that code wouldn't even compile because myMethod() didn't have a
return type - so I figured you were illustrating the point about the logger.
NPE...
>
>> The alternative is to invent a new framework and write the components to
>> work with it explicitly - namely the road they were going down in
>> vel-tools...
>
> No. You simply make a dependency on commons-logging.
Why? What if they aren't using it? To use my DateFooTool, you have to
switch your entire logging infrastructure, rather than just wrap the Log
interface around what you have?
>
>>> If a parent is required, then it requires a framework to support the
>>> children (ie: that is what a parent really is).
>>>
>>> Sure, sometimes frameworks are appropriate, but I don't think they are
>>> necessary for Velocity tools which are just objects stuck in the context...
>>
>> There is no framework required here :
>>
>> if ( the instantiator of the class decides to look for LogUser
>> && the instantiator has a logger impl that implements Log interface)
>> {
>> call setCommonsLog() so the component can log
>> }
>> else
>> {
>> do nothing
>> }
>>
>> I am sorry if I'm not clear. My suggestion has nothing to do with a
>> framework - the idea of logging is optional for what I am thinking of...
>
> Sorry if I'm not clear, but I don't think you read the example code I
> posted.
Ok - try again - what's the problem?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 4/3/02 10:49 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> On 4/3/02 1:12 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>
>> on 4/3/02 10:09 AM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>>
>>> Now, if the parent instantiates MyComponent and forgets to call
>>> enableLogging() *before* myMethod() is called, an NPE will be thrown and it
>>> will not be clear as to why that NPE was thrown unless you go and look at
>>> the source code. There is no open coding contract that says that
>>> enableLogging() needs to be called first.
>>
>> I should also add that I don't like the fact that a parent is required.
>>
>
> I'm not being clear - it doesn't *require* anything. If the method isn't
> called by the 'parent', it doesn't log. Very simple.
Look at the example code I posted. It was:
class
{
}
Who is going to be able to instantiate that class outside of the package?
> The alternative is to invent a new framework and write the components to
> work with it explicitly - namely the road they were going down in
> vel-tools...
No. You simply make a dependency on commons-logging.
>> If a parent is required, then it requires a framework to support the
>> children (ie: that is what a parent really is).
>>
>> Sure, sometimes frameworks are appropriate, but I don't think they are
>> necessary for Velocity tools which are just objects stuck in the context...
>
> There is no framework required here :
>
> if ( the instantiator of the class decides to look for LogUser
> && the instantiator has a logger impl that implements Log interface)
> {
> call setCommonsLog() so the component can log
> }
> else
> {
> do nothing
> }
>
> I am sorry if I'm not clear. My suggestion has nothing to do with a
> framework - the idea of logging is optional for what I am thinking of...
Sorry if I'm not clear, but I don't think you read the example code I
posted.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 1:12 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> on 4/3/02 10:09 AM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
>
>> Now, if the parent instantiates MyComponent and forgets to call
>> enableLogging() *before* myMethod() is called, an NPE will be thrown and it
>> will not be clear as to why that NPE was thrown unless you go and look at
>> the source code. There is no open coding contract that says that
>> enableLogging() needs to be called first.
>
> I should also add that I don't like the fact that a parent is required.
>
I'm not being clear - it doesn't *require* anything. If the method isn't
called by the 'parent', it doesn't log. Very simple.
The alternative is to invent a new framework and write the components to
work with it explicitly - namely the road they were going down in
vel-tools...
> If a parent is required, then it requires a framework to support the
> children (ie: that is what a parent really is).
>
> Sure, sometimes frameworks are appropriate, but I don't think they are
> necessary for Velocity tools which are just objects stuck in the context...
There is no framework required here :
if ( the instantiator of the class decides to look for LogUser
&& the instantiator has a logger impl that implements Log interface)
{
call setCommonsLog() so the component can log
}
else
{
do nothing
}
I am sorry if I'm not clear. My suggestion has nothing to do with a
framework - the idea of logging is optional for what I am thinking of...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
POC lives!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 4/3/02 10:09 AM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> Now, if the parent instantiates MyComponent and forgets to call
> enableLogging() *before* myMethod() is called, an NPE will be thrown and it
> will not be clear as to why that NPE was thrown unless you go and look at
> the source code. There is no open coding contract that says that
> enableLogging() needs to be called first.
I should also add that I don't like the fact that a parent is required.
If a parent is required, then it requires a framework to support the
children (ie: that is what a parent really is).
Sure, sometimes frameworks are appropriate, but I don't think they are
necessary for Velocity tools which are just objects stuck in the context...
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
I see no problem in some aspect like logging. Logging or tracing doe's not
depend on some framework or Container. If my "bean" or "service" is not
hosted by some container I
don't need any specific for "contract" interfaces or methods.
It is the same nonsence as implement
"setContext( ejbContext )" for Servlet or some ActiveX specific method for
plain Automation Object.
"public void setLogger( Log log )" has no meaning, if nobody sets this
"Log".
----- Original Message -----
From: Michael A. Smith <ma...@apache.org>
To: Jakarta Commons Developers List <co...@jakarta.apache.org>
Sent: Wednesday, April 03, 2002 9:50 PM
Subject: Re: [logging] Need interface...
> I'm trying to stay out of this debate, but I just can't let this go by:
>
> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
> > I'm thinking as:
> >
> > class MyClass implements LogUser
> > // default logger
> > private static Logger logger = Log.getLogger(MyClass.class);
> >
> > public void setLogger( Log log ) {
>
> // should really fail-fast if a null logger is provided rather
> // than have logging statements fail at some unknown point in
> // the future.
> if(log == null) throw new NullPointerException("null log");
>
> > logger=log;
> > }
> >
> > ...
> > if( logger.isDebugEnabled() ) logger.debug("Something" );
> > }
>
>
> yeah, I know it was just pseudo-code. :)
>
> regards,
> michael
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Michael A. Smith" <ma...@apache.org>.
I'm trying to stay out of this debate, but I just can't let this go by:
On Wed, 3 Apr 2002 costinm@covalent.net wrote:
> I'm thinking as:
>
> class MyClass implements LogUser {
> // default logger
> private static Logger logger = Log.getLogger(MyClass.class);
>
> public void setLogger( Log log ) {
// should really fail-fast if a null logger is provided rather
// than have logging statements fail at some unknown point in
// the future.
if(log == null) throw new NullPointerException("null log");
> logger=log;
> }
>
> ...
> if( logger.isDebugEnabled() ) logger.debug("Something" );
> }
yeah, I know it was just pseudo-code. :)
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/4/02 2:09 AM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>
>> Are you saying that any component/class/tool that implements the generic
>> commons logger Log interface is only usable in an application environment
>> where a special class with a static method getLogger() is in the classpath?
>> [Modulo the real name of the class and method... You get what I mean, I
>> hope...]
>
> The same pattern that is used with JDBC, JNDI, JAXP and about a dozen
> other APIs.
>
> I'm not sure what do you mean by 'framework' in this context - of course
> every API and package has a set of contracts and APIs. You want a database
> connection - you call the DriverManager or look up in JNDI.
I don't think it's a fair comparison necessarily, although I am having a
tough time explaining why.
But you pointed out an interesting thing. With a db connection, I can
legitimately 'pull' it via DriverManager, specifying exactly what I want in
terms of configuration, or it can be preconfigured by 'someone else' and (in
a broad sense) pushed to me via JNDI - I can go get it if I want, ready to
go.
In the case of commons, there seems to be an almost required implementation.
I think that's ok - it just needs to be stated (or y'all need to tell me to
go RTFM :)
> There is a LogFactory class that will find you the Log implementation,
> and if a logger is to be useable with the commons-logging it must
> implement the Log interface ( that's the big one ) and follow the
> discovery rules if it wants to be found using the LogFactory.
Ok - cool. I understand. If that isn't documented, it should be.
My only problem is that there is a huge assumption about how to get
LogFactory - unlike the db example, where I can use driver manager *or* JNDI
if I want to keep the knowledge outside of the app, I seem to have to utter
the right prayers and pull from some singleton.
I think there should be valid alternatives.
So there seems to be an opportunity for a generic logging interface in
commons that has no implementation or lifecycle requirements, because then I
can do what I want to do in Velocity and elsewhere - offer a logging
contract while leaving the push/pull & lifecycle issues in the hands of the
framework/app/container builder, where it belongs (IMO).
If I can find some time, I'll scratch something together - it will be
trivially usable with the existing commons logging - it will use the same
interface Log in fact - so it won't be a competitor but rather augment
o.a.c.l I think a nice name is 'NaturalLog' (math joke...)
>
>> I hope the answer is 'no' also, because otherwise, you are defining
>> framework-like requirements on any app using commons-logging-using
>> components.
>
> If a component wants to use commons-logging, it must obviously
> call it's API in the way commons-logging is designed.
Of course. Just like log4j or logkit. In a sense then, commons-logging is
yet another logger that didn't bother to write the guts, but just used
others. Log4j or logkit could be the same thing. For example, if you had a
logkit or jdk1.4 appender for log4j... (I wonder how fast I'd get run out
of town if I submitted *that* patch :)
LOL
>
> It doesn't impose any other requirement on your component. I'm not
> sure I understand what's your problem here.
I guess the mismatch is that I thought o.a.c.l was a policy-free logger
abstraction allowing components and apps to have a common interface for
logging w/o any implementation requirements, and that the project also
offered impls for log4j, logkit and jdk1.4. As is, its clearly a good
thing because people find it useful, but I think there are other needs.
>
> If you need an aditional interface to allow a standard way for
> components to get a different logger - I'm ok. With the
> current model the underlying logger is in control over what
> and how is logged - commons-logging is just a wrapper ( and
> the associated discovery method ).
I guess its the dictation of the discovery method that I have a problem
with. But it's fixable...
>
> It is curently assumed that each logger will have a name -
> so it can be found by the component on one side, and configured
> in the logger on the other side. In a JMX perspective, it
> makes sense - all objects that are manageable need some name.
It makes sense indeed. But I may not care always about having my own named
logger - as a component, I might just want to spooge out debug info and
think it nicer if it doesn't have to go to stdout.
>
> It is also a common pattern to separate between the actual
> channel ( where the log output goes ) and the 'facade' that
> is viewed by the component. And the pattern is to have
> each component use a logger with a name based on it's class
> ( with the classloader acting as namespace ).
>
> How do you fit the setter in this and what do you actually
> want - I don't know.
You can fit the setter in this - because with the factory alternative
offered by Michael
public interface LogUser
{
public void setLogFactory(LogFactory);
}
you can retain the pull pattern. But you get the benefit of the marker.
This of course shouldn't be the *only* way - because then you have to
specifically manage any logging component, which is a royal pain. Being
able to arbitrarily grab the logger out of thing air is clearly useful....
To summarize : yes, there is clear value in the pull model - makes
integration easy. I think that a generalized interface contract w/o
implementation requirements would be useful too.
>
> My feeling is that an interface to allow some tunning of the
> logging at runtime, in a logger-independent manner is extremenly
> usefull.
Does commons do that? I didn't think so.
> I think some portable way to set the level on a logger would
> be the most important. Since the logging is 2-layered it is possible
> to change the channel without any action in the component, but
> it is not possible to change the actual Log - do you think
> this is that important ?
To be able to change the actual Log? No - because the container/app/etc
implementing the Log interface can do that... Right?
>
>
>> I am not trying to be combative - I just think that this discussion showed
>> me that the commons logger is not as general-purpose as I thought it was -
>
> Yes, it's not general-purpose. It's just an API to allow your components
> to log. Nothing else.
I think that is a little short of the description, because log4j and logkit
did that already. I thought that being 'implementation agnostic' was one of
the goals, and it seem to be in one aspect - the Log interface is used for
any underlying impl (which is good). But in another sense, the pull pattern
requirement (or 'pseudo requirement') seems to exhibit some of the problems
I thought o.a.c.l was trying to solve.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> Are you saying that any component/class/tool that implements the generic
> commons logger Log interface is only usable in an application environment
> where a special class with a static method getLogger() is in the classpath?
> [Modulo the real name of the class and method... You get what I mean, I
> hope...]
The same pattern that is used with JDBC, JNDI, JAXP and about a dozen
other APIs.
I'm not sure what do you mean by 'framework' in this context - of course
every API and package has a set of contracts and APIs. You want a database
connection - you call the DriverManager or look up in JNDI.
There is a LogFactory class that will find you the Log implementation,
and if a logger is to be useable with the commons-logging it must
implement the Log interface ( that's the big one ) and follow the
discovery rules if it wants to be found using the LogFactory.
> I hope the answer is 'no' also, because otherwise, you are defining
> framework-like requirements on any app using commons-logging-using
> components.
If a component wants to use commons-logging, it must obviously
call it's API in the way commons-logging is designed.
It doesn't impose any other requirement on your component. I'm not
sure I understand what's your problem here.
If you need an aditional interface to allow a standard way for
components to get a different logger - I'm ok. With the
current model the underlying logger is in control over what
and how is logged - commons-logging is just a wrapper ( and
the associated discovery method ).
It is curently assumed that each logger will have a name -
so it can be found by the component on one side, and configured
in the logger on the other side. In a JMX perspective, it
makes sense - all objects that are manageable need some name.
It is also a common pattern to separate between the actual
channel ( where the log output goes ) and the 'facade' that
is viewed by the component. And the pattern is to have
each component use a logger with a name based on it's class
( with the classloader acting as namespace ).
How do you fit the setter in this and what do you actually
want - I don't know.
My feeling is that an interface to allow some tunning of the
logging at runtime, in a logger-independent manner is extremenly
usefull.
I think some portable way to set the level on a logger would
be the most important. Since the logging is 2-layered it is possible
to change the channel without any action in the component, but
it is not possible to change the actual Log - do you think
this is that important ?
> I am not trying to be combative - I just think that this discussion showed
> me that the commons logger is not as general-purpose as I thought it was -
Yes, it's not general-purpose. It's just an API to allow your components
to log. Nothing else.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 6:08 PM, "Morgan Delagrange" <md...@yahoo.com> wrote:
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Wednesday, April 03, 2002 4:43 PM
> Subject: Re: [logging] Need interface...
>
>
>> On 4/3/02 5:12 PM, "Morgan Delagrange" <md...@yahoo.com> wrote:
>>
>> [snip]
>>
>>>
>>> I _am_ saying that this interface doesn't make me happy, because as soon
> as
>>> we introduce it people will assert something like, "Commons Component X
> does
>>> not correctly implement the commons-logging component because Class Y
> does
>>> not implement the external configuration interface." I do not want to
>>> implement that interface in other Commons components; I don't think it's
>>> worth it. Therefore I don't support its introduction to the Commons
> logger
>>> component.
>>
>> Therefore - the only valid implementation of the interface that you see is
>> the static, singleton-accessed 'pull' approach?
>>
>> Can that be noted somewhere?
>
> Not at all. If you want your application to implement push Logs, then do
> so. I wouldn't mind the interface if it didn't introduce the expectation
> that a client of commons-logging will implement it.
Wouldn't it be nice then if I said "this component will use a commons
logger" that you can mechanically figure out how? We don't have to then
have another conversation describing how it gets the logger?
That's what happens now, right? There is what appears to be an unspoken
assumption that if I do something like
protected static Log logger = Log.getLogger(...);
>From within my component, it will magically work and not randomly chuck a
ClassNotFoundException depending on the app using the component?
>
>>>
>>>>> since we don't expect such behaviour in Commons components, it seems
>>>>> counter-productive to support it in the logger, which would introduce
>>> the
>>>>> possibility of such an interface being used inconsistently.
>>>>
>>>> Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ),
> Axis,
>>>> etc are all essentially based on the JavaBeans patterns.
>>>>
>>>> Tomcat is now going even deeper into this with JMX support, and many
>>>> discussion on ant sugest more 'configurability' for components is
>>>> desired.
>>>>
>>>>
>>>> I'm also not sure what 'inconsistent' use means for you - I think
>>>> ant, tomcat and most other projects I know are consistently using the
>>>> bean methods, togheter with JNDI and other pull patterns.
>>>
>>> I only said that, "In this particular case, [Commons component
> developers]
>>> do not require that an external framework/factory/whatever generate Log
>>> objects for individual classes". I didn't say that Commons components
>>> should not have bean methods. Of course they should, when appropriate.
> I
>>> don't think logging is one of those cases. If we add this interface, I
> fear
>>> that some components will start to adopt it internally, while others
> will
>>> not. That's what I mean by using the interface inconsistently.
>>>
>>
>> Are you saying that the Commons Logging component is for internal use only
>> by commons components?
>>
>
> Of course not.
>
Ok, good.
Are you saying that any component/class/tool that implements the generic
commons logger Log interface is only usable in an application environment
where a special class with a static method getLogger() is in the classpath?
[Modulo the real name of the class and method... You get what I mean, I
hope...]
I hope the answer is 'no' also, because otherwise, you are defining
framework-like requirements on any app using commons-logging-using
components.
I am not trying to be combative - I just think that this discussion showed
me that the commons logger is not as general-purpose as I thought it was -
so either I made a huge mistake in leaping to conclusions, or I came at it
from a different angle that has some validity :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, April 03, 2002 4:43 PM
Subject: Re: [logging] Need interface...
> On 4/3/02 5:12 PM, "Morgan Delagrange" <md...@yahoo.com> wrote:
>
> [snip]
>
> >
> > I _am_ saying that this interface doesn't make me happy, because as soon
as
> > we introduce it people will assert something like, "Commons Component X
does
> > not correctly implement the commons-logging component because Class Y
does
> > not implement the external configuration interface." I do not want to
> > implement that interface in other Commons components; I don't think it's
> > worth it. Therefore I don't support its introduction to the Commons
logger
> > component.
>
> Therefore - the only valid implementation of the interface that you see is
> the static, singleton-accessed 'pull' approach?
>
> Can that be noted somewhere?
Not at all. If you want your application to implement push Logs, then do
so. I wouldn't mind the interface if it didn't introduce the expectation
that a client of commons-logging will implement it.
> >
> >>> since we don't expect such behaviour in Commons components, it seems
> >>> counter-productive to support it in the logger, which would introduce
> > the
> >>> possibility of such an interface being used inconsistently.
> >>
> >> Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ),
Axis,
> >> etc are all essentially based on the JavaBeans patterns.
> >>
> >> Tomcat is now going even deeper into this with JMX support, and many
> >> discussion on ant sugest more 'configurability' for components is
> >> desired.
> >>
> >>
> >> I'm also not sure what 'inconsistent' use means for you - I think
> >> ant, tomcat and most other projects I know are consistently using the
> >> bean methods, togheter with JNDI and other pull patterns.
> >
> > I only said that, "In this particular case, [Commons component
developers]
> > do not require that an external framework/factory/whatever generate Log
> > objects for individual classes". I didn't say that Commons components
> > should not have bean methods. Of course they should, when appropriate.
I
> > don't think logging is one of those cases. If we add this interface, I
fear
> > that some components will start to adopt it internally, while others
will
> > not. That's what I mean by using the interface inconsistently.
> >
>
> Are you saying that the Commons Logging component is for internal use only
> by commons components?
>
Of course not.
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 5:12 PM, "Morgan Delagrange" <md...@yahoo.com> wrote:
[snip]
>
> I _am_ saying that this interface doesn't make me happy, because as soon as
> we introduce it people will assert something like, "Commons Component X does
> not correctly implement the commons-logging component because Class Y does
> not implement the external configuration interface." I do not want to
> implement that interface in other Commons components; I don't think it's
> worth it. Therefore I don't support its introduction to the Commons logger
> component.
Therefore - the only valid implementation of the interface that you see is
the static, singleton-accessed 'pull' approach?
Can that be noted somewhere?
>
>>> since we don't expect such behaviour in Commons components, it seems
>>> counter-productive to support it in the logger, which would introduce
> the
>>> possibility of such an interface being used inconsistently.
>>
>> Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ), Axis,
>> etc are all essentially based on the JavaBeans patterns.
>>
>> Tomcat is now going even deeper into this with JMX support, and many
>> discussion on ant sugest more 'configurability' for components is
>> desired.
>>
>>
>> I'm also not sure what 'inconsistent' use means for you - I think
>> ant, tomcat and most other projects I know are consistently using the
>> bean methods, togheter with JNDI and other pull patterns.
>
> I only said that, "In this particular case, [Commons component developers]
> do not require that an external framework/factory/whatever generate Log
> objects for individual classes". I didn't say that Commons components
> should not have bean methods. Of course they should, when appropriate. I
> don't think logging is one of those cases. If we add this interface, I fear
> that some components will start to adopt it internally, while others will
> not. That's what I mean by using the interface inconsistently.
>
Are you saying that the Commons Logging component is for internal use only
by commons components?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: <co...@covalent.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
"Morgan Delagrange" <mo...@apache.org>
Sent: Wednesday, April 03, 2002 4:37 PM
Subject: Re: [logging] Need interface...
> On Wed, 3 Apr 2002, Morgan Delagrange wrote:
>
> > I _am_ saying that this interface doesn't make me happy, because as soon
as
> > we introduce it people will assert something like, "Commons Component X
does
> > not correctly implement the commons-logging component because Class Y
does
> > not implement the external configuration interface." I do not want to
>
> Component X doesn't implement commons-logging, it just uses it.
But that's the expectation you introduce with that interface, that
components using commons-logging will implement a particular interface.
> And it was perfectly clear this is a marker interfaces, that'll just say
> that X supports runtime configuration of the logger.
>
> If X uses a different method to set the logger - then we have a small
> problem.
>
>
> > implement that interface in other Commons components; I don't think it's
> > worth it. Therefore I don't support its introduction to the Commons
logger
> > component.
>
> I do have a problem with this kind of arguments - "I don't need it, so
> nobody needs it as well".
Again with the strange attributions. I didn't say "I don't need it", I'm
saying it introduces the expectation that other Commons components (and any
other client of commons-logging) will implement it.
> I actually miss a lot the setDebug() model used in tomcat3 - where you can
> set debugging on a component level. Yes, you can do the same by setting
> the property on the logger used by the component, but I think it's cleaner
> if this is part of the component configuration.
>
> Not all programs need runtime (re)configuration - but some do, and
> the fact that you don't need it in your programs shouldn't be a valid
> reson for -1.
You've misinterpreted my comments. If I think it makes implementation of
commons-logging more confusing, that's a valid reason.
> I think this is a general enough problem.
>
>
> > I only said that, "In this particular case, [Commons component
developers]
> > do not require that an external framework/factory/whatever generate Log
> > objects for individual classes". I didn't say that Commons components
> > should not have bean methods. Of course they should, when appropriate.
I
> > don't think logging is one of those cases. If we add this interface, I
fear
> > that some components will start to adopt it internally, while others
will
> > not. That's what I mean by using the interface inconsistently.
>
> That's perfectly fine - components that need runtime changes in the log
> object will use it, those who don't will not use it.
I don't agree. I think it's confusing if some components are externally
configurable and some are not. I don't think you can cleanly categorize
components that need logging vs. those that don't. Either the logs are
consistently assigned by package name, or they are externally assignable
(possibly defaulting to package name). I don't think some combination
thereof is practical. And I don't want to revisit all the components to
make their Logs externally assignable.
> If you want a property to be modifiable, you add a setter. That doesn't
> mean all properties must have setters, or you need a 'framework' to call
> the setters.
>
> Is the Logger instance something to modify ? Probably not, since it is
> just a named wrapper and you can change the object underneath.
>
> But having a setLogLevel() and setLogName() in a component that supports
> this is valid.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
> I _am_ saying that this interface doesn't make me happy, because as soon as
> we introduce it people will assert something like, "Commons Component X does
> not correctly implement the commons-logging component because Class Y does
> not implement the external configuration interface." I do not want to
Component X doesn't implement commons-logging, it just uses it.
And it was perfectly clear this is a marker interfaces, that'll just say
that X supports runtime configuration of the logger.
If X uses a different method to set the logger - then we have a small
problem.
> implement that interface in other Commons components; I don't think it's
> worth it. Therefore I don't support its introduction to the Commons logger
> component.
I do have a problem with this kind of arguments - "I don't need it, so
nobody needs it as well".
I actually miss a lot the setDebug() model used in tomcat3 - where you can
set debugging on a component level. Yes, you can do the same by setting
the property on the logger used by the component, but I think it's cleaner
if this is part of the component configuration.
Not all programs need runtime (re)configuration - but some do, and
the fact that you don't need it in your programs shouldn't be a valid
reson for -1.
I think this is a general enough problem.
> I only said that, "In this particular case, [Commons component developers]
> do not require that an external framework/factory/whatever generate Log
> objects for individual classes". I didn't say that Commons components
> should not have bean methods. Of course they should, when appropriate. I
> don't think logging is one of those cases. If we add this interface, I fear
> that some components will start to adopt it internally, while others will
> not. That's what I mean by using the interface inconsistently.
That's perfectly fine - components that need runtime changes in the log
object will use it, those who don't will not use it.
If you want a property to be modifiable, you add a setter. That doesn't
mean all properties must have setters, or you need a 'framework' to call
the setters.
Is the Logger instance something to modify ? Probably not, since it is
just a named wrapper and you can change the object underneath.
But having a setLogLevel() and setLogName() in a component that supports
this is valid.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: <co...@covalent.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
"Morgan Delagrange" <mo...@apache.org>
Sent: Wednesday, April 03, 2002 3:04 PM
Subject: Re: [logging] Need interface...
> On Wed, 3 Apr 2002, Morgan Delagrange wrote:
>
> > > Please move the discussion about IoC and Avalon to avalon-dev.
> >
> > I'm sorry if this is such a politically charged term for you. I'm
merely
> > referring to the practice of externally generating a class' Log object.
> > Call it what you like.
>
> The practice of allowing an external class to set the log object is
> pretty standard since Beans were used the first time.
>
> The practice of forcing all components to use setters and not allowing
> pull is specific to Avalon.
>
> Jumping from 'allowing a component to be managed by having a setter' to
> 'all compoents should be configured only with setters and everyone
> should use only IoC' is what I don't like in this context.
Fine by me. All I mean to refer to is externally setting the Log object.
Use whatever terminology makes you comfortable.
>
> > > Most of the components implement Beans patterns and should support
> > > runtime changes to config ( JMX or not ). That has nothing to
> > > do with any inversion of control, it's standard java.
> >
> > In this particular case, we would not implement this interface in our
> > components, because we do not require that an external
> > framework/factory/whatever generate Log objects for individual classes.
And
>
> Yes, we do not _require_ an external 'whatever' to generate and set the
> Log objects.
>
> But that doesn't mean we shouldn't _allow_ 'watever' to set or change
> the Log object.
>
> That's the difference. Not _allowing_ this because some other project is
> forcing everyone to use only this pattern is a bit crazy.
I'm not saying that we shouldn't allow you to set an external Logger because
Avalon requires it.
I _am_ saying that this interface doesn't make me happy, because as soon as
we introduce it people will assert something like, "Commons Component X does
not correctly implement the commons-logging component because Class Y does
not implement the external configuration interface." I do not want to
implement that interface in other Commons components; I don't think it's
worth it. Therefore I don't support its introduction to the Commons logger
component.
> > since we don't expect such behaviour in Commons components, it seems
> > counter-productive to support it in the logger, which would introduce
the
> > possibility of such an interface being used inconsistently.
>
> Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ), Axis,
> etc are all essentially based on the JavaBeans patterns.
>
> Tomcat is now going even deeper into this with JMX support, and many
> discussion on ant sugest more 'configurability' for components is
> desired.
>
>
> I'm also not sure what 'inconsistent' use means for you - I think
> ant, tomcat and most other projects I know are consistently using the
> bean methods, togheter with JNDI and other pull patterns.
I only said that, "In this particular case, [Commons component developers]
do not require that an external framework/factory/whatever generate Log
objects for individual classes". I didn't say that Commons components
should not have bean methods. Of course they should, when appropriate. I
don't think logging is one of those cases. If we add this interface, I fear
that some components will start to adopt it internally, while others will
not. That's what I mean by using the interface inconsistently.
>
> It may be 'inconsistent' from Avalon perspective, but that doesn't mean
> we shouldn't use it. We don't claim to support IoC.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Costin et al,
Avalon is a FRAMEWORK and they are IoC obcessed.
Imposing IoC to components outside a framework context might be wrong
since people get scared about it and that obviously does not help their
adoption.
However, "religiously" using IoC in a framework or in something like
Tomcat makes all the sense.
I do use "component" (as above) in a wider sense than the Avalon guys
and I do not agree about everything they do, but dismissing Avalon
just because they seem too obcessed about what you perceive as their
little world of concepts and their closed culture is wrong and even
very stupid.
They have their own vocabulary and culture, but I do not think it is a
closed one. And their obcession with IoC and a couple of other concepts
is the reason they developed its use soo much and the reason they have
so much one can learn from.
As many of you are aware of, I know quite well the code of many Jakarta
and other Apache java projects. Still, the projects I learned the most
from are all Avalon related (Avalon, Cocoon and Ant-Myrmidon proposal).
I am far from totally agreeing with wathever is the Avalon way, but
there is a lot to learn from it and from its "culture".
On the "culture" side, Avalon provided me with the most helpful block
of concepts/vocabulary I found since discovering the Gang-of-four
Design Patterns. It actually helps me organizing my ideas and
communicating them.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Wednesday, April 03, 2002 11:04 PM
> To: Jakarta Commons Developers List; Morgan Delagrange
> Subject: Re: [logging] Need interface...
>
>
> On Wed, 3 Apr 2002, Morgan Delagrange wrote:
>
> > > Please move the discussion about IoC and Avalon to avalon-dev.
> >
> > I'm sorry if this is such a politically charged term for you.
> I'm merely
> > referring to the practice of externally generating a class' Log object.
> > Call it what you like.
>
> The practice of allowing an external class to set the log object is
> pretty standard since Beans were used the first time.
>
> The practice of forcing all components to use setters and not allowing
> pull is specific to Avalon.
>
> Jumping from 'allowing a component to be managed by having a setter' to
> 'all compoents should be configured only with setters and everyone
> should use only IoC' is what I don't like in this context.
>
>
> > > Most of the components implement Beans patterns and should support
> > > runtime changes to config ( JMX or not ). That has nothing to
> > > do with any inversion of control, it's standard java.
> >
> > In this particular case, we would not implement this interface in our
> > components, because we do not require that an external
> > framework/factory/whatever generate Log objects for individual
> classes. And
>
> Yes, we do not _require_ an external 'whatever' to generate and set the
> Log objects.
>
> But that doesn't mean we shouldn't _allow_ 'watever' to set or change
> the Log object.
>
> That's the difference. Not _allowing_ this because some other project is
> forcing everyone to use only this pattern is a bit crazy.
>
>
> > since we don't expect such behaviour in Commons components, it seems
> > counter-productive to support it in the logger, which would
> introduce the
> > possibility of such an interface being used inconsistently.
>
> Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ), Axis,
> etc are all essentially based on the JavaBeans patterns.
>
> Tomcat is now going even deeper into this with JMX support, and many
> discussion on ant sugest more 'configurability' for components is
> desired.
>
>
> I'm also not sure what 'inconsistent' use means for you - I think
> ant, tomcat and most other projects I know are consistently using the
> bean methods, togheter with JNDI and other pull patterns.
>
>
> It may be 'inconsistent' from Avalon perspective, but that doesn't mean
> we shouldn't use it. We don't claim to support IoC.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
>
> On Wed, 3 Apr 2002, Morgan Delagrange wrote:
>
> > > Please move the discussion about IoC and Avalon to avalon-dev.
> >
> > I'm sorry if this is such a politically charged term for you. I'm
> > merely referring to the practice of externally generating a
> class' Log
> > object. Call it what you like.
>
> The practice of allowing an external class to set the log
> object is pretty standard since Beans were used the first time.
>
> The practice of forcing all components to use setters and not
> allowing pull is specific to Avalon.
And Servlets. You are handed a Context object--with the Context.log()
method. You have no choice over what log level or implementation you
use.
>
> Jumping from 'allowing a component to be managed by having a
> setter' to 'all compoents should be configured only with
> setters and everyone should use only IoC' is what I don't
> like in this context.
Did you once here me say *everyone should use only IoC*?
I never said that, so don't twist words. I said that projects
built on IoC should not have static accessors. Granted the
impact of static accessors for a logging implementation is
low, consistency does help.
Not to mention, components can be used in different logical
sections of a system. If your log categories are set up according
to functional unit (as is the practice in Cocoon and other
apps like it), the Logger will most likely be different depending on
which system it is used inside of.
> > > Most of the components implement Beans patterns and
> should support
> > > runtime changes to config ( JMX or not ). That has nothing to do
> > > with any inversion of control, it's standard java.
> >
> > In this particular case, we would not implement this
> interface in our
> > components, because we do not require that an external
> > framework/factory/whatever generate Log objects for individual
> > classes. And
>
> Yes, we do not _require_ an external 'whatever' to generate
> and set the
> Log objects.
>
> But that doesn't mean we shouldn't _allow_ 'watever' to set or change
> the Log object.
>
> That's the difference. Not _allowing_ this because some other
> project is
> forcing everyone to use only this pattern is a bit crazy.
Again you missed the main point. If you want to *allow* overriding
of a logger by another class so be it. Don't call it IoC.
I jumped in this discussion because someone else started using the
term IoC, and I wanted to clarify the understanding around it.
Jumping to conclusions is crazy.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
> > Please move the discussion about IoC and Avalon to avalon-dev.
>
> I'm sorry if this is such a politically charged term for you. I'm merely
> referring to the practice of externally generating a class' Log object.
> Call it what you like.
The practice of allowing an external class to set the log object is
pretty standard since Beans were used the first time.
The practice of forcing all components to use setters and not allowing
pull is specific to Avalon.
Jumping from 'allowing a component to be managed by having a setter' to
'all compoents should be configured only with setters and everyone
should use only IoC' is what I don't like in this context.
> > Most of the components implement Beans patterns and should support
> > runtime changes to config ( JMX or not ). That has nothing to
> > do with any inversion of control, it's standard java.
>
> In this particular case, we would not implement this interface in our
> components, because we do not require that an external
> framework/factory/whatever generate Log objects for individual classes. And
Yes, we do not _require_ an external 'whatever' to generate and set the
Log objects.
But that doesn't mean we shouldn't _allow_ 'watever' to set or change
the Log object.
That's the difference. Not _allowing_ this because some other project is
forcing everyone to use only this pattern is a bit crazy.
> since we don't expect such behaviour in Commons components, it seems
> counter-productive to support it in the logger, which would introduce the
> possibility of such an interface being used inconsistently.
Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ), Axis,
etc are all essentially based on the JavaBeans patterns.
Tomcat is now going even deeper into this with JMX support, and many
discussion on ant sugest more 'configurability' for components is
desired.
I'm also not sure what 'inconsistent' use means for you - I think
ant, tomcat and most other projects I know are consistently using the
bean methods, togheter with JNDI and other pull patterns.
It may be 'inconsistent' from Avalon perspective, but that doesn't mean
we shouldn't use it. We don't claim to support IoC.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: <co...@covalent.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<mo...@apache.org>
Sent: Wednesday, April 03, 2002 2:26 PM
Subject: Re: [logging] Need interface...
> On Wed, 3 Apr 2002, Morgan Delagrange wrote:
>
> > Is that not also the case with Log4J and JDK 1.4?
> > Only the Avalon logger has a notion of IoC AFAIK. It
> > seems odd to be supporting IoC logging in
> > commons-logging, when we know that all of our other
> > components will not be able to utilize it.
>
> Please move the discussion about IoC and Avalon to avalon-dev.
I'm sorry if this is such a politically charged term for you. I'm merely
referring to the practice of externally generating a class' Log object.
Call it what you like.
> The proposal didn't mentioned IoC and I don't see how this get into
> this.
>
> Most of the components implement Beans patterns and should support
> runtime changes to config ( JMX or not ). That has nothing to
> do with any inversion of control, it's standard java.
In this particular case, we would not implement this interface in our
components, because we do not require that an external
framework/factory/whatever generate Log objects for individual classes. And
since we don't expect such behaviour in Commons components, it seems
counter-productive to support it in the logger, which would introduce the
possibility of such an interface being used inconsistently.
> Avalon and IoC are 'special' in that they require only one way
> to do things - and that's not something we'll do in commons or
> other projects. But that's their problem, not ours.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
> Is that not also the case with Log4J and JDK 1.4?
> Only the Avalon logger has a notion of IoC AFAIK. It
> seems odd to be supporting IoC logging in
> commons-logging, when we know that all of our other
> components will not be able to utilize it.
Please move the discussion about IoC and Avalon to avalon-dev.
The proposal didn't mentioned IoC and I don't see how this get into
this.
Most of the components implement Beans patterns and should support
runtime changes to config ( JMX or not ). That has nothing to
do with any inversion of control, it's standard java.
Avalon and IoC are 'special' in that they require only one way
to do things - and that's not something we'll do in commons or
other projects. But that's their problem, not ours.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>
> On 4/3/02 3:18 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>
<snip/>
> >
> > My point exactly.
> >
> > Commons Logging should be for all modules that do not
> > use IoC.
> >
>
> Commons logging should be for all modules that want a generic
> logging interface.
>
> In my opinion anyway... :)
>
>
> > For those that do need IoC, they either need to use Avalon
> or create
> > their own framework. (Hopefully, use Avalon ;P )
> >
>
> And in that framework, can they have their components use the
> generic commons interface for logging?
We haven't created a wrapper for it if that's what you mean. Avalon
provides a wrapper that is syntactically similar to commons--but
has a different interface name.
As I said, Avalon's logger abstraction was officially released first.
There was no official (i.e. released) commons logging at the time.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 3:18 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>> -----Original Message-----
>> From: Morgan Delagrange [mailto:mdelagra@yahoo.com]
>>
>> --- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>>> On 4/3/02 2:45 PM, "costinm@covalent.net" <co...@covalent.net>
>>> wrote:
>>>
>>>> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>>>>
>>>>> Yes, that's true. I didn't realize that it
>>> o.a.c.l was actually a logging
>>>>> framework.... I thought it was an interface we
>>> could write to in order to
>>>>> isolate ourselves from changing logger
>>> preferences...
>>>>
>>>> It's a logging API, with interfaces you can use to
>>> isolated from the
>>>> logger implementation.
>>>>
>>>
>>> However, it seems that the Log.getLogger(foo)
>>> pattern is what people have to
>>> use, or are expected to use?
>>>
>>
>> Is that not also the case with Log4J and JDK 1.4?
>> Only the Avalon logger has a notion of IoC AFAIK. It
>> seems odd to be supporting IoC logging in
>> commons-logging, when we know that all of our other
>> components will not be able to utilize it.
>
> My point exactly.
>
> Commons Logging should be for all modules that do not
> use IoC.
>
Commons logging should be for all modules that want a generic logging
interface.
In my opinion anyway... :)
> For those that do need IoC, they either need to use Avalon or
> create their own framework. (Hopefully, use Avalon ;P )
>
And in that framework, can they have their components use the generic
commons interface for logging?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Morgan Delagrange [mailto:mdelagra@yahoo.com]
>
> --- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> > On 4/3/02 2:45 PM, "costinm@covalent.net" <co...@covalent.net>
> > wrote:
> >
> > > On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> > >
> > >> Yes, that's true. I didn't realize that it
> > o.a.c.l was actually a logging
> > >> framework.... I thought it was an interface we
> > could write to in order to
> > >> isolate ourselves from changing logger
> > preferences...
> > >
> > > It's a logging API, with interfaces you can use to
> > isolated from the
> > > logger implementation.
> > >
> >
> > However, it seems that the Log.getLogger(foo)
> > pattern is what people have to
> > use, or are expected to use?
> >
>
> Is that not also the case with Log4J and JDK 1.4?
> Only the Avalon logger has a notion of IoC AFAIK. It
> seems odd to be supporting IoC logging in
> commons-logging, when we know that all of our other
> components will not be able to utilize it.
My point exactly.
Commons Logging should be for all modules that do not
use IoC.
For those that do need IoC, they either need to use Avalon or
create their own framework. (Hopefully, use Avalon ;P )
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 3:15 PM, "Morgan Delagrange" <md...@yahoo.com> wrote:
>
> --- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> On 4/3/02 2:45 PM, "costinm@covalent.net"
>> <co...@covalent.net> wrote:
>>
>>> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>>>
>>>> Yes, that's true. I didn't realize that it
>> o.a.c.l was actually a logging
>>>> framework.... I thought it was an interface we
>> could write to in order to
>>>> isolate ourselves from changing logger
>> preferences...
>>>
>>> It's a logging API, with interfaces you can use to
>> isolated from the
>>> logger implementation.
>>>
>>
>> However, it seems that the Log.getLogger(foo)
>> pattern is what people have to
>> use, or are expected to use?
>>
>
> Is that not also the case with Log4J and JDK 1.4?
Literally, yes - however, I am more than happy to write things where only
the app/container/framework/servlet interacts with the logger, and then has
a generic wrapping interface that it passes to subsystems/components such
that the pieces that can log don't know about the implementation to which
they are logging.
That's what I think you want o.a.c.l to be...
We have the same notion in Velocity - we define the interface that you can
use, and do an impl around log4j and logkit. (as well as a bitbucket and
stderr impls as well).
But you as the app writer can also implement that interface on whatever
logger you are using, such as something you already have in your application
servers, and pass that to velocity to use....
> Only the Avalon logger has a notion of IoC AFAIK. It
> seems odd to be supporting IoC logging in
> commons-logging, when we know that all of our other
> components will not be able to utilize it.
>
Then commons logging should not have public interfaces. It should only be
available to anything living in the o.a.c package, because you appear to be
forcing a usage pattern upon anyone that implements the interface...
If you want to put draw a line in the sand for people to use as *the*
generic logging interface for *general* use, it shouldn't prohibit IoC.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Morgan Delagrange <md...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> On 4/3/02 2:45 PM, "costinm@covalent.net"
> <co...@covalent.net> wrote:
>
> > On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> >
> >> Yes, that's true. I didn't realize that it
> o.a.c.l was actually a logging
> >> framework.... I thought it was an interface we
> could write to in order to
> >> isolate ourselves from changing logger
> preferences...
> >
> > It's a logging API, with interfaces you can use to
> isolated from the
> > logger implementation.
> >
>
> However, it seems that the Log.getLogger(foo)
> pattern is what people have to
> use, or are expected to use?
>
Is that not also the case with Log4J and JDK 1.4?
Only the Avalon logger has a notion of IoC AFAIK. It
seems odd to be supporting IoC logging in
commons-logging, when we know that all of our other
components will not be able to utilize it.
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> On 4/3/02 2:45 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
>
> > On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> >
> >> Yes, that's true. I didn't realize that it o.a.c.l was actually a logging
> >> framework.... I thought it was an interface we could write to in order to
> >> isolate ourselves from changing logger preferences...
> >
> > It's a logging API, with interfaces you can use to isolated from the
> > logger implementation.
> >
>
> However, it seems that the Log.getLogger(foo) pattern is what people have to
> use, or are expected to use?
There is no such requirement or expectation AFAIK.
Log.getLogger() is extremely easy to use, have the least overhead - that's
why most people use that. Nothing prevent you from creating the logger and
setting it in a manager application.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 2:45 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>
>> Yes, that's true. I didn't realize that it o.a.c.l was actually a logging
>> framework.... I thought it was an interface we could write to in order to
>> isolate ourselves from changing logger preferences...
>
> It's a logging API, with interfaces you can use to isolated from the
> logger implementation.
>
However, it seems that the Log.getLogger(foo) pattern is what people have to
use, or are expected to use?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> Yes, that's true. I didn't realize that it o.a.c.l was actually a logging
> framework.... I thought it was an interface we could write to in order to
> isolate ourselves from changing logger preferences...
It's a logging API, with interfaces you can use to isolated from the
logger implementation.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 2:26 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>
>>> class MyComponent
>>> implements Component, LogEnabled
>>> {
>>> private static Logger logger = Log.getLogger();
>>>
>>> myMethod()
>>> {
>>> logger.info("Hello World!");
>>> }
>>> }
>>>
>>> Seems so much cleaner of a design to me and it is impossible to get an NPE.
>>
>> Except that forces there to be something called Log in the classpath. In
>> the case where you are using the component/tool in an environment where that
>> doesn't exist, you'll get a different exception, out of your control...
>
> Well, if you implement LogUser you'll still have to have commons-logging
> in the classpath, wouldn't you ?
>
Yes, that's true. I didn't realize that it o.a.c.l was actually a logging
framework.... I thought it was an interface we could write to in order to
isolate ourselves from changing logger preferences...
>
> I'm thinking as:
>
> class MyClass implements LogUser {
> // default logger
> private static Logger logger = Log.getLogger(MyClass.class);
>
> public void setLogger( Log log ) {
> logger=log;
> }
That works too.
> ...
> if( logger.isDebugEnabled() ) logger.debug("Something" );
> }
>
> You start with a normal default, but at runtime the user decides he wants
> a different logger. Of course, this could be done by managing the logging
> implementation itself.
Yep
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> > class MyComponent
> > implements Component, LogEnabled
> > {
> > private static Logger logger = Log.getLogger();
> >
> > myMethod()
> > {
> > logger.info("Hello World!");
> > }
> > }
> >
> > Seems so much cleaner of a design to me and it is impossible to get an NPE.
>
> Except that forces there to be something called Log in the classpath. In
> the case where you are using the component/tool in an environment where that
> doesn't exist, you'll get a different exception, out of your control...
Well, if you implement LogUser you'll still have to have commons-logging
in the classpath, wouldn't you ?
I'm thinking as:
class MyClass implements LogUser {
// default logger
private static Logger logger = Log.getLogger(MyClass.class);
public void setLogger( Log log ) {
logger=log;
}
...
if( logger.isDebugEnabled() ) logger.debug("Something" );
}
You start with a normal default, but at runtime the user decides he wants
a different logger. Of course, this could be done by managing the logging
implementation itself.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 1:53 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> on 4/3/02 10:46 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>> Right - and with what I am thinking about, be defensive. Don't just use
>> 'logger' - wrap it with a check.
>>
>> Or have an internal log method that does that....
>
> So, for every class, I now also need to copy/paste in some log method?
>
> <sarcastic>
> Now that is smart OO engineering.
> </sarcastic>
<stunned by the pointlessness of this>
or you could just derive your components from a base class
</stunned by the pointlessness of this>
>
>>>
>>> I really don't understand why that is better than the Pull model which would
>>> be more like this:
>>>
>>> class MyComponent
>>> implements Component, LogEnabled
>>> {
>>> private static Logger logger = Log.getLogger();
>>>
>>> myMethod()
>>> {
>>> logger.info("Hello World!");
>>> }
>>> }
>>>
>>> Seems so much cleaner of a design to me and it is impossible to get an NPE.
>>
>> Except that forces there to be something called Log in the classpath. In
>> the case where you are using the component/tool in an environment where that
>> doesn't exist, you'll get a different exception, out of your control...
>
> Isn't the point of the Commons project to come up with a set of re-usable
> components? Isn't the point of the Commons-Logging project to come up with a
> small .jar file that you can just drop into your classpath and use with
> whatever logging system you want?
Could be - if that is all it is, I think it's missing something major :
defining a standard interface for logging for which implementations
beyond the current loggers can be created.
So if I have an existing application with a logging system, I don't need to
throw it away - I just put a wrapper around it that implements o.a.c.l.Log,
and all compoenents that use Log can use it. We took the same approach in
Velocity, and it works great - I have linked the velocity log flow into
existing log systems at my clients...
I think forcing the singleton approach sucks.
>
> Seems that we are trying to avoid the point of why we write software for
> Jakarta.
Which is what? Not invented here? :)
>
> :-)
>
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Jon Scott Stevens [mailto:jon@latchkey.com]
>
> on 4/3/02 10:46 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > Right - and with what I am thinking about, be defensive.
> Don't just
> > use 'logger' - wrap it with a check.
> >
> > Or have an internal log method that does that....
>
> So, for every class, I now also need to copy/paste in some log method?
>
> <sarcastic>
> Now that is smart OO engineering.
> </sarcastic>
:) Agree.
> >> I really don't understand why that is better than the Pull model
> >> which would be more like this:
> >>
> >> class MyComponent
> >> implements Component, LogEnabled
> >> {
> >> private static Logger logger = Log.getLogger();
> >>
> >> myMethod()
> >> {
> >> logger.info("Hello World!");
> >> }
> >> }
> >>
> >> Seems so much cleaner of a design to me and it is
> impossible to get
> >> an NPE.
> >
> > Except that forces there to be something called Log in the
> classpath.
> > In the case where you are using the component/tool in an
> environment
> > where that doesn't exist, you'll get a different exception, out of
> > your control...
>
> Isn't the point of the Commons project to come up with a set
> of re-usable components? Isn't the point of the
> Commons-Logging project to come up with a small .jar file
> that you can just drop into your classpath and use with
> whatever logging system you want?
>
> Seems that we are trying to avoid the point of why we write
> software for Jakarta.
It also seems that you guys are forgetting Container/Component
relationships.
Avalon uses Factory classes to ensure the proper lifecycle of a
component.
Excalibur's component package and the new container package (soon to be
renamed)
are examples of that approach.
You only need to be defensive if you don't trust your container. Is it
possible to get an NPE? Sure it is, but the likelihood of it happening
if
the component is instantiated by a proper factory class is nill. It's
when
you start mucking around with creating your own containers and such that
you have to be careful... That's why we use classes to encapsulate the
complex lifecycle stuff on our components. There is less room for
mistakes.
BTW, we will be altering the Avalon AbstractLogEnabled to throw an
exception
if no logger has been set before it is called.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 4/3/02 10:46 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> Right - and with what I am thinking about, be defensive. Don't just use
> 'logger' - wrap it with a check.
>
> Or have an internal log method that does that....
So, for every class, I now also need to copy/paste in some log method?
<sarcastic>
Now that is smart OO engineering.
</sarcastic>
>>
>> I really don't understand why that is better than the Pull model which would
>> be more like this:
>>
>> class MyComponent
>> implements Component, LogEnabled
>> {
>> private static Logger logger = Log.getLogger();
>>
>> myMethod()
>> {
>> logger.info("Hello World!");
>> }
>> }
>>
>> Seems so much cleaner of a design to me and it is impossible to get an NPE.
>
> Except that forces there to be something called Log in the classpath. In
> the case where you are using the component/tool in an environment where that
> doesn't exist, you'll get a different exception, out of your control...
Isn't the point of the Commons project to come up with a set of re-usable
components? Isn't the point of the Commons-Logging project to come up with a
small .jar file that you can just drop into your classpath and use with
whatever logging system you want?
Seems that we are trying to avoid the point of why we write software for
Jakarta.
:-)
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 1:09 PM, "Jon Scott Stevens" <jo...@latchkey.com> wrote:
> on 4/3/02 8:51 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
>>> http://jakarta.apache.org/avalon/framework/inversion-of-control.html
>>>
>>
>> I knew that's what the Avalon-ers call it, and that's where the idea came
>> from, but I didn't want to stir that up...
>
> Part of the problem with this Avalon design *IMHO* is that you more easily
> risk an NPE...for example, in the above URL, it has the following code:
>
> class MyComponent
> implements Component, LogEnabled
> {
> Logger logger;
>
> public enableLogging(Logger newLogger)
> {
> this.logger = newLogger;
> }
>
> myMethod()
> {
> logger.info("Hello World!");
> }
> }
>
> Now, if the parent instantiates MyComponent and forgets to call
> enableLogging() *before* myMethod() is called, an NPE will be thrown and it
> will not be clear as to why that NPE was thrown unless you go and look at
> the source code. There is no open coding contract that says that
> enableLogging() needs to be called first.
Right - and with what I am thinking about, be defensive. Don't just use
'logger' - wrap it with a check.
>
> If you don't want the NPE to be thrown, then every time you want to log, you
> would have to do something like this:
>
> if (logger != null)
> {
> logger.info("Hello World!");
> }
>
> A real pain in the ass.
Or have an internal log method that does that....
>
> I really don't understand why that is better than the Pull model which would
> be more like this:
>
> class MyComponent
> implements Component, LogEnabled
> {
> private static Logger logger = Log.getLogger();
>
> myMethod()
> {
> logger.info("Hello World!");
> }
> }
>
> Seems so much cleaner of a design to me and it is impossible to get an NPE.
Except that forces there to be something called Log in the classpath. In
the case where you are using the component/tool in an environment where that
doesn't exist, you'll get a different exception, out of your control...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 4/3/02 8:51 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> http://jakarta.apache.org/avalon/framework/inversion-of-control.html
>>
>
> I knew that's what the Avalon-ers call it, and that's where the idea came
> from, but I didn't want to stir that up...
Part of the problem with this Avalon design *IMHO* is that you more easily
risk an NPE...for example, in the above URL, it has the following code:
class MyComponent
implements Component, LogEnabled
{
Logger logger;
public enableLogging(Logger newLogger)
{
this.logger = newLogger;
}
myMethod()
{
logger.info("Hello World!");
}
}
Now, if the parent instantiates MyComponent and forgets to call
enableLogging() *before* myMethod() is called, an NPE will be thrown and it
will not be clear as to why that NPE was thrown unless you go and look at
the source code. There is no open coding contract that says that
enableLogging() needs to be called first.
If you don't want the NPE to be thrown, then every time you want to log, you
would have to do something like this:
if (logger != null)
{
logger.info("Hello World!");
}
A real pain in the ass.
I really don't understand why that is better than the Pull model which would
be more like this:
class MyComponent
implements Component, LogEnabled
{
private static Logger logger = Log.getLogger();
myMethod()
{
logger.info("Hello World!");
}
}
Seems so much cleaner of a design to me and it is impossible to get an NPE.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 11:19 AM, "Paul Hammant" <Pa...@yahoo.com> wrote:
> Costin,
>
>>> What we need is a marker interface that indicates a tool wants a logger, and
>>> of course a method to give it the logger... I did a quick scan of the
>>> public API, and there doesn't seem to be one.
>>>
>>> So what I propose is to add an interface 'LogUser' or something like it (we
>>> can quibble about the name...)
>>>
>>> public interface LogUser
>>> {
>>> public void setCommonsLogger(Log log)
>>> }
>>>
>>
>> In other words, you also want a 'push' model for the logger. Curently each
>> component is supposed to 'pull' the logger.
>>
> Not wishing to be political, just to furnish you with info, the 'push'
> model is described as 'Inversion of Control' -->
>
> http://jakarta.apache.org/avalon/framework/inversion-of-control.html
>
I knew that's what the Avalon-ers call it, and that's where the idea came
from, but I didn't want to stir that up...
:)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The obvious solutions are challenging
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Paul Hammant wrote:
> Not wishing to be political, just to furnish you with info, the 'push'
> model is described as 'Inversion of Control' -->
>
> http://jakarta.apache.org/avalon/framework/inversion-of-control.html
It is also described as "JavaBeans", JMX, and few other names. There is no
"inversion of control" in the java beans or jmx specification - just an
object setting properties ( or managing ) another one in a 'straight'
direction.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Paul Hammant <Pa...@yahoo.com>.
Costin,
>>What we need is a marker interface that indicates a tool wants a logger, and
>>of course a method to give it the logger... I did a quick scan of the
>>public API, and there doesn't seem to be one.
>>
>>So what I propose is to add an interface 'LogUser' or something like it (we
>>can quibble about the name...)
>>
>> public interface LogUser
>> {
>> public void setCommonsLogger(Log log)
>> }
>>
>
>In other words, you also want a 'push' model for the logger. Curently each
>component is supposed to 'pull' the logger.
>
Not wishing to be political, just to furnish you with info, the 'push'
model is described as 'Inversion of Control' -->
http://jakarta.apache.org/avalon/framework/inversion-of-control.html
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 2:20 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
>
>>
>> The current model used in log4j, jdk1.4, etc is pull - you request a
>> logger by name. Same thing for jdbc connections, resources, etc.
>>
>
> In fact, there's an important philosophical issue about logging here as
> well -- who gets to choose the name of the logger (and therefore the log
> level)?
In this case, it's you, the container.
>
> The trend I've seen the most is that logger names are fine grained - often
> based on the fully qualified class name of the class that is doing the
> logging. This means that I can turn on debug logging on just my "foo"
> component, without having to turn on debugging info for all the components
> that are sharing the same Log instance. To say nothing of the fact that I
> can direct the log output from different components to different places
> ...
Using the *optional* LogUser interface, you can choose where things log to -
you pass the 'channel' to the component in the setCommonsLog() method that
you want it to use - so in debugging, you pass it the logger for debugging -
for production, you give it a less chatty one, or none at all.
>
> Bottom line is that I would be unlikely to create components that
> implemented LogUser or whatever, even if it did get added. It takes away
> too much fine-grained control for my taste. The pattern I like is similar
> to what Jon quoted:
>
> public class MyComponent {
>
> private static Log log = LogFactory.getLog(MyComponent.class);
>
> public void hello() {
> log.info("Hello!");
> }
>
> }
>
> which creates a logger based on the fully qualified class name.
>
But now you've lost control as the container, or as the container, you have
to do all the work in LogFactory.
The other way, you can create some set of loggers and pass them to the
components when you, the app/framework/servlet/woogie instantiate them...
I think it's a wash - and I can implement your pattern with mine, so it
isn't a wash - imagine the app is creating/loading components :
foreach( class to instantiate)
{
Object o = Class.forName(classname).newInstance();
if (o implements LogUser)
{
Log log = LogFactory.getLog(o.getClass());
((LogUser) o).setCommonsLog(log);
}
}
So there I get your pattern exactly - so I can localize my per-class logging
in LogFactory *or* also have local control in the component loading :
foreach( class to instantiate)
{
Object o = Class.forName(classname).newInstance();
if (o instanceof "o.a.c.l.LogUser")
{
// don't do it for class foo.bar as its too blabby
if(!(o instanceof "foo.bar"))
{
Log log = LogFactory.getLog(o.getClass());
((LogUser) o).setCommonsLog(log);
}
}
}
> Further, at least for Log4J and JDK 1.4 logging (and perhaps others) have
> nice inheritance rules about logging names, so that you could turn on
> debug level output for *all* Commons components that use this pattern by
> setting the level for "org.apache.commons" ...
I don't see how that's taken away - you still can do that...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Maven & Gump are friends
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 3:52 PM, "Michael A. Smith" <ma...@apache.org> wrote:
> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
>> Again - I have doubts about how this will work for apps with multiple
>> loggers, but the idea of supporting both push and pull is valid.
>
> One method of supporting multiple loggers is to specify a LogFactory
> rather than a log. The component can then call the specified factory to
> retrieve a log instance to its liking. And if the container wants the
> component to use one and only one logger, it can provide a LogFactory to
> the component that will always return the same Log instance.
>
> E.g.
>
> public interface LogUser {
> void setCommonsLogFactory(LogFactory factory);
> }
>
That works :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Michael A. Smith" <ma...@apache.org>.
On Wed, 3 Apr 2002 costinm@covalent.net wrote:
> Again - I have doubts about how this will work for apps with multiple
> loggers, but the idea of supporting both push and pull is valid.
One method of supporting multiple loggers is to specify a LogFactory
rather than a log. The component can then call the specified factory to
retrieve a log instance to its liking. And if the container wants the
component to use one and only one logger, it can provide a LogFactory to
the component that will always return the same Log instance.
E.g.
public interface LogUser {
void setCommonsLogFactory(LogFactory factory);
}
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
>
> I'm a little wary of adding an interface to commons-logging that _should
> never be used_ inside of any other Commons component. If that interface
> started popping up in our other components, that would be very bad, as it
> would then imply/require that component to be used inside of an IoC
> framework.
Or in a JMX environment. Or as a JavaBean.
The fact that IOC uses setters doesn't mean nobody else should.
Any component that want to allow a management application ( JMX for
example ) to change it's logger can implement this interface ( or at least
have a setter with this name that can be called with introspection ).
Again - I have doubts about how this will work for apps with multiple
loggers, but the idea of supporting both push and pull is valid.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 3:04 PM, "Morgan Delagrange" <md...@yahoo.com> wrote:
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Wednesday, April 03, 2002 1:41 PM
> Subject: Re: [logging] Need interface...
>
>
>> On 4/3/02 2:32 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>>
>>>> -----Original Message-----
>>>> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>>>
>>>>
>>>> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
>>>>
>>>>>
>>>>> The current model used in log4j, jdk1.4, etc is pull - you
>>>> request a
>>>>> logger by name. Same thing for jdbc connections, resources, etc.
>>>>>
>>>>
>>>> In fact, there's an important philosophical issue about
>>>> logging here as well -- who gets to choose the name of the
>>>> logger (and therefore the log level)?
>>>
>>> In IoC based apps, the container. period. That is what IoC
>>> is all about. The container (or manager) makes all the decisions
>>> about the component.
>>
>> And that's not what seems to be the philosophy of commons logging. The
>> component gets to choose, or that is how it appears.
>>
>> This is teaching me not to jump to conclusions :)
>>
>
> I'm a little wary of adding an interface to commons-logging that _should
> never be used_ inside of any other Commons component. If that interface
> started popping up in our other components, that would be very bad, as it
> would then imply/require that component to be used inside of an IoC
> framework.
First, I never said that it "_should never be used_ inside of any other
Commons component." I said it doesn't *have* to be used.
Are you sure that o.a.c.l isn't the first step towards yet another jakarta
framework?
As for IoC, what's the downside if a component *can* be used inside of an
IoC framework?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Uncertainty breeds confusion and confusion breeds despair. - Ceki Gulcu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, April 03, 2002 1:41 PM
Subject: Re: [logging] Need interface...
> On 4/3/02 2:32 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>
> >> -----Original Message-----
> >> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> >>
> >>
> >> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
> >>
> >>>
> >>> The current model used in log4j, jdk1.4, etc is pull - you
> >> request a
> >>> logger by name. Same thing for jdbc connections, resources, etc.
> >>>
> >>
> >> In fact, there's an important philosophical issue about
> >> logging here as well -- who gets to choose the name of the
> >> logger (and therefore the log level)?
> >
> > In IoC based apps, the container. period. That is what IoC
> > is all about. The container (or manager) makes all the decisions
> > about the component.
>
> And that's not what seems to be the philosophy of commons logging. The
> component gets to choose, or that is how it appears.
>
> This is teaching me not to jump to conclusions :)
>
I'm a little wary of adding an interface to commons-logging that _should
never be used_ inside of any other Commons component. If that interface
started popping up in our other components, that would be very bad, as it
would then imply/require that component to be used inside of an IoC
framework.
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>
> On 4/3/02 2:32 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>
> >> -----Original Message-----
> >> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> >>
> >>
> >> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
> >>
> >>>
> >>> The current model used in log4j, jdk1.4, etc is pull - you
> >> request a
> >>> logger by name. Same thing for jdbc connections, resources, etc.
> >>>
> >>
> >> In fact, there's an important philosophical issue about
> logging here
> >> as well -- who gets to choose the name of the logger (and
> therefore
> >> the log level)?
> >
> > In IoC based apps, the container. period. That is what IoC is all
> > about. The container (or manager) makes all the decisions
> about the
> > component.
>
> And that's not what seems to be the philosophy of commons
> logging. The component gets to choose, or that is how it appears.
>
> This is teaching me not to jump to conclusions :)
:) Yep. Different tools for different fools....
Seriously though, IoC is powerful when done correctly--but a PITA
if done hap-hazardly. Which is why many developers stick to the
static accessor approach.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 2:32 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>> -----Original Message-----
>> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>
>>
>> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
>>
>>>
>>> The current model used in log4j, jdk1.4, etc is pull - you
>> request a
>>> logger by name. Same thing for jdbc connections, resources, etc.
>>>
>>
>> In fact, there's an important philosophical issue about
>> logging here as well -- who gets to choose the name of the
>> logger (and therefore the log level)?
>
> In IoC based apps, the container. period. That is what IoC
> is all about. The container (or manager) makes all the decisions
> about the component.
And that's not what seems to be the philosophy of commons logging. The
component gets to choose, or that is how it appears.
This is teaching me not to jump to conclusions :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Somebody has to do something, and it's just incredibly pathetic that it has
to be us. - Jerry Garcia
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>
>
> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
>
> >
> > The current model used in log4j, jdk1.4, etc is pull - you
> request a
> > logger by name. Same thing for jdbc connections, resources, etc.
> >
>
> In fact, there's an important philosophical issue about
> logging here as well -- who gets to choose the name of the
> logger (and therefore the log level)?
In IoC based apps, the container. period. That is what IoC
is all about. The container (or manager) makes all the decisions
about the component.
> The trend I've seen the most is that logger names are fine
> grained - often based on the fully qualified class name of
> the class that is doing the logging. This means that I can
> turn on debug logging on just my "foo" component, without
> having to turn on debugging info for all the components that
> are sharing the same Log instance. To say nothing of the
> fact that I can direct the log output from different
> components to different places ...
FQCN based logging is not fine enough :)
> Bottom line is that I would be unlikely to create components
> that implemented LogUser or whatever, even if it did get
> added. It takes away too much fine-grained control for my
> taste. The pattern I like is similar to what Jon quoted:
>
> public class MyComponent {
>
> private static Log log = LogFactory.getLog(MyComponent.class);
>
> public void hello() {
> log.info("Hello!");
> }
>
> }
The container chooses the fine grained name. Avalon makes the
balance quite well. In fact, we can have loggers that are by
functional unit--even below the class/component level.
>
> which creates a logger based on the fully qualified class name.
>
> Further, at least for Log4J and JDK 1.4 logging (and perhaps
> others) have nice inheritance rules about logging names, so
> that you could turn on debug level output for *all* Commons
> components that use this pattern by setting the level for
> "org.apache.commons" ...
LogKit also has those.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 3 Apr 2002 costinm@covalent.net wrote:
>
> The current model used in log4j, jdk1.4, etc is pull - you request a
> logger by name. Same thing for jdbc connections, resources, etc.
>
In fact, there's an important philosophical issue about logging here as
well -- who gets to choose the name of the logger (and therefore the log
level)?
The trend I've seen the most is that logger names are fine grained - often
based on the fully qualified class name of the class that is doing the
logging. This means that I can turn on debug logging on just my "foo"
component, without having to turn on debugging info for all the components
that are sharing the same Log instance. To say nothing of the fact that I
can direct the log output from different components to different places
...
Bottom line is that I would be unlikely to create components that
implemented LogUser or whatever, even if it did get added. It takes away
too much fine-grained control for my taste. The pattern I like is similar
to what Jon quoted:
public class MyComponent {
private static Log log = LogFactory.getLog(MyComponent.class);
public void hello() {
log.info("Hello!");
}
}
which creates a logger based on the fully qualified class name.
Further, at least for Log4J and JDK 1.4 logging (and perhaps others) have
nice inheritance rules about logging names, so that you could turn on
debug level output for *all* Commons components that use this pattern by
setting the level for "org.apache.commons" ...
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 2:29 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>>
>> I want to try to explain this one more time because I think
>> my earlier explanation wasn't good :
>>
>> 1) I am interested in adding an interface to the o.a.c.l
>> package which looks like (modulo some naming concerns...) :
>>
>> public interface LogUser
>> {
>> void setCommonsLogger(Log log);
>> }
>
> Ok. Similar to Avalon's LogEnabled class with the enableLogging()
> method.
I can't say I saw Avalon's to do this, but this is clearly inspired by the
same pattern.
>
>
>> 2) This interface is not required to be implemented by
>> anyone, nor is it required to be looked for by anyone.
>
> In that case there is limited use for it. See below.
>
>
>> 3) Repeat - there are no requirements as to the use of this interface.
>
> I repeat, see below.
>
>> 4) The purpose is to let tools and components that want to
>> log have a 'marker' interface that they can implement that
>> says to the world, whatever world they are living in,
>> independent of race, creed, framework, container or application :
>>
>> "I want to log if I can. I know what a o.a.c.l.Log interface is and
>> can use it. At any time, you can give one to me if you want to
>> and know how. Otherwise, I'm ok."
>
> We are mixing metaphors, and I don't like it. The interface breeds
> confusion. You can't mix IoC based apps and static accessor based
> apps. There are reasons why.
>
> First off, you have to choose where you are using the component. If it
> is in an application like JMeter where everything is accessed
> statically,
> all your components should behave the same. If you are basing your
> application on something like Avalon where IoC rules, you should not
> have
> *any* static accessors of any sort.
>
> IoC is a tool used for Container/Component infrastructures, and is not
> appropriate in all situations.
Ok - with you so far.
>
> Components (in the formal sense) will always be tied to their container.
> The container provides everything to the component. everything. That
> means
> not just the logger. That means that the component is tied to the
> framework
> anyway.
I wasn't working in the formal sense, because the hope was to write
bean-like classes that can be used in more than one framework/app/etc.
>
> Commons, Sun, and several other people use the term component in an
> informal
> sense. A component has a *role* (or work interface) separate from the
> implementation. It is tied to a container, which manages it. Commons
> has
> a modular API, and each API group has been given the informal name of
> component,
> which confuses people who see commons' docs and avalon's docs.
Avalon has docs? ;->
>
> Lastly, trying to mix IoC and static access based systems is like trying
> to mix procedural and object oriented programming. It can be done, but
> it
> is messy, confusing, and not maintainable. Each model has its
> advantages
> and disadvantages, but you should decide which model your component
> operates in from the outset.
Yep - I didn't realize that the o.a.c.l forced the static accessor model for
getting the Logger.
If that is the case, then I think it's true I have no choice but to go back
and reinvent wheel and fire in Velocity-tools-land because while I am
willing to use the Commons logging interface to normalize things, I am not
willing, right now, to force people to use the commons logging framework.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Age and treachery will always triumph over youth and talent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
>
> On Wed, 3 Apr 2002, Berin Loritsch wrote:
>
> > Components (in the formal sense) will always be tied to their
> > container.
>
> I don't know what is the 'formal sense' you are talking about,
> but one of the goals of commons is to create components that
> are _not_
> tied to a container.
Again, Commons doesn't have 'formal' components. Formal components
include CORBA, EJB, Avalon, Servlets, etc.
> > The container provides everything to the component.
> everything. That
> > means not just the logger. That means that the component
> is tied to
> > the framework anyway.
>
> And people have a choice to not use this kind of container - the
> components we write will work in most containers, if a container have
> a problem with pull model ( Log.getLog() ) - too bad for it.
Then it's not a component.
> > Commons, Sun, and several other people use the term component in an
> > informal sense. A component has a *role* (or work
> interface) separate
> > from the implementation. It is tied to a container, which
> manages it.
> > Commons has a modular API, and each API group has been given the
> > informal name of component, which confuses people who see commons'
> > docs and avalon's docs.
>
> I certainly hope avalon doesn't have a trademark on
> 'component' or claims ownership or 'the Right Definition' of the term.
Who do you think I am? Of course not.
Now I have to dig up my definitions on the net..... :/
>
> > Lastly, trying to mix IoC and static access based systems is like
> > trying to mix procedural and object oriented programming.
> It can be
> > done, but it is messy, confusing, and not maintainable. Each model
> > has its advantages
>
> I don't know about IoC, but push and pull models are mixed in most
> programs and that's a good and desirable thing.
>
> If IoC doesn't 'mix', then it shouldn't be used.
IoC is used for container managed systems. If you have a hierarchical
container system, the parent container controls the direct child
containers
which in turn control their children.
The reason it *shouldn't* mix is because of security reasons. If a sub-
container's security were breached, the damage that can be done is
limited
to that smaller container. There are more reasons, but that is the most
important. Therefore it is usually relagated to server systems.
It forces you to think differently, and is a useful tool in that
respect.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Berin Loritsch wrote:
> Components (in the formal sense) will always be tied to their container.
I don't know what is the 'formal sense' you are talking about,
but one of the goals of commons is to create components that are _not_
tied to a container.
> The container provides everything to the component. everything. That means
> not just the logger. That means that the component is tied to the
> framework anyway.
And people have a choice to not use this kind of container - the
components we write will work in most containers, if a container have
a problem with pull model ( Log.getLog() ) - too bad for it.
> Commons, Sun, and several other people use the term component in an
> informal
> sense. A component has a *role* (or work interface) separate from the
> implementation. It is tied to a container, which manages it. Commons has
> a modular API, and each API group has been given the informal name of
> component, which confuses people who see commons' docs and avalon's docs.
I certainly hope avalon doesn't have a trademark on 'component' or
claims ownership or 'the Right Definition' of the term.
> Lastly, trying to mix IoC and static access based systems is like trying
> to mix procedural and object oriented programming. It can be done, but it
> is messy, confusing, and not maintainable. Each model has its advantages
I don't know about IoC, but push and pull models are mixed in most
programs and that's a good and desirable thing.
If IoC doesn't 'mix', then it shouldn't be used.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [logging] Need interface...
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>
> I want to try to explain this one more time because I think
> my earlier explanation wasn't good :
>
> 1) I am interested in adding an interface to the o.a.c.l
> package which looks like (modulo some naming concerns...) :
>
> public interface LogUser
> {
> void setCommonsLogger(Log log);
> }
Ok. Similar to Avalon's LogEnabled class with the enableLogging()
method.
> 2) This interface is not required to be implemented by
> anyone, nor is it required to be looked for by anyone.
In that case there is limited use for it. See below.
> 3) Repeat - there are no requirements as to the use of this interface.
I repeat, see below.
> 4) The purpose is to let tools and components that want to
> log have a 'marker' interface that they can implement that
> says to the world, whatever world they are living in,
> independent of race, creed, framework, container or application :
>
> "I want to log if I can. I know what a o.a.c.l.Log interface is and
> can use it. At any time, you can give one to me if you want to
> and know how. Otherwise, I'm ok."
We are mixing metaphors, and I don't like it. The interface breeds
confusion. You can't mix IoC based apps and static accessor based
apps. There are reasons why.
First off, you have to choose where you are using the component. If it
is in an application like JMeter where everything is accessed
statically,
all your components should behave the same. If you are basing your
application on something like Avalon where IoC rules, you should not
have
*any* static accessors of any sort.
IoC is a tool used for Container/Component infrastructures, and is not
appropriate in all situations.
Components (in the formal sense) will always be tied to their container.
The container provides everything to the component. everything. That
means
not just the logger. That means that the component is tied to the
framework
anyway.
Commons, Sun, and several other people use the term component in an
informal
sense. A component has a *role* (or work interface) separate from the
implementation. It is tied to a container, which manages it. Commons
has
a modular API, and each API group has been given the informal name of
component,
which confuses people who see commons' docs and avalon's docs.
Lastly, trying to mix IoC and static access based systems is like trying
to mix procedural and object oriented programming. It can be done, but
it
is messy, confusing, and not maintainable. Each model has its
advantages
and disadvantages, but you should decide which model your component
operates in from the outset.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I want to try to explain this one more time because I think my earlier
explanation wasn't good :
1) I am interested in adding an interface to the o.a.c.l package which looks
like (modulo some naming concerns...) :
public interface LogUser
{
void setCommonsLogger(Log log);
}
2) This interface is not required to be implemented by anyone, nor is it
required to be looked for by anyone.
3) Repeat - there are no requirements as to the use of this interface.
4) The purpose is to let tools and components that want to log have a
'marker' interface that they can implement that says to the world, whatever
world they are living in, independent of race, creed, framework, container
or application :
"I want to log if I can. I know what a o.a.c.l.Log interface is and
can use it. At any time, you can give one to me if you want to
and know how. Otherwise, I'm ok."
That's it. There are no implications other than that.
Is that better?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> > In other words, you also want a 'push' model for the logger. Curently each
> > component is supposed to 'pull' the logger.
>
> Pull? From where?
Log log=LogFactory.getLog( MyObject.class )
( or by string ).
The current model used in log4j, jdk1.4, etc is pull - you request a
logger by name. Same thing for jdbc connections, resources, etc.
> What's Log.getLog() ?
>
> I am looking at o.a.c.l.Log and there is no getLog() method...
LogFactory.getLog(). It used to be a shortcut in Log too - my memory is
overloaded at the moment.
> > +1 on the idea - but maybe we can discuss a bit the details. LogUser
> > and setCommonLogger sounds a bit weird, and I'm not sure I understand who
> > will call the method.
>
> Here's the idea - we want to have a marker interface that a component (or
> tool, in our parlance) can implement such that any framework, container,
> code, app, thingy, servlet, (you get the idea) that supports commons logging
> can look for and invoke, handing the Log interface to the component to use.
>
> If the container, framework, code... doesn't support that, so be it. No
> worries... The component or tool won't log.
Just for the record, I think the default if no logger is explicitely set
is to get a logger using the normal pattern.
> Ok. This wouldn't change the Log interface - it would be an additional
> interface that is in fact optional - if a component/tool doesn't implement
> it, fine. If a framework/servlet/app/etc doesn't look for it, fine...
It'll still be part of the exposed interface of commons-logger, which we
try to keep minimal.
I'm +1 - except my comment in naming ( but I have no better names, so
can't complain ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 10:55 AM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>
>> What we need is a marker interface that indicates a tool wants a logger, and
>> of course a method to give it the logger... I did a quick scan of the
>> public API, and there doesn't seem to be one.
>>
>> So what I propose is to add an interface 'LogUser' or something like it (we
>> can quibble about the name...)
>>
>> public interface LogUser
>> {
>> public void setCommonsLogger(Log log)
>> }
>
> In other words, you also want a 'push' model for the logger. Curently each
> component is supposed to 'pull' the logger.
Pull? From where?
>
> Well, I can't say no. I prefer the current Log.getLog() pattern, but
> the whole point of commons is to be open and accept multiple points
> of view, instead of forcing everyone to use a 'right' thing.
That's "Right Thing". Get it right :)
What's Log.getLog() ?
I am looking at o.a.c.l.Log and there is no getLog() method...
>
> +1 on the idea - but maybe we can discuss a bit the details. LogUser
> and setCommonLogger sounds a bit weird, and I'm not sure I understand who
> will call the method.
Here's the idea - we want to have a marker interface that a component (or
tool, in our parlance) can implement such that any framework, container,
code, app, thingy, servlet, (you get the idea) that supports commons logging
can look for and invoke, handing the Log interface to the component to use.
If the container, framework, code... doesn't support that, so be it. No
worries... The component or tool won't log.
>
> In JMX terms, you would have a method setLogger( o.a.commons.logger.Log )
> or setLoggerName( String ) and based on some config JMX will set the
> logger. The Log???? interface will be extended by the component
> MBean interface ( if any ). Seems a valid use case, and a good idea to
> 'standardise' the pattern used to set the logger in a component.
Right - I used the methodname 'setCommonsLogger()' because 'setLogger()' is
just so generic, I didn't want to cause undue conflict with other methods a
Class would have to implement.
>
> Maybe even a set logLevel() to tune the ammount of output the component
> generates - i.e. a second filter pattern. I wouldn't say no, since the
> pattern is in wide use in tomcat(3 at least, and other projects as well )
> and quite usefull.
Ok - I'm game, as long as I can ignore it :)
>
>
>> As I personally believe that just being a commons committer doesn't give me
>> the 'spirit-of-the-law' right to commit to the logger, I'll ask for some
>> even vague hint of approval from the logger people before moving forward.
>
> Good idea, given the amount of debate we had for each API change in
> commons-logger. I would do the same.
>
> However feel free to commit anything in the impl :-).
Ok. This wouldn't change the Log interface - it would be an additional
interface that is in fact optional - if a component/tool doesn't implement
it, fine. If a framework/servlet/app/etc doesn't look for it, fine...
Kinda harmless. Just want to get it right...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"The greatest pleasure in life is doing what people say you cannot do."
- Walter Bagehot
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> What we need is a marker interface that indicates a tool wants a logger, and
> of course a method to give it the logger... I did a quick scan of the
> public API, and there doesn't seem to be one.
>
> So what I propose is to add an interface 'LogUser' or something like it (we
> can quibble about the name...)
>
> public interface LogUser
> {
> public void setCommonsLogger(Log log)
> }
In other words, you also want a 'push' model for the logger. Curently each
component is supposed to 'pull' the logger.
Well, I can't say no. I prefer the current Log.getLog() pattern, but
the whole point of commons is to be open and accept multiple points
of view, instead of forcing everyone to use a 'right' thing.
+1 on the idea - but maybe we can discuss a bit the details. LogUser
and setCommonLogger sounds a bit weird, and I'm not sure I understand who
will call the method.
In JMX terms, you would have a method setLogger( o.a.commons.logger.Log )
or setLoggerName( String ) and based on some config JMX will set the
logger. The Log???? interface will be extended by the component
MBean interface ( if any ). Seems a valid use case, and a good idea to
'standardise' the pattern used to set the logger in a component.
Maybe even a set logLevel() to tune the ammount of output the component
generates - i.e. a second filter pattern. I wouldn't say no, since the
pattern is in wide use in tomcat(3 at least, and other projects as well )
and quite usefull.
> As I personally believe that just being a commons committer doesn't give me
> the 'spirit-of-the-law' right to commit to the logger, I'll ask for some
> even vague hint of approval from the logger people before moving forward.
Good idea, given the amount of debate we had for each API change in
commons-logger. I would do the same.
However feel free to commit anything in the impl :-).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by co...@covalent.net.
On Wed, 3 Apr 2002, Craig R. McClanahan wrote:
> > public interface LogUser
> > {
> > public void setCommonsLogger(Log log)
> > }
> >
>
> I can see why some people might like to have a log setter method like this
> (rather than letting the log-using component define its own log name).
> What I don't see (yet?) is the value of having this interface defined in
> commons-logging itself. Isn't the decision to need/use this made on a
> component by component basis anyway? Don't the cooperating components
> have to know about it in order to call this method, whether its an
> o.a.c.l.LogUser interface or just a public property setter?
I think the value here is to establish a pattern ( i.e. a method name )
that can be used consistently in all components that decide to make the
log configurable.
With JMX you'll not have to implement the interface, but if the pattern is
used you'll know that all components can be managed in a consistent way.
( of course, setting the logger name would be easier to use in some cases)
It'll also reduce the coupling between components and frameworks - with it
the component will depend only on commons-logging, and not on a
framework-defined interface.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/3/02 11:59 AM, "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>
>> Date: Wed, 03 Apr 2002 08:46:07 -0500
>> From: Geir Magnusson Jr. <ge...@optonline.net>
>> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>> Subject: [logging] Need interface...
>>
>> So what I propose is to add an interface 'LogUser' or something like it (we
>> can quibble about the name...)
>>
>> public interface LogUser
>> {
>> public void setCommonsLogger(Log log)
>> }
>>
>
> I can see why some people might like to have a log setter method like this
> (rather than letting the log-using component define its own log name).
> What I don't see (yet?) is the value of having this interface defined in
> commons-logging itself. Isn't the decision to need/use this made on a
> component by component basis anyway? Don't the cooperating components
> have to know about it in order to call this method, whether its an
> o.a.c.l.LogUser interface or just a public property setter?
I know I am explaining this badly... Let me take another wack.
The idea is that in some kind of app/framework/servlet (from now on :=
'app'), the app might setup aggregated logging for all of the components to
use, and it would be nice if there was a standard indicator for
components/tools to use to indicate compatibility.
As components are added dynamically, the app sees if they implement the
*standard* interface o.a.c.l.LogUser, which flags to the app that the
component can log to a o.a.c.l.Log interface. The app then invokes the
setCommonsLogger() method on the component with a Log-implementing object,
and then the component can log happily ever after.
If that doesn't make it clear, let me illustrate with a use case.
Imagine a system, like a webapp, where you can define a set of tools (java
class names) that the servlet will instantiate and make available to the
view layer to use when templating. For each tool that it reads from the set
(say a config file with class names...), it can check to see if that class
implements the LogUser interface, indicating that it wants to and can log
using o.a.c.l.Log. So the servlet then just passes in something shaped like
a Log.
Our hope, in our Velocity tools project, is that we don't have to reinvent
the wheel - if we support o.a.c.l.Log as the interface to the tools that log
(wrapping around whatever - the servlet logger, the Velocity logger, it
doesn't matter) - and we invent and promote a standard way to indicate
desire and compatibility that comes from o.a.c.l we don¹t have to invent a
new, Velocity-tool-specific way to indicate loggyness to the
servlet/toolmanager..
Clearer?
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Need interface...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
> Date: Wed, 03 Apr 2002 08:46:07 -0500
> From: Geir Magnusson Jr. <ge...@optonline.net>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [logging] Need interface...
>
> So what I propose is to add an interface 'LogUser' or something like it (we
> can quibble about the name...)
>
> public interface LogUser
> {
> public void setCommonsLogger(Log log)
> }
>
I can see why some people might like to have a log setter method like this
(rather than letting the log-using component define its own log name).
What I don't see (yet?) is the value of having this interface defined in
commons-logging itself. Isn't the decision to need/use this made on a
component by component basis anyway? Don't the cooperating components
have to know about it in order to call this method, whether its an
o.a.c.l.LogUser interface or just a public property setter?
> Geir Magnusson Jr. geirm@optonline.net
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>