You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by msew <ms...@ev1.net> on 2001/01/21 04:13:29 UTC
directory structure and and xml files
ok maybe I just need more caffeine and some sleep, but I can't for the life
of me find any listing in the documentation or examples of:
a multi package java project using .xml files for the log4j config options.
ie:
package org.foo.bar.util;
package org.foo.bar.server;
package org.foo.bar.server.msg;
package org.baz.client;
dir structure:
org/foo/bar/util
/server
/server/msg
/baz/client
so now with that you want to have your .xml files (and yes want the .xml
files and not the .properties) so where do you stick them?
for props some people just have a /props dir and dump them all in there
(which is semi scary imo) and others put them with the .java src files and
others have them somewhere and then copy them somewhere (ie like a
/distrib/classes and /distrib/props or something)
so where do you stick the .xml files?
also where are people sticking the .props files just for the info.
and depending on where you stick the .xml files how are people accessing
them? :) (ie the main method can get a nice command argument but it seems
it would be nice to have the location of a .java's corresponding .xml file
in THAT .java file. (ie in the org.foo.bar.server.UberServer.java in the
UberServer.java there would be a Configurator that grabs it's config stuff???)
Also I didn't see anyway to make a Category that maps to a method. (ie
org.foo.bar.server.UberServer.init() ). I would really like to make the
logger granular on the method level. So when you are making a new method
you can just turn it on and not the entire object without having to make a
billion different priorities(ie fooLog_methodA, fooLog_methodB) that is
unacceptable. Can you make method granular categories?
hope this makes sense I am going to pass out and hope that I have some mail
when I wake up
msew
Re: directory structure and and xml files
Posted by Ceki Gulcu <cg...@urbanet.ch>.
At 18:40 21.01.2001 -0800, you wrote:
>At 11:59 01/21/2001 +0100, Ceki Gulcu wrote:
>>One option, assuming your XML main configuration file is very long, is to
>>to chop it into different files and include them using XML external
>>entities from the main XML config file.
>
>do you have an example of this :-)
>
>Having one file seems pretty unacceptable on a big project :-) Especially
>if that file is being changed lots. having the external entities might be
>ok I think.
Here it is:
<?xml version="1.0" ?>
<!DOCTYPE documentRoot SYSTEM "some.dtd" [<!ENTITY data SYSTEM "file.xml">]>
<log4j:documentRoot>
&data; <---- embed a document within another XML document
</documentRoot>
>>Now, if your main configuration file is very very long, then the chances
>>are that you are not taking advantage of inheritance in the category hierarchy.
>
>Suppose I want to be really explicit (maybe overly so? ) but I want EVERY
>SINGLE method to have a category.
>
>Certainly many of these will not be used. Maybe never used , but I want
>the option to easily and quickly turn logging on in any given method in
>the entire project.
>
>
>ie: in a multi package project that spans the globe when various people
>that you don't know or even see face to face ever. you want the ability
>to turn on debugging in their entire package, in a object of theirs, or in
>the method you are calling of theirs. (ie I call the createDBEntry()
>method and I want to see ONLY that method's debug statements.)
>
>ie what I am looking/thinking of doing is:
>
>
>auto generated .xml file based on a class. all of the methods boom
>become categories :-)
I strongly advise that you avoid having a separate category for each
method. In large project you might have over 500 classes with 10 methods in
each class, that makes 5000 categories to deal with. Definitely a bad idea.
What you might want to do instead is to add a string with the name of the
calling method to each log request; then you could easily filter on the log
output using grep. What do you say? Ceki
----
Ceki Gülcü (cgu@urbanet.ch)
Re: directory structure and and xml files
Posted by msew <ms...@ev1.net>.
At 11:59 01/21/2001 +0100, Ceki Gulcu wrote:
>One option, assuming your XML main configuration file is very long, is to
>to chop it into different files and include them using XML external
>entities from the main XML config file.
do you have an example of this :-)
Having one file seems pretty unacceptable on a big project :-) Especially
if that file is being changed lots. having the external entities might be
ok I think.
>Now, if your main configuration file is very very long, then the chances
>are that you are not taking advantage of inheritance in the category hierarchy.
Suppose I want to be really explicit (maybe overly so? ) but I want EVERY
SINGLE method to have a category.
Certainly many of these will not be used. Maybe never used , but I want
the option to easily and quickly turn logging on in any given method in the
entire project.
ie: in a multi package project that spans the globe when various people
that you don't know or even see face to face ever. you want the ability to
turn on debugging in their entire package, in a object of theirs, or in the
method you are calling of theirs. (ie I call the createDBEntry() method
and I want to see ONLY that method's debug statements.)
ie what I am looking/thinking of doing is:
auto generated .xml file based on a class. all of the methods boom become
categories :-)
Re: directory structure and and xml files
Posted by Ceki Gulcu <cg...@urbanet.ch>.
Hi msew,
At 19:13 20.01.2001 -0800, you wrote:
>ok maybe I just need more caffeine and some sleep, but I can't for the
>life of me find any listing in the documentation or examples of:
>
>
>a multi package java project using .xml files for the log4j config options.
>
>
>ie:
>
>
>package org.foo.bar.util;
>
>package org.foo.bar.server;
>
>package org.foo.bar.server.msg;
>
>package org.baz.client;
>
>
>dir structure:
>
>org/foo/bar/util
> /server
> /server/msg
>
> /baz/client
>
>
>
>so now with that you want to have your .xml files (and yes want the .xml
>files and not the .properties) so where do you stick them?
>
>
>for props some people just have a /props dir and dump them all in there
>(which is semi scary imo) and others put them with the .java src files and
>others have them somewhere and then copy them somewhere (ie like a
>/distrib/classes and /distrib/props or something)
>
>so where do you stick the .xml files?
>
>
>also where are people sticking the .props files just for the info.
>
>
>
>and depending on where you stick the .xml files how are people accessing
>them? :) (ie the main method can get a nice command argument but it
>seems it would be nice to have the location of a .java's corresponding
>.xml file in THAT .java file. (ie in the
>org.foo.bar.server.UberServer.java in the UberServer.java there would be
>a Configurator that grabs it's config stuff???)
I belive most people deal with just one XML configuration file even in
multi package projects but that is just my guess. Inserting
DOMConfigurator.configure("foor.bar.xml") in the foo.bar class is probably
not a good idea.
One option, assuming your XML main configuration file is very long, is to
to chop it into different files and include them using XML external
entities from the main XML config file.
Now, if your main configuration file is very very long, then the chances
are that you are not taking advantage of inheritance in the category hierarchy.
>Also I didn't see anyway to make a Category that maps to a method. (ie
>org.foo.bar.server.UberServer.init() ). I would really like to make the
>logger granular on the method level. So when you are making a new method
>you can just turn it on and not the entire object without having to make a
>billion different priorities(ie fooLog_methodA, fooLog_methodB) that is
>unacceptable. Can you make method granular categories?
Assuming class foo.bar has N methods M1, M2, ...., MN. Let us also assume
that you are only interested in exercising granularity on methods M1 and
not the other methods.
Then, in "foo.bar", create a category "foo.bar.M1()" for method M1 and
category "foo.bar" for the rest of the foo.bar class. You just need to set
priorities for categories "foo.bar.M1()" and "foo.bar" separately.
For example if you set "foo.bar" to ERROR and "foo.bar.M1()" to DEBUG then
only ERROR messages in "foo.bar" will print except the log statements
contained in M1(). Does that answer the question?
>hope this makes sense I am going to pass out and hope that I have some
>mail when I wake up
You just did. I hope it answers your questions too. :-) Ceki
----
Ceki Gülcü (cgu@urbanet.ch)