You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bob Johnson <bo...@tumbleweed.com> on 2001/04/20 16:15:39 UTC
Logging levels being ignored
As distributed, JAMES's logging "level" is set to DEBUG (the most verbose).
I attempted (w/o success) to reduce this level by editing the JAMES.xml.conf
line from
<channel name="default" loglevel="DEBUG" logwriter="default"/>
to
<channel name="default" loglevel="EMERGENCY" logwriter="default"/>
This attempt to go from one verbose extreme to the opposite is having NO
affect. All the DEBUG level msgs still appear in the logfiles (I did this
to all the channels). I'm assuming that the loglevel strings are the names
of the static int field names defined in the Logger interface.
Is this a bug with logging, or cockpit-error on my part?
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Manual steps in Avalon Framework.
Posted by Peter Donald <do...@apache.org>.
At 12:20 23/4/01 +0200, Leo Simons wrote:
></java:sig> > >I've not been fond of the configuration system ever since I
>> >saw it. I would like to have a single config file per .sar,
>>
>> you mean like we do? (conf/config.xml)
>
>we have two =)
you mean conf/server.xml ... I guess we could merge that with
conf/config.xml ... I am not sure - will look at it again though.
>> But remember that it was set up this way for a very specific reason - it
>> separates out the roles developer/assembler/deployer/admin. (Thou deployer
>> and admin are practically the same in our current model). The benefits of
>> this design may not be seen now but in time will become obvious.
>
>I am not quite sure that separation will ever be seen as the files are
>all packed into one .jar. I'll give it the benefit of the doubt though.
Same as the benefits of servlets/wars. Though typically there is minimal
"assembly" in web apps (unless you use EJBs extensively) it is an okay
example. Of separation between developer and deployer. (it relies on
servlet engine to do admin side though ;[).
>> >Note: I will probably set up phoenix so you can configure most
>> >of it through a conf/phoenix-conf.xml file, if no-one objects.
>>
>> that was vetoed ages ago but maybe if you put a good case for it ;)
>> (especially once we actually have some pluggable facilities).
>
>Looking at my current proposal, there's like 10 fields that need to
>be filled in some way. It has already got pluggable logger, deployer,
>kernel and manager. Making all the other facilities pluggable isn't
>much effort.
>Finding an efficient way to handle this plugging is.
The question was - do we a config file for that. In 90% of the cases you
are going to be using the defaults - when this is not the case it is simple
enough to do something like
run.sh --log-file=/var/log/some-server/server.log
the question is how often non-defaults will be used. I don't think we can
answer this yet - so we may aswell leave it for a bit later in dev cycle.
>> XML will still be required as part of deployment descriptor. Whether it
>> stays in that form or goes in via LDAP/XML/JMX/whatever is largely
>> irrelevent (I personally want LDAP).
>
>Since LDAP requires more than just java it can only ever be an option
>and not a requirment. But yes, it would be useful.
Hell yes - a tribe of 100 servers would be a PITA to manage individually ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Manual steps in Avalon Framework.
Posted by Leo Simons <ma...@leosimons.com>.
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig> > >I've not been fond of the configuration system ever since I
> >saw it. I would like to have a single config file per .sar,
>
> you mean like we do? (conf/config.xml)
we have two =)
> But remember that it was set up this way for a very specific reason - it
> separates out the roles developer/assembler/deployer/admin. (Thou deployer
> and admin are practically the same in our current model). The benefits of
> this design may not be seen now but in time will become obvious.
I am not quite sure that separation will ever be seen as the files are
all packed into one .jar. I'll give it the benefit of the doubt though.
> >Note: I will probably set up phoenix so you can configure most
> >of it through a conf/phoenix-conf.xml file, if no-one objects.
>
> that was vetoed ages ago but maybe if you put a good case for it ;)
> (especially once we actually have some pluggable facilities).
Looking at my current proposal, there's like 10 fields that need to
be filled in some way. It has already got pluggable logger, deployer,
kernel and manager. Making all the other facilities pluggable isn't
much effort.
Finding an efficient way to handle this plugging is.
> XML will still be required as part of deployment descriptor. Whether it
> stays in that form or goes in via LDAP/XML/JMX/whatever is largely
> irrelevent (I personally want LDAP).
Since LDAP requires more than just java it can only ever be an option
and not a requirment. But yes, it would be useful.
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Manual steps in Avalon Framework.
Posted by Peter Donald <do...@apache.org>.
At 10:01 23/4/01 +0200, Leo Simons wrote:
>> How about also having one file say blocks.xml that describes all
>> the blocks
>> and from which xinfo and provide part of assembly.xml could be generated.
>
><snip>
>
>> what do you think ?
-1 defeats the purpose of composing in a component based system.
>I've not been fond of the configuration system ever since I
>saw it. I would like to have a single config file per .sar,
you mean like we do? (conf/config.xml)
or
>one per .bar if the file otherwise becomes to large. Additionally,
>you might want to be able to include a security.policy on a per-sar
>basis.
like we do ? (conf/server.xml?server/policy)
>This is not something to change lightly - changing the mechanism
>means everyone who uses it to rewrite their files. Then again, I'd
>say we cannot change this for a long time after we go beta.
But remember that it was set up this way for a very specific reason - it
separates out the roles developer/assembler/deployer/admin. (Thou deployer
and admin are practically the same in our current model). The benefits of
this design may not be seen now but in time will become obvious.
>Note: I will probably set up phoenix so you can configure most
>of it through a conf/phoenix-conf.xml file, if no-one objects.
that was vetoed ages ago but maybe if you put a good case for it ;)
(especially once we actually have some pluggable facilities).
>one more note: long term prediction - the use of xml for configuration
>files will decline once it becomes easy to pass a configuration
>object through JMX.
XML will still be required as part of deployment descriptor. Whether it
stays in that form or goes in via LDAP/XML/JMX/whatever is largely
irrelevent (I personally want LDAP).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Manual steps in Avalon Framework.
Posted by Leo Simons <ma...@leosimons.com>.
> How about also having one file say blocks.xml that describes all
> the blocks
> and from which xinfo and provide part of assembly.xml could be generated.
<snip>
> what do you think ?
+1
I've not been fond of the configuration system ever since I
saw it. I would like to have a single config file per .sar, or
one per .bar if the file otherwise becomes to large. Additionally,
you might want to be able to include a security.policy on a per-sar
basis.
This is not something to change lightly - changing the mechanism
means everyone who uses it to rewrite their files. Then again, I'd
say we cannot change this for a long time after we go beta.
Note: I will probably set up phoenix so you can configure most
of it through a conf/phoenix-conf.xml file, if no-one objects.
one more note: long term prediction - the use of xml for configuration
files will decline once it becomes easy to pass a configuration
object through JMX.
regards,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Manual steps in Avalon Framework.
Posted by Harmeet Bedi <hb...@yahoo.com>.
From: "Peter Donald" <do...@apache.org>
> In the short term what does everyone think about relaxing the requirement
> that blocks be indicated by manifest. This requirement was mainly added in
> to ease management via GUI ... but we aren't quite there yet ....
thoughts?
I think it is a good idea. One could ignore the manifest.mf if it exists.
The same information exists elsewhere.
How about also having one file say blocks.xml that describes all the blocks
and from which xinfo and provide part of assembly.xml could be generated.
A DTD could be.
----------------------------------
<ELEMENT blocks (blockinfo*)>
<ELEMENT blockinfo (service+,dependency*)>
<ATTLIST blockinfo name CDATA required>
<ELEMENT service (#PCDATA)>
<ATTLIST service name CDATA required>
<ELEMENT dependency (#PCDATA)>
-------------------------------------
for example the XCommander could be specified like this
<blocks>
<blockinfo name="xcommander-server">
<service name="sockets">
org.apache.cornerstone.services.sockets.SocketManager
</service>
<service name="connections">
org.apache.cornerstone.services.connection.ConnectionManager
</service>
</blockinfo>
....
....
<blocks>
This contains all the information in assembly(sans config) and xinfo for
xcommander
One could generate .xinfo and assembly.xml or even deprecate .xinfo and
assembly.xml for blocks.xml and config.xml.
Advantages would be
- less duplication.
- less chance of spending time on sometimes easy to miss configuration
mistakes.
- easier to configure. lower barrier of use.
what do you think ?
Harmeet
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Manual steps in Avalon Framework.
Posted by Harmeet Bedi <hb...@yahoo.com>.
From: "Peter Donald" <do...@apache.org>
> In the short term what does everyone think about relaxing the requirement
> that blocks be indicated by manifest. This requirement was mainly added in
> to ease management via GUI ... but we aren't quite there yet ....
thoughts?
I think it is a good idea. One could ignore the manifest.mf if it exists.
The same information exists elsewhere.
How about also having one file say blocks.xml that describes all the blocks
and from which xinfo and provide part of assembly.xml could be generated.
A DTD could be.
----------------------------------
<ELEMENT blocks (blockinfo*)>
<ELEMENT blockinfo (service+,dependency*)>
<ATTLIST blockinfo name CDATA required>
<ELEMENT service (#PCDATA)>
<ATTLIST service name CDATA required>
<ELEMENT dependency (#PCDATA)>
-------------------------------------
for example the XCommander could be specified like this
<blocks>
<blockinfo name="xcommander-server">
<service name="sockets">
org.apache.cornerstone.services.sockets.SocketManager
</service>
<service name="connections">
org.apache.cornerstone.services.connection.ConnectionManager
</service>
</blockinfo>
....
....
<blocks>
This contains all the information in assembly(sans config) and xinfo for
xcommander
One could generate .xinfo and assembly.xml or even deprecate .xinfo and
assembly.xml for blocks.xml and config.xml.
Advantages would be
- less duplication.
- less chance of spending time on sometimes easy to miss configuration
mistakes.
- easier to configure. lower barrier of use.
what do you think ?
Harmeet
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Manual steps in Avalon Framework. Was: Logging levels
being ignored
Posted by Peter Donald <do...@apache.org>.
At 02:59 21/4/01 -0700, Harmeet Bedi wrote:
>There are a few places in Avalon that require same name.
>For example to add a block one needs to enter interrelated informaion in
>- .xinfo file
>- Manifest.mf
>- server.xml for logging
>- assembly.xml.
>
>There seems to be some duplication and getting one or more of these wrong
>can eat up a lot of time. Would it make sense to have code generators
>automate some of these. One could specify information only once and have an
>Ant target or a tool generate the correct files.
Yep this is definetly a long term goal and the reason why we do a few
things. (Like have Service interface and put entries in manifest).
In the short term what does everyone think about relaxing the requirement
that blocks be indicated by manifest. This requirement was mainly added in
to ease management via GUI ... but we aren't quite there yet .... thoughts?
>I wrote a python script to read assembly.xml and generate the block
>dependent part of server.xml. Attaching it. Automating part of server.xml
>removed logging issues in James. Maybe this, or something better should be
>added to Avalon. I was thinking that having templates, data file and an Ant
>Target would make things nicer.
>In the meantime maybe a few python scripts could help. :-)
excellent. added in under tools/bin - thanks ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Manual steps in Avalon Framework. Was: Logging levels
being ignored
Posted by Peter Donald <do...@apache.org>.
At 02:59 21/4/01 -0700, Harmeet Bedi wrote:
>There are a few places in Avalon that require same name.
>For example to add a block one needs to enter interrelated informaion in
>- .xinfo file
>- Manifest.mf
>- server.xml for logging
>- assembly.xml.
>
>There seems to be some duplication and getting one or more of these wrong
>can eat up a lot of time. Would it make sense to have code generators
>automate some of these. One could specify information only once and have an
>Ant target or a tool generate the correct files.
Yep this is definetly a long term goal and the reason why we do a few
things. (Like have Service interface and put entries in manifest).
In the short term what does everyone think about relaxing the requirement
that blocks be indicated by manifest. This requirement was mainly added in
to ease management via GUI ... but we aren't quite there yet .... thoughts?
>I wrote a python script to read assembly.xml and generate the block
>dependent part of server.xml. Attaching it. Automating part of server.xml
>removed logging issues in James. Maybe this, or something better should be
>added to Avalon. I was thinking that having templates, data file and an Ant
>Target would make things nicer.
>In the meantime maybe a few python scripts could help. :-)
excellent. added in under tools/bin - thanks ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Manual steps in Avalon Framework. Was: Logging levels being ignored
Posted by Harmeet Bedi <hb...@yahoo.com>.
There are a few places in Avalon that require same name.
For example to add a block one needs to enter interrelated informaion in
- .xinfo file
- Manifest.mf
- server.xml for logging
- assembly.xml.
There seems to be some duplication and getting one or more of these wrong
can eat up a lot of time. Would it make sense to have code generators
automate some of these. One could specify information only once and have an
Ant target or a tool generate the correct files.
I wrote a python script to read assembly.xml and generate the block
dependent part of server.xml. Attaching it. Automating part of server.xml
removed logging issues in James. Maybe this, or something better should be
added to Avalon. I was thinking that having templates, data file and an Ant
Target would make things nicer.
In the meantime maybe a few python scripts could help. :-)
Harmeet
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
Subject: Re: Logging levels being ignored
>
> At 10:15 20/4/01 -0400, Bob Johnson wrote:
> >As distributed, JAMES's logging "level" is set to DEBUG (the most
verbose).
> >I attempted (w/o success) to reduce this level by editing the
JAMES.xml.conf
> >line from
> >
> > <channel name="default" loglevel="DEBUG" logwriter="default"/>
> >to
> > <channel name="default" loglevel="EMERGENCY"
logwriter="default"/>
> >
> >This attempt to go from one verbose extreme to the opposite is having NO
> >affect. All the DEBUG level msgs still appear in the logfiles (I did
this
> >to all the channels). I'm assuming that the loglevel strings are the
names
> >of the static int field names defined in the Logger interface.
> >
> >Is this a bug with logging, or cockpit-error on my part?
>
> It could be either. At one stage there was a bug in logging. Which version
> are you using? Another possibility is that the categories in config file
> may no longer line up with categories used in code.
> Cheers,
>
> Pete
Manual steps in Avalon Framework. Was: Logging levels being ignored
Posted by Harmeet Bedi <hb...@yahoo.com>.
There are a few places in Avalon that require same name.
For example to add a block one needs to enter interrelated informaion in
- .xinfo file
- Manifest.mf
- server.xml for logging
- assembly.xml.
There seems to be some duplication and getting one or more of these wrong
can eat up a lot of time. Would it make sense to have code generators
automate some of these. One could specify information only once and have an
Ant target or a tool generate the correct files.
I wrote a python script to read assembly.xml and generate the block
dependent part of server.xml. Attaching it. Automating part of server.xml
removed logging issues in James. Maybe this, or something better should be
added to Avalon. I was thinking that having templates, data file and an Ant
Target would make things nicer.
In the meantime maybe a few python scripts could help. :-)
Harmeet
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
Subject: Re: Logging levels being ignored
>
> At 10:15 20/4/01 -0400, Bob Johnson wrote:
> >As distributed, JAMES's logging "level" is set to DEBUG (the most
verbose).
> >I attempted (w/o success) to reduce this level by editing the
JAMES.xml.conf
> >line from
> >
> > <channel name="default" loglevel="DEBUG" logwriter="default"/>
> >to
> > <channel name="default" loglevel="EMERGENCY"
logwriter="default"/>
> >
> >This attempt to go from one verbose extreme to the opposite is having NO
> >affect. All the DEBUG level msgs still appear in the logfiles (I did
this
> >to all the channels). I'm assuming that the loglevel strings are the
names
> >of the static int field names defined in the Logger interface.
> >
> >Is this a bug with logging, or cockpit-error on my part?
>
> It could be either. At one stage there was a bug in logging. Which version
> are you using? Another possibility is that the categories in config file
> may no longer line up with categories used in code.
> Cheers,
>
> Pete
Re: Logging levels being ignored
Posted by Peter Donald <do...@apache.org>.
At 10:15 20/4/01 -0400, Bob Johnson wrote:
>As distributed, JAMES's logging "level" is set to DEBUG (the most verbose).
>I attempted (w/o success) to reduce this level by editing the JAMES.xml.conf
>line from
>
> <channel name="default" loglevel="DEBUG" logwriter="default"/>
>to
> <channel name="default" loglevel="EMERGENCY" logwriter="default"/>
>
>This attempt to go from one verbose extreme to the opposite is having NO
>affect. All the DEBUG level msgs still appear in the logfiles (I did this
>to all the channels). I'm assuming that the loglevel strings are the names
>of the static int field names defined in the Logger interface.
>
>Is this a bug with logging, or cockpit-error on my part?
It could be either. At one stage there was a bug in logging. Which version
are you using? Another possibility is that the categories in config file
may no longer line up with categories used in code.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org