Ah, good call. I'll just change do a replace '$' to '.' on the way in so:
Category cat = Category.getInstance(Inner.class.getName().replace('$',
'.');
I can do this on both inners and outers so that I can remain consistent.
Thanks once again,
Rex
-----Original Message-----
From: Jim Moore [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 29, 2001 9:48 AM
To: 'LOG4J Users Mailing List'
Subject: RE: Static vs. non-static categories and inner classes
That brings up a good question: Does the parser that creates a hierarchy for
Categories tokenize on a period only, or does it also understand $ as a
seperator? If not, then maybe Category.getInstance(Class clz) should
translate a $ in a name to a period.
-Jim Moore
-----Original Message-----
From: Rex Madden [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 29, 2001 9:34 AM
To: LOG4J Users Mailing List
Subject: RE: Static vs. non-static categories and inner classes
Thanks for the ideas.
So are you saying that having a dollar sign will screw up the hierarchy? I
just assumed that "com.Outer" would be a parent of "com.Outer$Inner". If
not, how about an enhancement that allows the "$" symbol to be interpreted
as a separator as well? (Sorry, normally I would have just tested this, but
I'm short on time this week.)
Although looking up the category dynamically is slower, I don't think it's
slow enough to warrant changing how I name the category and name its
variable (Again, if you're constructing the inner classes millions of times,
then that may be a concern.) I'd prefer to leave all of my Categories named
"cat" and use "Inner.class.getName()" for naming, this way it's a bit more
transparent when I'm moving classes around, or doing global search and
replaces.
Any thoughts?
Rex
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 29, 2001 8:45 AM
To: LOG4J Users Mailing List
Subject: RE: Static vs. non-static categories and inner classes
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
