At 10:14 29.01.2001 +0100, you wrote:
>How about this as an alternative?
>
>Declare the static log category in the outer class, eg
>
>class Outer
>{
> static Category cat = Category.getInstance(Outer.class.getName());
> static Category catInner = Category.getInstance(something);
>
> private class Inner
> {
> Inner() {catInner.debug("in Inner constructor");}
> }
>
> Outer {cat.debug("in Outer constructor");}
>}
IMO, this is the right approach. You probably want to name the inner class
category as:
something = Outer.class.getName() + ".innerClassName";
Inner.class.getName() won't work as there will be dollar sign between
"Outer" and "Inner"; probably not what you want.
Cheers, Ceki
ps: As mentioned previsly, there is nothing wrong with calling
Category.getInstance("...") to retrieve a category object dynamically.
However, this is slower then getting the variable directly as a static.
>I'm not sure how you can tidily pass a suitable string to the
>catInner constructor representing the inner class' name. And
>the *name* of the Category variable used from the Inner class
>must be different from the normal convention (cat) you've adopted,
>but on the positive side, the log object only gets constructed
>once.
>
>Regards,
>
>Simon
>
> > -----Original Message-----
> > From: Rex Madden [SMTP:[EMAIL PROTECTED]]
> > Sent: Saturday, January 27, 2001 11:32 PM
> > To: LOG4J Users Mailing List
> > Subject: RE: Static vs. non-static categories and inner classes
> >
> > Thanks Jim! So it sounds like the performance and memory penalties are
> > relatively small, unless those inner classes are created over and over
> > again. That's what I was hoping to hear...I just wanted to make sure
> > there weren't any weird side effects.
> >
> > Thanks again,
> > Rex
> >
> > -----Original Message-----
> > From: Jim Moore [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 27, 2001 5:16 PM
> > To: 'LOG4J Users Mailing List'
> > Subject: RE: Static vs. non-static categories and inner classes
> >
> > If you use a "static inner class" (aka "top-level member class") then you
> > can have static members in them. They have all the capabilities of other
> > top-level classes and then some.
> >
> > If, however, you want the real advantage of an "inner class" (because you
> > want to implicit OuterClass.this member) then the disadvantage of the
> > non-static Category declaration in that class is a very small performance
> > and memory penalty. The performance penalty comes from having to look up
> > the Category every time a new instance of the inner class is created. The
> > memory penalty is that each instance has another Reference associated with
> > it. (Since there's a hash guaranteeing that there's only one instance of
> > a Category of a particular name, there's no performance or memory cost
> > involved in creating new Categories for each inner class instance.)
> >
> > -Jim Moore
> >
> > -----Original Message-----
> > From: Rex Madden [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 27, 2001 3:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: Static vs. non-static categories and inner classes
> > I'm using the recommended approach to setting up Categories by software
> > component, so I generally use
> >
> > private static MyCategory cat =
> > (MyCategory)MyCategory.getInstance(ThisClass.class.getName());
> >
> > The problem is, I sometimes use inner classes, and since they cannot have
> > static member variables, I have to either:
> >
> > 1.
> > Declare the category member variable as non-static.
> > 2.
> > Simply use the outer class's Category
> >
> > I'd rather do number 1, but I'm not sure how mixing non-static and static
> > categories throughout my code will effect the logging output and
> > performance. Does anyone know the ramifications of having not-static
> > categories? Also, I'm using extended Category and Priority classes, if
> > that makes a difference (it shouldn't)
> >
> > Thanks,
> >
> > Rex
> >
> > P.S. Sorry if this is a stupid question, but statics always make my head
> > hurt.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
----
Ceki Gülcü - Independent IT Consultant
av. de Rumine 5 Tel: ++41 21 351 23 15
CH-1005 Lausanne e-mail: [EMAIL PROTECTED] or
Switzerland [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
