You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Brian Stansberry <be...@yahoo.com> on 2005/04/25 23:00:58 UTC
Re: [logging] possible errors in child first cases [WAS Re: [logging] issues highlighted by analysis]
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> On Sun, 2005-04-24 at 23:59 -0700, Brian Stansberry
> wrote:
> > --- robert burrell donkin
>
> <snip>
>
> > When I ran these, for every child-first case the
> > sysout output said the caller was defined by the
> child
> > loader.
> >
> > [java] Caller defined by CHILD class
> loader
> >
> > For 18, 20, 26, 28, 30 and 32, the overview says
> > caller should be loaded by the parent. Haven't
> had a
> > chance to try to see why, but this could be the
> cause
> > of some problems.
>
> that's interesting.
>
> i've rerun the tests on my machine and all those
> tests seem to have the
> caller defined correctly. (i don't seem to have
> anything which isn't
> check in.) i'm running Java HotSpot(TM) Client VM
> (build 1.4.2_04-b05,
> mixed mode) on linux at the moment.
>
> anyone else experiencing these problems?
Please note that the results I reported came when I
ran the tests using the patched version of
LogFactoryImpl I discussed. Don't know if that would
matter or not. I can try again tonight using the
normal JCL. Or it could be some other screwup on my
part.
Brian
>
> - robert
>
> [java] Running case 18...
> [java] Child context classloader: false
> [java] Child first: true
> [java] JCL defined by CHILD class
> loader
> [java] Log4j defined by CHILD class
> loader
> [java] Static Logger defined by CHILD class
> loader
> [java] Caller defined by PARENT class
> loader
>
> [java] Running case 20...
> [java] Child context classloader: true
> [java] Child first: true
> [java] JCL defined by CHILD class
> loader
> [java] Log4j defined by CHILD class
> loader
> [java] Static Logger defined by CHILD class
> loader
> [java] Caller defined by PARENT class
> loader
>
> [java] Running case 26...
> [java] Child context classloader: false
> [java] Child first: true
> [java] JCL defined by CHILD class
> loader
> [java] Log4j defined by CHILD class
> loader
> [java] Static Logger defined by CHILD class
> loader
> [java] Caller defined by PARENT class
> loader
>
> [java] Running case 28...
> [java] Child context classloader: true
> [java] Child first: true
> [java] JCL defined by CHILD class
> loader
> [java] Log4j defined by CHILD class
> loader
> [java] Static Logger defined by CHILD class
> loader
> [java] Caller defined by PARENT class
> loader
>
> [java] Running case 30...
> [java] Child context classloader: false
> [java] Child first: true
> [java] JCL defined by CHILD class
> loader
> [java] Log4j defined by CHILD class
> loader
> [java] Static Logger defined by CHILD class
> loader
> [java] Caller defined by PARENT class
> loader
>
> [java] Running case 32...
> [java] Child context classloader: true
> [java] Child first: true
> [java] JCL defined by CHILD class
> loader
> [java] Log4j defined by CHILD class
> loader
> [java] Static Logger defined by CHILD class
> loader
> [java] Caller defined by PARENT class
> loader
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] possible errors in child first cases
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2005-04-25 at 23:01 -0700, Brian Stansberry wrote:
> Sorry to waste your time; false alarm. The child-first
> cases are fine. Somehow my commons-logging.jar had
> everything but the kitchen sink in it, including the
> demonstration code.
>
> Good news is with that problem fixed and a refactored
> LogFactoryImpl, JCL worked as expected in all cases.
great :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] possible errors in child first cases
Posted by Brian Stansberry <be...@yahoo.com>.
Sorry to waste your time; false alarm. The child-first
cases are fine. Somehow my commons-logging.jar had
everything but the kitchen sink in it, including the
demonstration code.
Good news is with that problem fixed and a refactored
LogFactoryImpl, JCL worked as expected in all cases.
Brian
--- Brian Stansberry <be...@yahoo.com>
wrote:
>
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
>
> > On Sun, 2005-04-24 at 23:59 -0700, Brian
> Stansberry
> > wrote:
> > > --- robert burrell donkin
> >
> > <snip>
> >
> > > When I ran these, for every child-first case the
> > > sysout output said the caller was defined by the
> > child
> > > loader.
> > >
> > > [java] Caller defined by CHILD class
> > loader
> > >
> > > For 18, 20, 26, 28, 30 and 32, the overview says
> > > caller should be loaded by the parent. Haven't
> > had a
> > > chance to try to see why, but this could be the
> > cause
> > > of some problems.
> >
> > that's interesting.
> >
> > i've rerun the tests on my machine and all those
> > tests seem to have the
> > caller defined correctly. (i don't seem to have
> > anything which isn't
> > check in.) i'm running Java HotSpot(TM) Client VM
> > (build 1.4.2_04-b05,
> > mixed mode) on linux at the moment.
> >
> > anyone else experiencing these problems?
>
> Please note that the results I reported came when I
> ran the tests using the patched version of
> LogFactoryImpl I discussed. Don't know if that
> would
> matter or not. I can try again tonight using the
> normal JCL. Or it could be some other screwup on my
> part.
>
> Brian
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org