Well, our design is slightly more complicated, since the logging classes also need database access, and the logging classes in module A uses for example the datasource java:/A, so as the logging part is designed right now you can't view the classes as a library but as an EJB component that is customized for each app it runs with. It's probably a bad design choice and a JBoss issue, after all.
[I've written and sent this reply a few days ago, but used "Reply to Sender Only", my mistake...]
Elias Ross wrote:
On Wed, 2003-11-19 at 02:08, Stefan Puiu wrote:
The second one is related to finding a different solution using log4j. We needed to have a custom logger for two main reasons:
1) supplementary pattern converters (besides the parameters supported by log4j, we need a supplementary set specific to our app)
2) logging to a database; jdbcAppender is said to be experimental and subject to change in future versions, so we couldn't have used it without risking to have to change the code with newer log4j versions.
Can't you just write your own pattern converter and appender and stick only those few (2) classes in a .jar file, deploy them in $JBOSS_DIST/server/default/lib, and _not_ write your own Logger class? Assuming you don't need to change these very often, it may work better to have them static.
I'm not sure how reliable it is to have hot-redeployed appenders and pattern converters. People have a difficult enough time as-is without layering on class loading complexity.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
