On 4/5/02 4:48 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED]
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
