June 2009 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-133) Deadlock because of logging
by Olivier Cailloux (JIRA) 26 Jun '09

26 Jun '09

Deadlock because of logging --------------------------- Key: LBCLASSIC-133 URL: http://jira.qos.ch/browse/LBCLASSIC-133 Project: logback-classic Issue Type: Improvement Affects Versions: unspecified Reporter: Olivier Cailloux Assignee: Logback dev list The short story is that in some circumstances, calling "s_logger.debug("Current worker status is: {}.", worker);" creates a deadlock while calling "s_logger.debug("Current worker status is: {}.", worker.toString());" does not. This is because the logger tries to acquire a lock on the worker object *while holding the lock on the logger itself*. It would be a good improvement, IMHO, to logback if the logger did not do that. In more details, the pattern is the following. (Please see hereby the java classes which might be clearer.) - In a class "Worker", a method "work()" locks the object instance of the class Worker to do some work and calls the logging framework to print the result (while still holding the lock). - In the same class "Worker", an other method "getStatus()" obtains the current status of the object instance of the class Worker and returns it as a String (method used for logging). That method locks the object at some point to make sure it reads consistent internal status information. - In an other class "Accessor", a method "access()" performs some work (not locking anything), then logs the status of an object of the class Worker by using its getStatus() method. Now the deadlock scenario is the following. - A thread "WorkerThread" is executing the method "work()". It has acquired the lock for the Worker object and has not reached the logging statement yet. - An other thread "AccessorThread" is executing the method "access()", and is executing the logging statement. AFAIU, logback console logger has some sort of "central" locking point: when a thread is logging, an other thread may not log in parallel (that seems good as the user does not want his different logging statements to be mixed together)... Thus, the following happens. - AccessorThread has a lock to the Logger, and waits to acquire the Worker lock to execute the synchronized block in getStatus(). - WorkerThread is holding that precise lock, and will never release it, because arriving at the logging statement in "work()", it starts waiting for the Logger lock acquired by AccessorThread. These two threads are caught in a deadlock. My reasoning: I feel the problem comes from not respecting the general rule that a block of code holding a lock should not call a method on an externally controlled object (possibly shared with other threads) whose locking behavior is unknown. (Note that both the example code and the logging framework do not respect this rule, AFAIU.) If the logging implementation respected this rule, the user of the logging framework would not have to bother about thinking of locking issues *created by the use of the logging framework*, but only to his own locking problems inside his code. Currently, the two solutions I see for the logback user to overcome the deadlock issues are both not completely satisfactory: - don't use parametrized logging to spare the time of "stringification" of an object when logging and rather always call ".toString()" explicitely, as in the above example ; or - quit every lock you hold on your own objects before calling any logging statement. (Very unpractical!) A very nice improvement to logback classic (solving this class of problems, AFAIU) would be that logback releases its internal lock before calling the .toString method of the worker object, then locks itself again. You will find hereby an example reliably reproducing the deadlock problem (classes Accessor, Worker, and DeadlockTest which has a JUnit4 test case, with the appropriate logback configuration file). I don't know if this behavior is a bug or a "feature". If the improvement I suggest is too difficult to implement (or impractical for reasons I didn't think of), then a good improvement would be to document this fact. The possibility of introducing deadlock problems in a program when adding logging statements is something users should be warned against! (And once you have a deadlock problem in your code you don't start looking at the logging statements, so it can take much time to find the cause.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 9

[JIRA] Created: (LBCORE-62) Dinimish contention among concurrent threads when using logback
by Ceki Gulcu (JIRA) 26 Jun '09

26 Jun '09

Dinimish contention among concurrent threads when using logback --------------------------------------------------------------- Key: LBCORE-62 URL: http://jira.qos.ch/browse/LBCORE-62 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.9 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Fix For: 0.9.10 We should strive to diminish interference among concurrent threads when using logback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 1

svn commit: r2301 - logback/trunk/logback-site/src/site/resources
by noreply.ceki＠qos.ch 26 Jun '09

26 Jun '09

Author: ceki Date: Fri Jun 26 21:04:24 2009 New Revision: 2301 Removed: logback/trunk/logback-site/src/site/resources/10reasons.ppt Modified: logback/trunk/logback-site/src/site/resources/logback.ppt Log: - removed 10reasons.ppt - added remark about log4j no longer being actively developed Modified: logback/trunk/logback-site/src/site/resources/logback.ppt ============================================================================== Binary files. No diff available.

1 0

svn commit: r2300 - logback/trunk/logback-site/src/site/resources
by noreply.ceki＠qos.ch 26 Jun '09

26 Jun '09

Author: ceki Date: Fri Jun 26 21:01:08 2009 New Revision: 2300 Modified: logback/trunk/logback-site/src/site/resources/logback.ppt Log: updated to the logback presentation Modified: logback/trunk/logback-site/src/site/resources/logback.ppt ============================================================================== Binary files. No diff available.

1 0

[JIRA] Created: (LBCLASSIC-110) TargetLengthBasedClassNameAbbreviator does not work for strings with more than 12 dots (inclusive).
by Lukas Zapletal (JIRA) 22 Jun '09

22 Jun '09

TargetLengthBasedClassNameAbbreviator does not work for strings with more than 12 dots (inclusive). --------------------------------------------------------------------------------------------------- Key: LBCLASSIC-110 URL: http://jira.qos.ch/browse/LBCLASSIC-110 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.9, 0.9.10, 0.9.11, 0.9.12, 0.9.13, 0.9.14, 0.9.15 Reporter: Lukas Zapletal Assignee: Logback dev list Please add this to TargetLengthBasedClassNameAbbreviatorTest: System.out.println("13"); { // 13 dots test TargetLengthBasedClassNameAbbreviator abbreviator = new TargetLengthBasedClassNameAbbreviator(20); String name = "com.pike.test.puma.wm.isd2dita.core.g.project.server.pkg.isobjecttype.isobject.ISObjectContentGenerator"; assertEquals("c.p.t.p.w.i.c.g.o.s.r.i.ISObjectContentGenerator", abbreviator.abbreviate(name)); } System.out.println("12"); { // 12 dots test TargetLengthBasedClassNameAbbreviator abbreviator = new TargetLengthBasedClassNameAbbreviator(20); String name = "com.pike.puma.wm.isd2dita.core.g.project.server.pkg.isobjecttype.isobject.ISObjectContentGenerator"; assertEquals("c.p.p.w.i.c.g.o.s.r.i.ISObjectContentGenerator", abbreviator.abbreviate(name)); } Logs are disappearing when this bug occurs. It throws ArrayIndexOfBounds when testing but in production logs are just skipped (thus this bug is not FATAL-CRITICAL). Workaround: higher the 12 dot limit. Better workaround: handle with strings correctly not to ses AIOB exception ever. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3

svn commit: r2299 - in logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue: lbclassic133 lbclassic36
by noreply.ceki＠qos.ch 21 Jun '09

21 Jun '09

Author: ceki Date: Sun Jun 21 17:33:13 2009 New Revision: 2299 Added: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic133/Deadlock_Tapp.java - copied, changed from r2298, /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic133/DeadlockTest.java logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatOriginal_tzest.java - copied, changed from r2298, /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/TestDateFormatOriginal.java logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatPerf_Tapp.java - copied, changed from r2298, /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatPerfTest.java Removed: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic133/DeadlockTest.java logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatPerfTest.java logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/TestDateFormatOriginal.java Log: - renaming non-junit application as Tapp (test app). Rrecent maven versions had trouble with the old names. Copied: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic133/Deadlock_Tapp.java (from r2298, /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic133/DeadlockTest.java) ============================================================================== --- /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic133/DeadlockTest.java (original) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic133/Deadlock_Tapp.java Sun Jun 21 17:33:13 2009 @@ -5,8 +5,8 @@ import org.slf4j.Logger; import org.slf4j.LoggerFactory; -public class DeadlockTest { - private static Logger s_logger = LoggerFactory.getLogger(DeadlockTest.class); +public class Deadlock_Tapp { + private static Logger s_logger = LoggerFactory.getLogger(Deadlock_Tapp.class); public static void main(String[] args) throws Exception { s_logger.debug("Starting test."); Copied: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatOriginal_tzest.java (from r2298, /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/TestDateFormatOriginal.java) ============================================================================== --- /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/TestDateFormatOriginal.java (original) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatOriginal_tzest.java Sun Jun 21 17:33:13 2009 @@ -11,7 +11,7 @@ import org.joda.time.format.DateTimeFormat; import org.joda.time.DateTime; -public class TestDateFormatOriginal extends TestCase { +public class DateFormatOriginal_tzest extends TestCase { public static final String ISO8601_PATTERN = "yyyy-MM-dd HH:mm:ss,SSS"; static final long NANOS_IN_ONE_SEC = 1000 * 1000 * 1000L; @@ -21,7 +21,7 @@ * @param testName * name of the test case */ - public TestDateFormatOriginal(String testName) { + public DateFormatOriginal_tzest(String testName) { super(testName); } @@ -29,7 +29,7 @@ * @return the suite of tests being tested */ public static Test suite() { - return new TestSuite(TestDateFormatOriginal.class); + return new TestSuite(DateFormatOriginal_tzest.class); } public static void main(String[] args) { Copied: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatPerf_Tapp.java (from r2298, /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatPerfTest.java) ============================================================================== --- /logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatPerfTest.java (original) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic36/DateFormatPerf_Tapp.java Sun Jun 21 17:33:13 2009 @@ -6,7 +6,7 @@ import org.joda.time.format.DateTimeFormat; import org.joda.time.format.DateTimeFormatter; -public class DateFormatPerfTest { +public class DateFormatPerf_Tapp { public static final String ISO8601_PATTERN = "yyyy-MM-dd HH:mm:ss,SSS"; static final long NANOS_IN_ONE_SEC = 1000 * 1000 * 1000L;

1 0

svn commit: r2298 - in logback-demo/trunk/src/main: java/ch/qos/logback/demo java/ch/qos/logback/demo/login java/ch/qos/logback/demo/prime resources resources/parts webapp/WEB-INF
by noreply.ceki＠qos.ch 21 Jun '09

21 Jun '09

Author: ceki Date: Sun Jun 21 16:56:45 2009 New Revision: 2298 Added: logback-demo/trunk/src/main/java/ch/qos/logback/demo/UserServletFilter.java Modified: logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java logback-demo/trunk/src/main/resources/logback.xml logback-demo/trunk/src/main/resources/parts/sifting.xml logback-demo/trunk/src/main/webapp/WEB-INF/web.xml Log: - update the demo Added: logback-demo/trunk/src/main/java/ch/qos/logback/demo/UserServletFilter.java ============================================================================== --- (empty file) +++ logback-demo/trunk/src/main/java/ch/qos/logback/demo/UserServletFilter.java Sun Jun 21 16:56:45 2009 @@ -0,0 +1,63 @@ +package ch.qos.logback.demo; + +import java.io.IOException; +import java.security.Principal; + +import javax.servlet.Filter; +import javax.servlet.FilterChain; +import javax.servlet.FilterConfig; +import javax.servlet.ServletException; +import javax.servlet.ServletRequest; +import javax.servlet.ServletResponse; +import javax.servlet.http.HttpServletRequest; +import javax.servlet.http.HttpSession; + +import org.slf4j.MDC; + +public class UserServletFilter implements Filter { + + boolean userRegistered = false; + + public void destroy() { + } + + public void doFilter(ServletRequest request, ServletResponse response, + + FilterChain chain) throws IOException, ServletException { + + HttpServletRequest req = (HttpServletRequest) request; + Principal principal = req.getUserPrincipal(); + // Please note that we could have also used a cookie to + // retreive the user name + + if (principal != null) { + String username = principal.getName(); + registerUsername(username); + } else { + HttpSession session = req.getSession(); + String username = (String) session + .getAttribute(Constants.USERID_SESSION_KEY); + registerUsername(username); + } + + try { + chain.doFilter(request, response); + } finally { + if (userRegistered) { + MDC.remove(Constants.USERID_MDC_KEY); + } + } + } + + public void init(FilterConfig arg0) throws ServletException { + } + + private void registerUsername(String username) { + System.out.println("in registerUsername username="+username); + if (username != null && username.trim().length() > 0) { + MDC.put(Constants.USERID_MDC_KEY, username); + userRegistered = true; + } + } + +} Modified: logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java ============================================================================== --- logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java (original) +++ logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java Sun Jun 21 16:56:45 2009 @@ -29,7 +29,6 @@ MDC.put(Constants.USERID_MDC_KEY, username); logger.info("Login: " + username + " just logged in."); request.getSession().setAttribute(Constants.USERID_SESSION_KEY, username); - request.setAttribute("a", username); } } Modified: logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java ============================================================================== --- logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java (original) +++ logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java Sun Jun 21 16:56:45 2009 @@ -7,6 +7,7 @@ import org.apache.struts.action.ActionMapping; import org.slf4j.Logger; import org.slf4j.LoggerFactory; +import org.slf4j.MDC; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @@ -26,6 +27,9 @@ if(number == 99) { logger.info("99 is not a valid value", new Exception("99 is invalid")); } + + System.out.println("*** userid="+MDC.get(Constants.USERID_MDC_KEY)); + NumberCruncher nc = new NumberCruncherImpl(); Long start = System.currentTimeMillis(); Long[] result = nc.factor(number); Modified: logback-demo/trunk/src/main/resources/logback.xml ============================================================================== --- logback-demo/trunk/src/main/resources/logback.xml (original) +++ logback-demo/trunk/src/main/resources/logback.xml Sun Jun 21 16:56:45 2009 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="UTF-8" ?> - + <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> @@ -35,7 +35,7 @@ </appender> --> -  +  <appender name="CYCLIC" class="ch.qos.logback.core.read.CyclicBufferAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> @@ -53,13 +53,13 @@ -  <turboFilter class="ch.qos.logback.classic.turbo.MDCFilter"> <MDCKey>userid</MDCKey> <Value>sebastien</Value> <OnMatch>ACCEPT</OnMatch> </turboFilter> - --> +  <jmxConfigurator /> - <appender name="SIFT" - class="ch.qos.logback.classic.sift.SiftingAppender"> - <discriminator> - <Key>userid</Key> - <DefaultValue>unknown</DefaultValue> - </discriminator> - <sift> - <appender name="FILE-${userid}" - class="ch.qos.logback.core.FileAppender"> - <File>${userid}.log</File> - <Append>false</Append> - <layout> - <Pattern> - %d [%thread] %-55(%-5level %10mdc %logger{35}) - %msg%n - </Pattern> - </layout> - </appender> - </sift> - </appender> <root level="${lb_level:-ERROR}"> <appender-ref ref="STDOUT" /> - <appender-ref ref="SIFT" /> - <appender-ref ref="CYCLIC" /> + <appender-ref ref="FILE" /> + <appender-ref ref="CYCLIC" /> </root> </configuration> Modified: logback-demo/trunk/src/main/resources/parts/sifting.xml ============================================================================== --- logback-demo/trunk/src/main/resources/parts/sifting.xml (original) +++ logback-demo/trunk/src/main/resources/parts/sifting.xml Sun Jun 21 16:56:45 2009 @@ -17,4 +17,3 @@ </appender> </sift> </appender> - Modified: logback-demo/trunk/src/main/webapp/WEB-INF/web.xml ============================================================================== --- logback-demo/trunk/src/main/webapp/WEB-INF/web.xml (original) +++ logback-demo/trunk/src/main/webapp/WEB-INF/web.xml Sun Jun 21 16:56:45 2009 @@ -5,6 +5,19 @@ <display-name>logback-demo</display-name> + <filter> + <filter-name>mdc_filter</filter-name> + <filter-class> + ch.qos.logback.demo.UserServletFilter + </filter-class> + </filter> + <filter-mapping> + <filter-name>mdc_filter</filter-name> + <url-pattern>/*</url-pattern> + </filter-mapping> + + +  <env-entry> <description>JNDI logging context for this app</description>

1 0

[JIRA] Created: (LBGENERAL-30) logback fails to initialise when loaded from bootstrap classpath
by Henric Larsson (JIRA) 18 Jun '09

18 Jun '09

logback fails to initialise when loaded from bootstrap classpath ---------------------------------------------------------------- Key: LBGENERAL-30 URL: http://jira.qos.ch/browse/LBGENERAL-30 Project: logback-general Issue Type: Bug Affects Versions: 0.9.14, 0.9.15 Reporter: Henric Larsson Assignee: Logback dev list Attachments: classloader.patch When logback is put in the endorsed library path of the jdk, it fails to initialise because the getClassLoader() call returns null in a couple of places. Returning null is expected when the classloader is the bootstrap classloader, as is the case when logback is loaded from the endorsed directory. Here's a snippet from the sun jdk javadoc for Class.getClassLoader() "Returns the class loader for the class. Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader." I'm using jacorb 2.3.1, which uses slf4j-api 1.5.6. Jacorb is required to be in the endorsed lib to work, and hence any logging implementation has to go there too. I patched my logback instance to return the system classloader when the null classloader is encounterd. Attaching patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3

svn commit: r2297 - in logback/trunk: logback-classic/src/main/java/ch/qos/logback/classic/util logback-core/src/main/java/ch/qos/logback/core/util
by noreply.ceki＠qos.ch 18 Jun '09

18 Jun '09

Author: ceki Date: Thu Jun 18 18:10:04 2009 New Revision: 2297 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java Log: Fixing LBCORE-100 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java Thu Jun 18 18:10:04 2009 @@ -80,7 +80,7 @@ } public URL findURLOfDefaultConfigurationFile(boolean updateStatus) { - ClassLoader myClassLoader = this.getClass().getClassLoader(); + ClassLoader myClassLoader = Loader.getClassLoaderOfObject(this); URL url = findConfigFileURLFromSystemProperties(myClassLoader, updateStatus); if (url != null) { return url; Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java Thu Jun 18 18:10:04 2009 @@ -83,7 +83,7 @@ * @return */ public static URL getResourceBySelfClassLoader(String resource) { - return getResource(resource, Loader.class.getClassLoader()); + return getResource(resource, getClassLoaderOfClass(Loader.class)); } // private static URL getResourceByTCL(String resource) { @@ -103,11 +103,41 @@ @SuppressWarnings("unchecked") public static Class loadClass(String clazz, Context context) throws ClassNotFoundException { - ClassLoader cl = context.getClass().getClassLoader(); + ClassLoader cl = getClassLoaderOfObject(context); return cl.loadClass(clazz); } /** + * Get the class loader of the object passed as argument. Return the system + * class loader if appropriate. + * + * @param o + * @return + */ + public static ClassLoader getClassLoaderOfObject(Object o) { + if (o == null) { + throw new NullPointerException("Argument cannot be null"); + } + return getClassLoaderOfClass(o.getClass()); + } + + /** + * Return the class loader which loaded the class passed as argument. Return + * the system class loader if appropriate. + * + * @param clazz + * @return + */ + public static ClassLoader getClassLoaderOfClass(Class clazz) { + ClassLoader cl = clazz.getClassLoader(); + if (cl == null) { + return ClassLoader.getSystemClassLoader(); + } else { + return cl; + } + } + + /** * If running under JDK 1.2 load the specified class using the * <code>Thread</code> <code>contextClassLoader</code> if that fails try * Class.forname. Under JDK 1.1 only Class.forName is used. Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java Thu Jun 18 18:10:04 2009 @@ -9,7 +9,6 @@ */ package ch.qos.logback.core.util; - import java.util.Properties; import ch.qos.logback.core.Context; @@ -22,11 +21,12 @@ public class OptionHelper { public static Object instantiateByClassName(String className, - Class superClass, Context context) throws IncompatibleClassException, DynamicClassLoadingException { - ClassLoader classLoader = context.getClass().getClassLoader(); + Class superClass, Context context) throws IncompatibleClassException, + DynamicClassLoadingException { + ClassLoader classLoader = Loader.getClassLoaderOfObject(context); return instantiateByClassName(className, superClass, classLoader); } - + @SuppressWarnings("unchecked") public static Object instantiateByClassName(String className, Class superClass, ClassLoader classLoader) @@ -74,57 +74,54 @@ final static int DELIM_START_LEN = 2; final static int DELIM_STOP_LEN = 1; final static String _IS_UNDEFINED = "_IS_UNDEFINED"; - + /** * Perform variable substitution in string <code>val</code> from the values * of keys found in context property map, and if that fails, then in the * system properties. * - * - * The variable substitution delimeters are ${ and }. + * The variable substitution delimeters are ${ and }. * - * - * For example, if the context property map contains a property "key1" set as - * "value1", then the call + * For example, if the context property map contains a property "key1" set + * as "value1", then the call * * <pre> * String s = OptionConverter.substituteVars("Value of key is ${key1}.", context);</pre> + * * will set the variable <code>s</code> to "Value of key is value1.". * - * - * If no value could be found for the specified key in the context map, then - * the system properties are searched, if that fails, then substitution defaults - * to appending "_IS_UNDEFINED" to the key name. - * - * - * For example, if not the context not the system properties contains no value for the key - * "inexistentKey", then the call + * If no value could be found for the specified key in the context map, + * then the system properties are searched, if that fails, then substitution + * defaults to appending "_IS_UNDEFINED" to the key name. + * + * For example, if not the context not the system properties contains no + * value for the key "inexistentKey", then the call * * <pre> * String s = OptionConverter.subsVars( * "Value of inexistentKey is [${inexistentKey}]", context);</pre> - * will set <code>s</code> to "Value of inexistentKey is [inexistentKey_IS_UNDEFINED]". * - * - * Nevertheless, it is possible to specify a default substitution value using - * the ":-" operator. For example, the call + * will set <code>s</code> to "Value of inexistentKey is + * [inexistentKey_IS_UNDEFINED]". + * + * Nevertheless, it is possible to specify a default substitution value + * using the ":-" operator. For example, the call * * <pre> * String s = OptionConverter.subsVars("Value of key is [${key2:-val2}]", context);</pre> + * * will set <code>s</code> to "Value of key is [val2]" even if the "key2" * property is not set. * - * - * An {@link java.lang.IllegalArgumentException} is thrown if <code>val</code> - * contains a start delimeter "${" which is not balanced by a stop delimeter - * "}". - * - + * An {@link java.lang.IllegalArgumentException} is thrown if + * <code>val</code> contains a start delimeter "${" which is not balanced by + * a stop delimeter "}". + * * * @param val - * The string on which variable substitution is performed. + * The string on which variable substitution is performed. * @throws IllegalArgumentException - * if <code>val</code> is malformed. + * if <code>val</code> is malformed. */ public static String substVars(String val, PropertyContainer pc) { @@ -191,7 +188,7 @@ sbuf.append(recursiveReplacement); } else { // if we could not find a replacement, then signal the error - sbuf.append(key+"_IS_UNDEFINED"); + sbuf.append(key + "_IS_UNDEFINED"); } i = k + DELIM_STOP_LEN; @@ -205,9 +202,9 @@ * {@link SecurityException} is absorbed. * * @param key - * The key to search for. + * The key to search for. * @param def - * The default value to return. + * The default value to return. * @return the string value of the system property, or the default value if * there is no property with that key. */ @@ -224,8 +221,8 @@ * {@link SecurityException} is absorbed. * * @param key - * The key to search for. - + * The key to search for. + * * @return the string value of the system property. */ public static String getSystemProperty(String key) { @@ -235,6 +232,7 @@ return null; } } + /** * Very similar to {@link System#getProperties()} except that the * {@link SecurityException} is absorbed. @@ -248,7 +246,7 @@ return new Properties(); } } - + static public String[] extractDefaultReplacement(String key) { String[] result = new String[2]; result[0] = key; @@ -265,8 +263,7 @@ * <code>value</code> is "false", then <code>true</code> is returned. * Otherwise, <code>default</code> is returned. * - * - * Case of value is unimportant. + * Case of value is unimportant. */ public static boolean toBoolean(String value, boolean dEfault) { if (value == null) {

1 0

[JIRA] Commented: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Ceki Gulcu (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBCLASSIC-36: ------------------------------------- Right. The working assumption here is that the scope of synchronization will be reduced in future logback versions. > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip, DoubleCheckedLocking.patch > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0