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