James Strachan wrote:
>
> ----- Original Message -----
> From: "Earl Hood" <[EMAIL PROTECTED]>
> > In the work I have done, the solution to this problem is to merge
> > the necessary jar files together to avoid the dependency on CLASSPATH.
> > The merging is not ideal for some applications, like applets, but
> > works well for server-side, or stand-alone, applications. It makes
> > distribution and installation easier.
> >
> > To do the merging, I wrote some classes that do the merging processing
> > (using jar to do the work is inefficent and awkward). It attempts to
> > preserve manifest information and supports selective inclusion and
> > exclusion of classes; this allows one to merge only what is needed.
> > If there is interest, I can make the source available.
>
> Sounds like a possible inclusion in the ant tasks sandbox area?
>
> > Wrt log4j, you could include the log4j jar file with Cactus and then
> > merge it into the jar file (or files(?), I am not familiar with Cactus)
> > during the build so all necessary log4j classes are available. For a
> > project I am working on where I work, this is what I do. I also
> > include a default log4j.properties in our base library so log4j does
> > not complain if the application does not provide one.
>
> Agreed. Maybe we all need is just a micro log4j distribution that contains
> the bare minimum (handful?) of classes (the facade & a couple of
> implementation classes) to get some real basic logging by default for
> projects that feel they need it. Then users could always swap in the full
> log4j if they want more control & flexibility.
>
Ceki? You listening? :)
James - want to run this idea on the log4j list? It sounds very
useful...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
