commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Lundberg (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LOGGING-35) Logging has a NPE when security prevents property reading
Date Tue, 29 Dec 2009 17:06:29 GMT

     [ https://issues.apache.org/jira/browse/LOGGING-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dennis Lundberg updated LOGGING-35:
-----------------------------------

    Fix Version/s: 1.0.1

> Logging has a NPE when security prevents property reading
> ---------------------------------------------------------
>
>                 Key: LOGGING-35
>                 URL: https://issues.apache.org/jira/browse/LOGGING-35
>             Project: Commons Logging
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: Operating System: All
> Platform: All
>            Reporter: Tim Vernum
>             Fix For: 1.0.1
>
>
> In LogFactoryImpl:
>         // Identify the Log implementation class we will be using
>         String logClassName = null;
>         try {
>   /** Read attributes **/
>   /** Read properties **/
>   /** Look for Log4J **/
>   /** Look for jdk1.4 **/
>   /** Use Default logger **/
>         } catch (SecurityException e) {
>         }
>         // Attempt to load the Log implementation class
>         Class logClass = null;
>         try {
>             logClass = loadClass(logClassName);
>         
> If a SecurityException occurs, then logClassName isn't ever set, and the 
> loadClass
> method throws a NullPointerException.
> What to do?
> a) Throw the SecurityException instead. Better, because then the cause is at 
> least clearer (than the NPE), but probably not what we want.
> b) Have the DefaultLogger setting occur outside of the "try". Better still, but 
> then you loose any chance of getting log4j or jdk1.4, just because you aren't 
> allowed to read system properties.
> c) Only wrap the getProperty calls in the try block. I think this is the best 
> solution, but I'm not sure if any of the other code in there could raise a 
> SecruityException.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message