[logback-user] ContextSelector and getLogger

[Martin Burchard]

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 at 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.