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/06 00:36:42 UTC
[logging] LogFactory tangent : was Re: [logging] Need interface...
VOTE
On 4/5/02 4:48 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
>> I don't know if that's fair - because the application has setup and pushed
>> into the context the Log..
>>
>> In the o.a.c.l model, I can't even replace the static LogFactory....
>
> Replace it with what ? The javadoc for the static LogFactory.getLog()
> is pretty clear, the method must implement what's in the doc.
>
My own implementation? (You know, that choice thing?)
Before I summarize my understanding :
I am not advocating removing the pull model.
Ok. Here's my understanding of the LogFactory issue - please correct me
where it's wrong :
1) if the Log, LogFactory interfaces are kept in the same jar the
.impl.LogFactory, then "there are challenges" to clearly implement an
alternative LogFactory because of the issues surrounding the discovery
method.
2) If Log and LogFactory interfaces were separated from the .impl that is in
commons now, into two separate packages,
o.a.c.l -> commons-logging.jar (contains the interfaces)
o.a.c.li -> commons-loggingimpl.jar (contains the impl)
then
a) Nothing would change for users, developers, existing components, future
components as all code would still work. The only requirement is that the
two commons-logging jars would have to be added to the classpath. Not a big
deal.
b) Alternative LogFactory implementations are easy to deploy as it just
means dropping the lightweight interface jar into the classpath, and the
alternative factory impl jar.
c) o.a.c.l becomes a truly generic logging interface (which is how many
people interpret it) that can be implemented by anyone, supporting any pull
model you choose, and any push model you choose...
Is the above correct?
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] LogFactory tangent : was Re: [logging] Need
interface... VOTE
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/5/02 6:37 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> So the LogFactory itself isn't really generic, as it presumes the helper?
> And everyone who writes to this does
>
> import o.a.c.l.LogFactory;
>
> ...
>
> Log logger = LogFactory.getLogger();
>
>
> Ok - so there's no point in continuing. It seems like the only way to offer
> a generic set of interfaces for logging is to do a different package...
>
Wouldn't a better pattern be the discovery pattern in the services docs :
import o.a.c.l.LogFactory;
public class MyFoo {
Log logger = null;
static {
Iterator i = Service.providers(LogFactory.class);
while (i.hasNext())
{
LogFactory lf = (LogFactory) i.next();
logger = lf.getLogger(....);
}
}
public void foo()
{
logger.log("hi from foo");
}
}
Question - could o.a.c.l.LogFactory be an interface in this case? I am
guessing yes, but not sure...
So in this case, the pull discovery is maintained ("Not taken away...") yet
implementation freedom is restored...
--
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] LogFactory tangent : was Re: [logging] Need
interface... VOTE
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/5/02 6:37 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> And everyone who writes to this does
>
> import o.a.c.l.LogFactory;
>
> ...
>
> Log logger = LogFactory.getLogger();
>
>
> Ok - so there's no point in continuing. It seems like the only way to offer
> a generic set of interfaces for logging is to do a different package...
Is it possible to make LogFactory.getFactory() abstract as well and push the
impl to o.a.c.l.i?
--
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] LogFactory tangent : was Re: [logging] Need
interface... VOTE
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/5/02 5:59 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
>
>> 2) If Log and LogFactory interfaces were separated from the .impl that is in
>> commons now, into two separate packages,
>>
>> o.a.c.l -> commons-logging.jar (contains the interfaces)
>>
>> o.a.c.li -> commons-loggingimpl.jar (contains the impl)
>>
>> then
>>
>>
>> b) Alternative LogFactory implementations are easy to deploy as it just
>> means dropping the lightweight interface jar into the classpath, and the
>> alternative factory impl jar.
>
> It doesn't matter where the LogFactory sits - if we define the helper
> ( org.apache.foo.LogFactory ) and it uses a static method it can't be
> reimplemented.
I see now - because the discovery functionality (the static method) and the
interface you are trying to discover (LogFactory) are combined, via
o.a.c.LogFactory being an abstract class with the static method, rather than
an interface, we're screwed if you want to replace LogFactory.
Is that it? That's why I would have to remove o.a.c.LogFactory from the jar
and replace with my own?
So the LogFactory itself isn't really generic, as it presumes the helper?
And everyone who writes to this does
import o.a.c.l.LogFactory;
...
Log logger = LogFactory.getLogger();
Ok - so there's no point in continuing. It seems like the only way to offer
a generic set of interfaces for logging is to do a different package...
Otherwise, the the basic interfaces (Log, LogFactory) can't be implemented
freely?
Hm....
--
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] LogFactory tangent : was Re: [logging] Need interface...
VOTE
Posted by co...@covalent.net.
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> > Replace it with what ? The javadoc for the static LogFactory.getLog()
> > is pretty clear, the method must implement what's in the doc.
> >
>
> My own implementation? (You know, that choice thing?)
So you're saying an API can never use static methods ?
It's just a simple tradeoff between convenience and flexibility.
If we don't have the static method the user will have to write more
code.
Even if you would be able to replace it, the replacement is required
to implement exactly the same thing anyway.
> 1) if the Log, LogFactory interfaces are kept in the same jar the
> .impl.LogFactory, then "there are challenges" to clearly implement an
> alternative LogFactory because of the issues surrounding the discovery
> method.
No. The discovery method works the way it is supposed to - i.e. it _helps_
you if you have a single logger implementation and prefer to be helped.
If you have more then one or you don't like the discovery - just use
whatever else you want, the static method in LogFactory is just supposed
to make 'simple things easy'.
> 2) If Log and LogFactory interfaces were separated from the .impl that is in
> commons now, into two separate packages,
>
> o.a.c.l -> commons-logging.jar (contains the interfaces)
>
> o.a.c.li -> commons-loggingimpl.jar (contains the impl)
>
> then
>
>
> b) Alternative LogFactory implementations are easy to deploy as it just
> means dropping the lightweight interface jar into the classpath, and the
> alternative factory impl jar.
It doesn't matter where the LogFactory sits - if we define the helper
( org.apache.foo.LogFactory ) and it uses a static method it can't be
reimplemented.
If you sugest replacing the actual class - you can do it today by
replacing the class in the current jar.
> c) o.a.c.l becomes a truly generic logging interface (which is how many
> people interpret it) that can be implemented by anyone, supporting any pull
> model you choose, and any push model you choose...
o.a.c.l is a 'generic logging interface' already - it is not a 'generic
discovery interface'. The pull/push/Class.forName()/static methods
are all choices on how to register and get a logger - including the
infamous static method you don't like. It's a choice that work
if you have a single logger and you use the standard mechanism, same
as JAXP.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>