To give you an impression of the pain of a Domino developer, here is a basic agent. package de.pentos.test.agents; import lotus.domino.AgentBase; import lotus.domino.AgentContext; import lotus.domino.Base; import lotus.domino.Database; import lotus.domino.Document; import lotus.domino.NotesException; import lotus.domino.Session; /** * @author Martin Burchard */ public class BasicAgent extends AgentBase { /** * Recycles every Domino object and doesn't care about the thrown * NotesException. * * @param obj */ public static void recycle(final Base obj) { if (obj != null) { try { obj.recycle(); } catch (NotesException e) {} } } @Override public void NotesMain() { Session session = null; AgentContext agCTX = null; Database db = null; Document doc = null; try { session = getSession(); agCTX = session.getAgentContext(); db = agCTX.getCurrentDatabase(); doc = agCTX.getDocumentContext(); // start doing something useful... } catch (NotesException e) { e.printStackTrace(); } finally { recycle(doc); recycle(db); recycle(agCTX); recycle(session); } } } Locking at the NotesMain method, you see that every Domino object that a developer uses needs to be recycled. If you forgot it, the Server will crash after a while. Behind the Java objects are C objects. Another bad thing. If you use a Domino API written of somebody else in your compony, without knowing how it works and your Java code and the other API are accessing the same database (for example to log into the database) both have 2 different Java objects but the same C object. If one of you recycles this database object, the C object is gone... Either your code fails, or the API fails... That is why you always have to deal with the lifetime and accessibility of Domino objects. That is what logging into a Domino database makes that hard... I hope this small excursus makes my question a little bit clearer. If you like I can also post how a basic WebService and Servlet looking like... Ceki Gulcu wrote:
See http://logback.qos.ch/manual/appenders.html#SiftingAppender which will work for all loggers, even those declared statically.
You could either put values in MDC when your thread starts or develop your own "discriminator" class based on thread ids. A discriminator has to implement the ch.qos.logback.core.sift.Discriminator interface.
With the help of this discriminator each thread will use its own specific appender. You could modify the discriminator so that several related thread map to the same value so that they use the same appender.
I fear that I still have not understood your environment very well. Thus, the above proposal might be off the mark.
HTH,
Martin Burchard wrote:
Hello Mahoney,
I read about MDC and Filter but I don't have a clue how to find the non static session object and the non static database object to write the log into the right database object.
The only other way, without using the ContextSelector is to create an Appender that tries to find the corresponding Session with ThreadLocal access. But I think that this wont be very fast...
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://www.nabble.com/ContextSelector-and-getLogger-tp22352655p22356808.html Sent from the Logback User mailing list archive at Nabble.com.