Re: Plans for supporting a build in level of "trace"

[WJCarpenter]

It seems obvious enough why there is wide disagreement on how to use
the existing levels and/or whether more levels are needed.  People are
trying to cram selectively enabled logging into log4j's strict
hierarchical logging scheme.

What I think mos people want is some reasonable way of saying how much
logging they want (and the current scheme is fine for that) along with
saying what kind of information they want logged (the current scheme
is lousy for that).  What folks probably want for the latter is the
ability to turn on and off some selection of "items of interest".  

I'm sure many people independently do this outside of log4j.  I don't
know if it would be easy / reasonable / worthwhile to have some
facility inside log4j that implemented the same idea.  You might be
able to cook up some "items of interest" that were interesting to many
development efforts, but there would certainly be unique elements that
folks would want to use to supplement that.
-- 
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Do people use log4j in J2EE applications?

[WJCarpenter]

dl> It is also reasonable (and not that tough) to create Custom
dl> appenders that write directly to the vendors proprietary logger (I
dl> have one for WebLogic if you are interested)

I wouldn't mind seeing that.  Thanks.
-- 
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: log4j + j2ee error

[WJCarpenter]

> Thank you so much. "transient" eliminates the error. I still have a
> question, doesn't private declaration excludes data members from
> getting serialized/deserialized? - Sandeep


No.  There are various ways you can control what gets serialized, but if
you just take the defaults, everything is taken.


http://java.sun.com/j2se/1.4/docs/guide/serialization/




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: log4j + j2ee error

[WJCarpenter]

> So in your set up, I am guessing that ValueObjectFactory is returning a
> collection of a class named like EmployeeVO.  If this collection is
> then sent back to the client and the EmployeeVO instances making up the
> elements of that collection define a Logger (or Category) instance, the
> serialization will fail because Logger/Category is not serializable.
> You would need to mark the Logger/Category variable on the EmployeeVO
> class as transient.

You should also look at whether you had actually intended your
Logger/Category variable to be static.  Besides solving this problem, it
will give you a very minor performance assist.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Line numbers and method name of calling class

[WJCarpenter]

> re-inventing the wheel, um, I mean wrapper.  And there are issues
> surrounding whether to wrap or not to wrap.

Yeah, but isn't "write a wrapper" the standard advice given to people
who want to make additional logging levels?

-- 
[EMAIL PROTECTED] (WJCarpenter)PGP 0x91865119
38 95 1B 69 C9 C6 3D 2573 46 32 04 69 D6 ED F3




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Warning: no appenders found

[WJCarpenter]

> When I see this, it usually means I forgot to put the log4j.xml
> configuration file in the right place.

Yes, and be warned that if there is no config for log4j, it sets
itself to DEBUG level, even though there are no appenders.  You can
waste a lot of CPU time on DEBUG output that way.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

performance with NO configuration

[WJCarpenter]

I was startled to find this out, though it seems consistent with the
documentation.  Is this as expected?

If you run an instrumented application with no log4j configuration at
all, the default configuration sets the RootLogger to DEBUG.  Since
there are no appenders, there is a warning about that and, of course,
no logged output.

The problem is that setting the RootLogger to DEBUG cascades to set all
the other loggers to DEBUG.  Even though there are no appenders, the
value of logger.isDebugEnabled is true.  Lots of people follow the coding
pattern of wrapping complex things inside a check for whether some
particular level is enabled.  That's supposed to give the best performance.
If an application naively has no log4j.properties or equivalent, thinking
they'll get the best performance by completely disabling logging (or
maybe they don't even know anything about log4j inside some component
they're using), they'll actually get somewhat degraded performance.

Since this whole business only happens in the fallback of fallbacks (ie,
when there is no config info), what is the point of setting the RootLogger
to DEBUG?  Why not set it to ERROR or something to facilitate the
recommended coding pattern?




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Dumb question about logging in Windows

[WJCarpenter]

> I believe Java is smart enough to change forward slashes to back
> slashes in file names, so C:/App/logs/app.log may work.

It's not Java that has those smarts.  Most recent versions of MSWindows
will accept slashes in either direction.  (It also forbids both in
filenames.)  So, Java just hands the path to the operating system and
lets it do its thing.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Performance between Log4j and custom in-house logger

[WJCarpenter]

> Yes, you are right. My measurements doesn't account
> for the background thread processing time since it use
> the pattern observer/observable(more like publish and
> subscribe but in-process).

Performance has many dimensions.  You're talking about absolute intervals
for a single operation.  If you care about scalability, you definitely
want to account for the resources used by the background threads.  At
some point, the machine has to do the work, one way or another.

Also, you cited measurements that included start-up costs.  Unless you
have a fairly trivial application which doesn't live long, you might
want to consider factoring out the start-up costs as not mattering much
in the steady state.  (If you do have such an application, you're
probably being killed by JVM start-up overhead in the first place.)

Anyhow, maybe you already know all this and you're measuring things
just the way you want to measure them.  For a pretty significant percentage
of developers and applications, the above two points are pretty
pertinent, though.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: