pglezen 01/06/04 21:41:00
Modified:src/java/org/apache/log4j/examples/appserver
AppServerCategoryFactory.java package.html
Log:
1. AppServerCategoryFactory - ctor changed to automatically
install itself as the default factory for use by the
AppS
Hello Paul,
Complexity is not the right word. The right term would be lack of reliability. The
user can get a category of a different type than expected depending on the order of
initialization of things. It's not a problem with your extensions. Anyway, I have to
get some sleep now. Tomorrow
Long-term, we could use Sun's proposed JAXB
http://java.sun.com/xml/jaxb/index.html:
JAXB (previously known as Project
Adelard) provides an API and tools that automate the mapping between XML
documents and Java objects.
-Chris
- Original Message -
From: "Paul Glezen" <[EMA
Priyank Johri wrote:
>
> Hi all,
> I am new to log4j, hence a simple question on
> log4j.properties file. Is there more documentation
> about all possible name/value pairs specified in the
> files than given in the sample files for the 'Sort'
> example? For e.g. if I want to name my log files
> s
Hi all,
I am new to log4j, hence a simple question on
log4j.properties file. Is there more documentation
about all possible name/value pairs specified in the
files than given in the sample files for the 'Sort'
example? For e.g. if I want to name my log files
so that they contain today's date as pa
Ceki,
Are you saying that the current manner of logging extensions (which, beyond
adding more appenders, usually amounts to the desire to add extra logging
attributes) is too complex? Perhaps I've been immersed in it for too long
to see it. From my prospective, the only undocumented complexity
IMHO, we should not add a Hashtable to LoggingEvent to address
brittleness of serialized LoggingEvents and probably not for any other
reason either.
If a particular Appender (a derivative of SocketAppender perhaps) wants
to serialize LoggingEvents as a set of string name-value pairs or XML
encode
paul,
XML based serialization could be useful for non-Java translations of log4j. Just one
of my far-fetched wishes... Ceki
At 10:56 04.06.2001 -0700, you wrote:
>I think the item Ceki has you working on takes priority over LoggingEvent
>serialization issues.
>
>As for the XML idea, that would
At 14:24 04.06.2001 -0400, you wrote:
>The rules for XML serialization/deserialization can be external to
>the LoggingEvent itself. Only when a remote logging event gets ready
>to go across the wire, it would inspect the LoggingEvent object and
>build the appropriate XML representation. This way
org.apache.log4j.Category lacks a toString() method - so here's the one
i've found useful.
if you don't like it, then maybe you'll write your own but Category is
an important class and really ought to have a toString method.
- robert
Index: src/java/org/apache/log4j/Category.java
==
At 10:43 04.06.2001 -0700, you wrote:
>Ceki,
>
>The PropertyConfigurator only sets the default category factory when
>someone has specified that a different category factory be used (via the
>categoryFactory property). Without this behaviour, we are saying go ahead
>and specify any factory you
Hi Paul,
The versioning/serialization problem you mention is a quite generic and goes beyond
log4j.
The solution adopted by some APIs, in particular JMS, is to encapsulate most
parameters in a HashMap. This allows the underlying data type to be indefinitely
extensible. The disadvantage is t
The rules for XML serialization/deserialization can be external to
the LoggingEvent itself. Only when a remote logging event gets ready
to go across the wire, it would inspect the LoggingEvent object and
build the appropriate XML representation. This way, only the people
using remote logging wil
I think the item Ceki has you working on takes priority over LoggingEvent
serialization issues.
As for the XML idea, that would solve the problem of version changes.
Presently, log4j is not dependent on the user having XML parsers available.
You need one if you want to use DOMConfigurator or if y
Ceki,
The PropertyConfigurator only sets the default category factory when
someone has specified that a different category factory be used (via the
categoryFactory property). Without this behaviour, we are saying go ahead
and specify any factory you want, but you can't use it to instantiate
cate
Paul Glezen wrote:
>
> Hi Mike,
>
> Here is a problem I have been interested but haven't had the time to
> investigate it fully. You might want to check it out.
>
> Log4j uses a class called LoggingEvent to encapsulate the information sent
> to appenders from categories. For cases of remote l
pglezen 01/06/04 10:35:42
Modified:src/java/org/apache/log4j PropertyConfigurator.java
Log:
Assignment of configured factory to hierarchy in
configureCategoryFactory removed pending further
review.
Revision ChangesPath
1.27 +5 -1
jakarta-log4j/src/java/org
Hello Paul,
Having the PropertyConfigurator set the default category is an important and rather
invasive change. I am uncomfortable with it especially because there is no way to
override it. I would like to have it commented out until we find a better solution.
Regards, Ceki
At 07:49 04.0
Hi Mike,
Here is a problem I have been interested but haven't had the time to
investigate it fully. You might want to check it out.
Log4j uses a class called LoggingEvent to encapsulate the information sent
to appenders from categories. For cases of remote logging, the event is
serialized and
This would be troublesome if multiple extensions were in use within the
same JVM. I do provide an alternative (referred to as "very manual
configuration" in the package javadocs) that leaves the hierarchy alone.
Unfortunately, this does not occur automatically (as implied by the name
"very manual
Hi Mike,
We all make mistakes there is no shame in that. I wouldn't worry about it.
Thank you for your offer for help. Bug #1960 might be suitable. Have a look at
http://nagoya.betaversion.org/bugzilla/show_bug.cgi?id=1960
Regards, Ceki
At 00:36 04.06.2001 -0700, you wrote:
>Ok, now tha
Hello Paul,
The recent addition of
Category.getDefaultHierarchy().setCategoryFactory(categoryFactory);
in configureCategoryFactory method in PropertyConfigurator.java is troublesome.
Setting the category factory once and fall al may be suitable in certain cases but
precludes different ex
Ok, now that I have embarressed myself on the user list maybe I should
do something to change my ignorance of the codebase. I'm new to this
process, so bear with me if I ask ignorant questions.
I don't really have any features I'd like to add. But I want to help.
Maybe I can help fix a bug or tw
23 matches
Mail list logo
