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: 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