Commons logging issues

[Ryan Hoegg <rh...@isisnetworks.net>]

Andrew, Daniel, pay attention:

Craig R. McClanahan wrote:

>On Fri, 7 Feb 2003, Ryan Hoegg wrote:
>  
>
>>Starting a new thread for this, it really has little to do with CLI.
>>
>>We are having a similar dilemma in XML-RPC.  The idea of a
>>SafeCommonsLogger seems sound.  It could even end up in a commons-stub
>>package.  It would do nothing if commons-logging-api.jar or
>>commons-logging.jar is not in the CLASSPATH.
>>
>
>Instead of trying to convert every commons-logging user in the world to
>switch to using SafeCommonsLogger as a wrapper around commons-logging
>(which is itself a wrapper around ... nah, let's not go there at the
>moment :-), I have an alternative suggestion.
>
>Why not just provide a trivially simple two-class JAR file that defines
>org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory
>with exactly the same public APIs as the "real" ones?  Then, just ship
>this tiny little JAR file with apps (or applets) that don't want to use
>commons-logging.  The resulting JAR file is going to be pretty much the
>same size as something containing SafeCommonsLogger anyway.
>
>As long as your replacement classes maintain binary compatibility with the
>standard ones, any code that currently thinks it is using commons-logging
>will be transparently using your own version instead.
>
What do you think of this scenario?

Re: Logging, packaging and applets

[Daniel Rall <dl...@finemaltcoding.com>]

Ryan Hoegg <rh...@isisnetworks.net> writes:

> Andrew Evers wrote:
> 
> >Hmm, thread revival. Had to go back to the archives to check out what I had
> >said. This proposal looks like a solution.
> >
> >Log itself is an interface, LogFactory is a class. The tiniest possible
> >implementation
> >we could build would be to have our own LogFactory that copies the real
> >LogFactory public API and implements Log itself and does very little. This
> >could be pretty small, and provide the required functionality. The
> >problem then becomes keeping current with the LogFactory public API,
> >since we need to keep binary compatibility.
> >
> >I'd prefer having a createLog() method in its own interface, which then
> >either creates a BasicLog (logs everything to stderr, dependent on setting of
> >XmlRpc.debug) or calls an instance of XmlRpcLog to create the Log instance
> >(via commons logging by default). I just built a trial implementation, it's
> >about 4k/2k including the Log interface from commons logging.
>
> Sounds great in english!  I'd actually like to start using log4j with
> my xmlrpc code, so when you get it commitable, I'd love to play with
> it.

Ditto, I'm really looking forward to having real logging.
-- 

Daniel Rall

Re: Logging, packaging and applets

[Ryan Hoegg <rh...@isisnetworks.net>]

Andrew Evers wrote:

>Hmm, thread revival. Had to go back to the archives to check out what I had
>said. This proposal looks like a solution.
>
>Log itself is an interface, LogFactory is a class. The tiniest possible
>implementation
>we could build would be to have our own LogFactory that copies the real
>LogFactory public API and implements Log itself and does very little. This
>could be pretty small, and provide the required functionality. The
>problem then becomes keeping current with the LogFactory public API,
>since we need to keep binary compatibility.
>
>I'd prefer having a createLog() method in its own interface, which then
>either creates a BasicLog (logs everything to stderr, dependent on setting of
>XmlRpc.debug) or calls an instance of XmlRpcLog to create the Log instance
>(via commons logging by default). I just built a trial implementation, it's
>about 4k/2k including the Log interface from commons logging.
>
Sounds great in english!  I'd actually like to start using log4j with my 
xmlrpc code, so when you get it commitable, I'd love to play with it.

>As a separate issue, I just looked at how the applet stuff works, and it is
>only dependent on the Base64 class from the main package. Although this
>doesn't seem to be included in applet jar ;). Everything else it repeats
>in SimpleXmlRpcClient. There is a comment to the effect that this should
>really all be done with the core classes. Current classes are 16k/8k
>(20k/10k including Base64).
>
>Including the core proper into the applet would make it much bigger, but
>moving SimpleXmlRpcClient up a level and leveraging the code in XmlRpc
>would result in a small increase in the size of the applet code delivered
>(I think that it will actually be a decrease, since the secure/ directory is
>currently packaged), but have the advantage of being simpler to maintain.
>
>Andrew.
>
I think I may have put that comment there.  Check bug 16383.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16383

Logging, packaging and applets

[Andrew Evers <an...@redwood.com>]

> > > Craig R. McClanahan wrote:
> > > >Why not just provide a trivially simple two-class JAR file that
defines
> > > >org.apache.commons.logging.Log and
org.apache.commons.logging.LogFactory
> > > >with exactly the same public APIs as the "real" ones?  Then, just
ship
> > > >this tiny little JAR file with apps (or applets) that don't want to
use
> > > >commons-logging.  The resulting JAR file is going to be pretty much
the
> > > >same size as something containing SafeCommonsLogger anyway.

Hmm, thread revival. Had to go back to the archives to check out what I had
said. This proposal looks like a solution.

Log itself is an interface, LogFactory is a class. The tiniest possible
implementation
we could build would be to have our own LogFactory that copies the real
LogFactory public API and implements Log itself and does very little. This
could be pretty small, and provide the required functionality. The
problem then becomes keeping current with the LogFactory public API,
since we need to keep binary compatibility.

I'd prefer having a createLog() method in its own interface, which then
either
creates a BasicLog (logs everything to stderr, dependent on setting of
XmlRpc.debug) or calls an instance of XmlRpcLog to create the Log instance
(via commons logging by default). I just built a trial implementation, it's
about
4k/2k including the Log interface from commons logging.

As a separate issue, I just looked at how the applet stuff works, and it is
only dependent on the Base64 class from the main package. Although this
doesn't seem to be included in applet jar ;). Everything else it repeats
in SimpleXmlRpcClient. There is a comment to the effect that this should
really all be done with the core classes. Current classes are 16k/8k
(20k/10k
including Base64).

Including the core proper into the applet would make it much bigger, but
moving SimpleXmlRpcClient up a level and leveraging the code in XmlRpc
would result in a small increase in the size of the applet code delivered
(I think that it will actually be a decrease, since the secure/ directory is
currently packaged), but have the advantage of being simpler to maintain.

Andrew.

Re: Commons logging issues

[Daniel Rall <dl...@finemaltcoding.com>]

"Andrew Evers" <an...@redwood.com> writes:

> > Andrew, Daniel, pay attention:
> >
> > Craig R. McClanahan wrote:
> > >Why not just provide a trivially simple two-class JAR file that defines
> > >org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory
> > >with exactly the same public APIs as the "real" ones?  Then, just ship
> > >this tiny little JAR file with apps (or applets) that don't want to use
> > >commons-logging.  The resulting JAR file is going to be pretty much the
> > >same size as something containing SafeCommonsLogger anyway.
> > >
> > >As long as your replacement classes maintain binary compatibility
> > >with > the standard ones, any code that currently thinks it is
> > >using commons-logging will be transparently using your own
> > >version instead.
> > >
> > What do you think of this scenario?
> 
> This sounds fine. We would always need a dependency on the Log
> interface (and probably LogFactory) at compile and runtime. This
> solution means we don't need a runtime dependency on a large JAR
> file, we can simply package these two classes in with the applet
> JAR.

Yeah, that sounds just dandy.  Sorry for the late reply, and thanks
for taking care of this.
-- 

Daniel Rall

Re: Commons logging issues

[Andrew Evers <an...@redwood.com>]

> Andrew, Daniel, pay attention:
>
> Craig R. McClanahan wrote:
> >Why not just provide a trivially simple two-class JAR file that defines
> >org.apache.commons.logging.Log and org.apache.commons.logging.LogFactory
> >with exactly the same public APIs as the "real" ones?  Then, just ship
> >this tiny little JAR file with apps (or applets) that don't want to use
> >commons-logging.  The resulting JAR file is going to be pretty much the
> >same size as something containing SafeCommonsLogger anyway.
> >
> >As long as your replacement classes maintain binary compatibility with
the
> >standard ones, any code that currently thinks it is using commons-logging
> >will be transparently using your own version instead.
> >
> What do you think of this scenario?

This sounds fine. We would always need a dependency on the Log interface
(and
probably LogFactory) at compile and runtime. This solution means we don't
need
a runtime dependency on a large JAR file, we can simply package these two
classes
in with the applet JAR.

Andrew.