wrapper-user

[Wrapper-user] Logging level of System.err

[Mark P. <Ma...@so...>]

I just discovered this project today.  I cannot believe how great it works 
and how easy it is to use. 

Of course I do have a question/request:

Is it possible to make messages that are written to System.err be treated 
by the log as ERROR instead of INFO?  (I also entered this request on 
sf.net prior to joining the list)

If not, then I assume the only way to get that sort of functionality is to 
use your WrapperManager.log() method.  I would rather not do that at this 
stage in case we wind up needing to run this code in environments that are 
not using your Wrapper.  If I do use this method, does your code fail 
gracefully at runtime if I am just running my code manually, such as using 
the Run/Debug methods from Eclipse? 

Thanks

Mark

Re: [Wrapper-user] Logging level of System.err

[Leif M. <le...@ta...>]

Mark Phippard wrote:

>I just discovered this project today.  I cannot believe how great it works 
>and how easy it is to use.
>
Great I'm glad you find it useful.

>Of course I do have a question/request:
>
>Is it possible to make messages that are written to System.err be treated 
>by the log as ERROR instead of INFO?  (I also entered this request on 
>sf.net prior to joining the list)
>
I have tried to get this working a couple times but the problem is that if I
break these up then if becomes very difficult to keep the System.out and
System.err messages in the correct order when writing them to the log file.
As long as the output rate is low, things work file.  But If an 
application kicks
out a bunch of  err output mixed in with out output all at once, then 
the err
ouput will appear grouped together in the log file followed by the out 
output.
I'll take another look at it, but I am not optimistic about getting this 
working.
Currently it is not possible.

One thing I have thought about is replacing the System.out and System.err
OutputStreams with streams which will prepend all output with a "E:" or 
a "O:".
The Wrapper would then strip these off and apply the correct log level.  The
user should never see the above tokens in either the console or the log 
files.
I have avoided this solutions as it would place a load on the console 
output.
It is probably not significant enough that I should really be worrying 
about it
however.

>If not, then I assume the only way to get that sort of functionality is to 
>use your WrapperManager.log() method.  I would rather not do that at this 
>stage in case we wind up needing to run this code in environments that are 
>not using your Wrapper.  If I do use this method, does your code fail 
>gracefully at runtime if I am just running my code manually, such as using 
>the Run/Debug methods from Eclipse? 
>
The WrapperManager class will work perfectly whether the JVM is being
controlled by the Wrapper or not.  IF you wish to run from within 
Eclipse, or
elsewhere without the Wrapper, here is what you do:
Set the wrapper.debug property to true and run the application normally
using the Wrapper.  This will display the full Java command used by the
Wrapper to launch Java.   Copy this command into a small one line batch
file.  Remove the -Dwrapper.key=XXXXXX parameter.  Then run the batch
file.  Your application should start up and run normally.
For eclipse, you would want to duplicate this command line in the Eclipse
configuration.

Cheers,
Leif

Re: [Wrapper-user] Logging level of System.err

[Mark P. <Ma...@so...>]

Leif,

Thanks for all of the info.

We are just going to go ahead and use your Log method instead of 
System.out and System.err.

Mark

[Wrapper-user] Logging filter enhancement

[Mark P. <Ma...@so...>]

Would it be possible to add an action of IGNORE to wrapper.filter.action? 
IGNORE would mean to not write the message to the log.

I would like to use this to enter some log messages as triggers that we 
would rather not write to the log.  I have a process where I am logging 
all of the messages retrieved after running a system command.  Some of 
these messages are just copyrights etc..  It would be nice if I could 
filter them out in the logging framework instead of in my code.  That way 
the user could control it, and if the copyrights changed I could just 
filter them out by updating the wrapper.conf.

Thanks

Mark

Re: [Wrapper-user] Logging filter enhancement

[Leif M. <le...@ta...>]

Mark,
In your last message, you said that you were going to use the Wrapper log
methods to control log output.  One option would be to send the output at
the DEBUG level.  this way it would not be displayed in the console, or the
wrapper.log file by default.

Otherwise,  I would suggest using Log4j or Avalon's LogKit to handle
logging from within the JVM.  They will do a much better job than the
Wrapper is capable of doing from outside.

Features have slowly been added to the Wrapper's logging over time in
response to user needs, but it is not designed to be a replacement for
a real logging system inside the JVM.   Most applications that I write 
handle
all logging within the JVM by sending application output to a dedicated log
file.  Only error messages are displayed to the console.  This keeps the
contents of the wrapper.log file fairly simple and dedicated to startup,
shutdown, and critical errors.  I know it is all personal preference though.

I'll give your request some thought.  Each filter adds some load to the
system as all log output must be scanned against each registered filter.
What you are asking for is to be able to hide an entire line of output if
that output contains a specified token?

Cheers,
Leif

Mark Phippard wrote:

>Would it be possible to add an action of IGNORE to wrapper.filter.action? 
>IGNORE would mean to not write the message to the log.
>
>I would like to use this to enter some log messages as triggers that we 
>would rather not write to the log.  I have a process where I am logging 
>all of the messages retrieved after running a system command.  Some of 
>these messages are just copyrights etc..  It would be nice if I could 
>filter them out in the logging framework instead of in my code.  That way 
>the user could control it, and if the copyrights changed I could just 
>filter them out by updating the wrapper.conf.
>  
>