Hi and thank for your reply,
I have same kind of initialization routine in place (at least I think).
Code below is implemented in my shared library (ServletContextListener -
if that matters) and both web apps are using the listener (path to the
application specific configuration file is given with web context
parameter). After configuration routine have finished, I can see from
status messages, that web app B have initialized also rolling appender
from web app A configuration.
Can JBoss module's shared classloader somehow mess logging context used
in logback implementation? I have started to suspect some of
classloading issues, because I am also facing following scenario during
the JBoss startup:
1. Application A tries to invoke LoggerFactory.getILoggerFactory -->
doesn't get the correct LoggerContext because underlying logback is not
initialized properly(?)
2. Almost at the same time Application B tries to invoke
LoggerFactory.getILoggerFactory --> Correct LoggerContext is retrieved
and initialization continues
3. In step 1 I check if correct context is not returned, I put the
thread to sleep for 15 seconds. After thread becomes active again, I can
get correct LoggerContext and can do the initialization
Ville
On 20.3.2013 20:39, Donald McLean wrote:
The standard way for Logback to work, configuration is from the
logback.xml file.
I had a similar problem in that I wanted to be able to feed Logback a
custom configuration that came from somewhere else. This is the code
that I wrote to do the configuration:
val lc = LoggerFactory.getILoggerFactory.asInstanceOf[LoggerContext]
val configurator = new JoranConfigurator()
configurator.setContext(lc)
// the context was probably already configured by default
configuration rules
lc.reset()
val stream = configurationAsStream(data)
configurator.doConfigure(stream)
The code is in Scala, but it translates pretty easily since it's
pretty much all just function calls. The important part is the call to
"configurationAsStream", where I create an input stream containing the
logback configuration that I want the app to use.
Donald
On Wed, Mar 20, 2013 at 2:29 PM, Ville Hägg <[email protected]> wrote:
Hi all,
I need to clarify if I have understood logging separation correctly.
I have almost the same scenario than described e.g. in this question:
http://mailman.qos.ch/pipermail/logback-user/2010-March/001442.html. In my
environment I have most of the application logic deployed to JBoss 7 as a
JBoss module. Module have my shared libraries for common parts of the
application as well as third party libraries (like Logback and Spring). My
own custom shared implementations are using logging in a standard way by
instantiating loggers as a static class variables.
I am also having two war-applications which are using module described.
Requirement is to have own logging context for each of the application.
Which means applications should have their own log files, log levels and
root loggers etc. I have tried to introduce JNDIBasedContextDiscriminator
together with ShiftingAppender with no luck. My problem is that after my
applications are initialized, it seems both of them is somehow sharing the
same appenders. If I view status messages servlet, I can see that
application B have initialized also RollingFileAppenders configured in
application A's configuration file or other way round. RollingFileAppenders
are wrapped inside SiftingAppender in both configuration files.
Can anyone clarify to me can two applications using shared libraries have
strictly separated configuration files which are introducing own loggers,
appenders and logging levels? Or do I still have some kind of configuration
problem with my setup?
_______________________________________________
Logback-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________
Logback-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-user
