On Tue, 2005-06-21 at 21:57 -0700, Brian Stansberry wrote:
> > > Since log4j is on the classpath, they'd have to do
> > use
> > > commons-logging.properties anyway.
> >
> > Well, I have a patch to propose which will change
> > that :-)
> >
>
> Related to the comment you just added to
> LogFactor
--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-06-20 at 22:46 -0700, Brian Stansberry
> wrote:
>
> > > Of course because the error is now suppressed,
> > > people won't get any hint
> > > that the logging output is getting diverted to
> an
> > > unexpected destination
> > > - unles
On Mon, 2005-06-20 at 22:46 -0700, Brian Stansberry wrote:
> Maybe a little bit good? ;-) With the latest JCL I
> was able to remove the JBoss filter of JCL and get
> logkit logging working for both webapp classes and
> Tomcat's JSPServlet by following the standard steps --
> commons-logging.prop
--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi Brian,
>
> On Sun, 2005-06-19 at 16:22 -0700, Brian Stansberry
> wrote:
> > Had a chance to check this out, and the problem is
> > because JBoss/Tomcat uses commons-logging.jar
> instead
> > of the commons-logging-api.jar used by standalone
> > T
Hi Brian,
On Sun, 2005-06-19 at 16:22 -0700, Brian Stansberry wrote:
> Had a chance to check this out, and the problem is
> because JBoss/Tomcat uses commons-logging.jar instead
> of the commons-logging-api.jar used by standalone
> Tomcat. When a webapp is deployed JBoss also deploys
> container
--- Brian Stansberry <[EMAIL PROTECTED]>
wrote:
> --- robert burrell donkin
> <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-05-05 at 23:12 +1200, Simon Kitching
> > wrote:
> > > On Wed, 2005-05-04 at 23:37 -0700, Brian
> > Stansberry wrote:
> >
> >
> >
> > > > 2) When checking into the above, I d