certainly it is true that the code for your own TriggeringEventEvaluator is
trivial. however my personal opinion is that being able to set the triggering
level is a requirement which is common enough to be implemented in the
SMTPAppender. e.g. setting it to FATAL because you only want to know
2 Logger.getLogger in my class files. It solves my purpose but just
wondering if my approach is fine?
It's perfect :-)
i'd put either the String JobStatus or the whole logger somewhere central
like into a singleton (to make sure you can change the loggers name easily) but
this is
hi wim,
i did not find any way to change the pattern, neither in the webstart nor in
the download version (with vigilog-1.3-SNAPSHOT.jar renamed to replace
vigilog-1.2.1.jar). but then i'm not sure if i realy have 1.3 working...
- how can i set the pattern?
- is there a way to see which
add the following to you log4j.properties:
log4j.rootCategory=ALL, R1, R2
to log all other events to both appenders/files
or
log4j.logger.AbstractAnimal =ALL, R1, R2
to log only the events of AbstractAnimal to both appenders/files
btw:
Note that the classes are in three difference packages
i made 3 extensions to DailyRoling file appender:
1) dated = the current logfile will also include the date and will not be
renamed on rolling
2) compressing = old logs are compressed.
3) cleaning = stupid name but it will delete all files ending with zip which
are older than the given max date.
i'm not sure if i understand what you want to do but i see 2 possibilities:
- have only one log4jconfig and in that define a separat console appender and
let the castor packages log to this (additivity=fasle)
- do the same configuration from within your code
cheers
patrick
-Ursprüngliche
As soon as I uncomment appender-ref ref=mail/ in the
example given
below, log4j is no longer picked up (by commons-logging). Is
there anything
if it's working otherwise then make sure that you have all needed libraries in
your classpath (mail.jar, activation.jar)
wrong with the
Why does the logger force you to use Strings?
no body is forced to log *strings* have a look at the signature of
Logger.info():
public void info(Object message)
so use StringBuffers (or if using java1.5 StringBuilder) if you like to.
however IMHO your code is generating unnecessary String
jacob,
thanks for your advice. as you seem to be expert on servlets maybe you can tell
me what you think of the way i used to handle my logs when i was doing servlets
under jboss (it's been more than a year ago, so this all may be a little
inaccurate):
1. i have 2 system properties: log-path
