Thanks, that makes sense. Then one replaces the static Category factories
(getRoot, getInstance) with calls to the corresponding methods of the custom
Hierarchy. At least, that's what I did, and it's working with my original
xml configuration file. I don't have a dummy "other" application using
log4j handy to my verify isolation in the JVM, but I'm there, right?
> -----Original Message-----
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 11:02 AM
> To: LOG4J Users Mailing List
> Subject: Re: non-default hierarchy in shared JVM
>
>
>
> Clay,
>
> Multiple hierarchy management is one of the most advanced
> log4j topics and was only recently introduced.
>
> The answer to you question is seemingly easy.
>
> To create a new hierarchy do:
>
> Hierarchy h = new Hierarchy(new RootCategory(Priority.WHATEVER));
>
> the constructor for the org.apache.log4j.spi.RootCategory is public.
>
> RootCategory extends Category and surprisingly not the other
> way around. The rationale behind this is that the
> RootCategory is a just a category that provides a few
> guarantees: like always having a set priority and not having
> any parents, other than that, it is a Category like any
> other. To preserve those safeguards at all costs, the
> RootCategory class is final and cannot be extended.
>
> I could have done it the other way around: Category extending
> RootCategory. That would have no tangible benefits but force
> RootCategory to be non-final.
>
> The Hierarchy constructor requires a Category object and not
> a RootCategory. This initially confuses users who want to
> manage their own hierarchies like yourself. Since custom
> hierarchy management is an advanced topic I wanted to leave
> such users the liberty of using their own custom Category
> class. If the Hierarchy constructor was declared
>
> public
> Hierarchy(RootCategory root)
>
> then there would be less confusion but that would also impose
> the RootCategory at the top. The way things are today you can
> have FooRootCategory (possibly final) extending FooCategory
> extending Category and place FooRootCategory at the root or
> top of a custom hierarchy.
>
> I hope that helps, Ceki
>
> At 09:32 23.03.2001 -0600, Johnson, Clay wrote:
> >I am running in a JVM that may contain other applications,
> and I need to
> >configure log4j such that my logging environment is isolated
> from others.
> >Documentation in the Hierarchy class (v1.1b1) indicates a
> solution in the
> >form of a "non-default" (my wording) hierarchy, but I'm
> having difficulty
> >figuring how to go about it. In particular, the constructor
> for Hierarchy
> >requires a Category, but the Category constructor is
> protected, and it's
> >static factory methods would seem to apply to the default
> hierarchy. The
> >circularity is confusing.
> >
> >I would appreciate a hint or pointer to an example how to
> isolate logging in
> >a shared JVM.
> >
> >Thanks,
> >Clay
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> I hope to see you at my ApacheCon 2001 presentation
> entitled "Log4j, A Logging Package for Java".
>
> See http://ApacheCon.Com/2001/US/ for more details.
>
> --
> Ceki Gülcü Web: http://qos.ch
> email: [EMAIL PROTECTED] (preferred)
> [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
