I appreciate any response...I may stumble to the solution by explaining my
problem.
I have actually implemented the service threads exactly as you mentioned. I
should've explained that before.
My log4j.properties files for the server and services are almost identical
with the exception of the log file names. Below is an example with the
layout pattern including the %t that has saved me many hours in debugging.
log4j.rootCategory=DEBUG, Default, Console
log4j.appender.Default=org.apache.log4j.DailyRollingFileAppender
log4j.appender.Default.File=server/log/server.log
log4j.appender.Default.DatePattern='.'yyyy-MM-dd
# log4j.appender.Default.MaxFileSize=500KB
# log4j.appender.Default.MaxBackupIndex=1
log4j.appender.Default.layout=org.apache.log4j.PatternLayout
log4j.appender.Default.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
log4j.appender.Default.Append=true
log4j.appender.Console=org.apache.log4j.ConsoleAppender
log4j.appender.Console.layout=org.apache.log4j.PatternLayout
log4j.appender.Console.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
log4j.debug=true
I can confirm that the thread that runs the service corresponds to the
correct service context classloader. I have a ServiceClassLoader (SCL) that
simply extends URLClassLoader. Each service that is deployed has its own
SCL (same theory as App Servers) which are registered as MBeans in JMX.
In my service threads, I save the current context classloader like so and
set the context classloader with the service classloader that is about to
run.
I then load my class and call the interface method implementation and reset
the context classloader to the saved classloader when all is done.
...
try {
appClass = cl.loadClass(classname);
appObject = appClass.newInstance();
if ( appObject instanceof ServiceHandler ) {
ServiceHandler handler = ( ServiceHandler )
appObject;
ctxCLBackup =
Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(cl);
serviceLogger =
Logger.getLogger(CallReceiver.class.getName());
try {
handler.handleCall(call, context);
} catch (RuntimeException rte) {
rte.printStackTrace();
}
} else {
...
}
} catch (...) {
} finally {
Thread.currentThread().setContextClassLoader(ctxCLBackup);
...
}
>From my research on the net, I found that to be the general steps. Am I
doing something wrong?
Many thanks
Vance
-----Original Message-----
From: Carl Brenton [mailto:[EMAIL PROTECTED]
Sent: Friday, 19 March 2004 1:58 AM
To: Log4J Users List
Subject: RE: Contextual Repository Selector problem
This probably doesn't help much...
1. dump the threads in the logs (%t in <appender>.layout.CovertionPattern
parameter)
2. verify the ClassLoader (getContextClassLoader) when writing the log. I
*guess* this should be the same as when the service was created by your
classloader.
After that try this in each "service" application :-
1. save the current context classloader
2. set the current context classloader
(Thread.currentThread().setContextClassloader(
this.getClass().getClassLoader() ); )
3. perform your logging etc
4. restore the saved context classloader
Carl
> -----Original Message-----
> From: Vance Karimi [mailto:[EMAIL PROTECTED]
> Sent: Thursday 18 March 2004 16:28
> To: [EMAIL PROTECTED]
> Subject: Contextual Repository Selector problem
>
>
> Hi
> I am writing a container server application that runs
> services/contexts
> within it. These services are hot deployed in a jar file and
> I manage the
> ClassLoaders to handle separate contexts. I need to implement the
> repository selector in Log4j so each thread that runs a
> service logs to a
> separate log file.
>
> Based on the following http://www.qos.ch/logging/sc.html I
> have a Repository
> Selector something very similar to:
>
>
> import org.apache.log4j.spi.RepositorySelector;
> import org.apache.log4j.spi.LoggerRepository;
> import org.apache.log4j.spi.RootCategory;
> import org.apache.log4j.Hierarchy;
> import org.apache.log4j.Level;
> import java.util.Hashtable;
>
> public class CRS implements RepositorySelector {
>
> // key: current thread's ContextClassLoader,
> // value: Hierarchy instance
> private Hashtable ht;
>
> public CRS() {
> ht = new Hashtable();
> }
>
> public LoggerRepository getLoggerRepository() {
> LoggerRepository loggerRepository = null;
>
> ClassLoader classLoader =
> Thread.currentThread().getContextClassLoader();
>
> loggerRepository = (LoggerRepository)
> loggerRepositories.get(classLoader.toString());
>
> if (loggerRepository != null) {
> // do nothing
> } else {
> loggerRepository = new Hierarchy(new RootCategory((Level)
> Level.DEBUG));
> loadRepository(loggerRepository);
> loggerRepositories.put(classLoader.toString(),
> loggerRepository);
>
> }
>
> return loggerRepository;
> }
>
> /**
> * The Container should remove the entry when the web-application
> * is removed or restarted.
> * */
> public void remove(ClassLoader cl) {
> if (loggerRepositories.containsKey(cl.toString())) {
> LoggerRepository lr = (LoggerRepository)
> loggerRepositories.get(cl.toString());
> lr.resetConfiguration();
> }
> loggerRepositories.remove(cl.toString());
> }
>
> private static void loadRepository(LoggerRepository
> loggerRepository) {
>
> URL url = getURL(resources);
>
> if (url != null) {
> OptionConverter.selectAndConfigure(url, null,
> loggerRepository);
> }
> }
> .....
> }
>
>
> I set the Context Repository Selector when the server first starts up:
>
> if (guard == null) {
> guard = new Object();
> }
>
> ContextRepositorySelector crs =
> agent.registerContextRepositorySelector();
> LogManager.setRepositorySelector(crs, guard);
>
>
> I have enabled debugging in Log4j. When my server first
> starts up, I get
> the following debug statements due to the log4j.properties of
> the server,
> showing the root context and 2 appenders (Default and Console)
>
> log4j: Parsing for [root] with value=[DEBUG, Default, Console].
> log4j: Level token is [DEBUG].
> log4j: Category root set to DEBUG
> log4j: Parsing appender named "Default".
> log4j: Parsing layout options for "Default".
> log4j: Setting property [conversionPattern] to [%d [%t] %-5p
> %c - %m%n].
> log4j: End of parsing for "Default".
> log4j: Setting property [append] to [true].
> log4j: Setting property [file] to [server/log/server.log].
> log4j: Setting property [datePattern] to ['.'yyyy-MM-dd].
> log4j: setFile called: server/log/server.log, true
> log4j: setFile ended
> log4j: Appender [Default] to be rolled at midnight.
> log4j: Parsed "Default" options.
> log4j: Parsing appender named "Console".
> log4j: Parsing layout options for "Console".
> log4j: Setting property [conversionPattern] to [%d [%t] %-5p
> %c - %m%n].
> log4j: End of parsing for "Console".
> log4j: Parsed "Console" options.
> log4j: Finished configuring.
> log4j: JIVS: Time taken to look up loggerRepository 368ms
>
> I then deploy my service and call
> Logger.getLogger(my.service.class) to get
> the following for the root logger with 2 appenders(A1 and A2):
>
> log4j: Parsing for [root] with value=[DEBUG, A1, A2].
> log4j: Level token is [DEBUG].
> log4j: Category root set to DEBUG
> log4j: Parsing appender named "A1".
> log4j: Parsing layout options for "A1".
> log4j: Setting property [conversionPattern] to [%d [%t] %-5p
> %c - %m%n].
> log4j: End of parsing for "A1".
> log4j: Setting property [file] to [server/log/recorder.log].
> log4j: Setting property [append] to [true].
> log4j: Setting property [datePattern] to ['.'yyyy-MM-dd].
> log4j: setFile called: server/log/recorder.log, true
> log4j: setFile ended
> log4j: Appender [A1] to be rolled at midnight.
> log4j: Parsed "A1" options.
> log4j: Parsing appender named "A2".
> log4j: Parsing layout options for "A2".
> log4j: Setting property [conversionPattern] to [%d [%t] %-5p
> %c - %m%n].
> log4j: End of parsing for "A2".
> log4j: Parsed "A2" options.
> log4j: Finished configuring.
> log4j: JIVS: Time taken to look up loggerRepository 33ms
>
> Now the problem:
>
> All my logs are directed to server.log and the console. The
> recorder.log
> (log for the deployed service) is created, but no logs are
> appended to the
> file. I know the log4j.properties config file of the service
> is found and
> loaded correctly due to the debug statements.
>
> I really need some direction here and have come to a dead end. Your
> feedback would be really appreciated.
>
> Cheers,
> Vance
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
This message has been scanned for viruses by MailControl -
www.mailcontrol.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
