logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Sicker (JIRA)" <j...@apache.org>
Subject [jira] [Created] (LOG4J2-604) Audit use of ClassLoader, Class.forName, etc.
Date Tue, 15 Apr 2014 03:03:14 GMT
Matt Sicker created LOG4J2-604:

             Summary: Audit use of ClassLoader, Class.forName, etc.
                 Key: LOG4J2-604
                 URL: https://issues.apache.org/jira/browse/LOG4J2-604
             Project: Log4j 2
          Issue Type: Epic
          Components: API, Core
    Affects Versions: 2.0-rc2
            Reporter: Matt Sicker
            Priority: Blocker

The idiom {{Class.forName}} is almost always a bad idea if it's called without a classloader
to go along with it. The only acceptable place to put it is in something like Loader.loadClass
as a last resort.

To make sure everything works as expected in non-trivial environments (e.g., multiple LoggerContexts
associated to completely different ClassLoaders like in webapps or bundles), all usage of
dynamic class loading should be audited for correctness. The appropriate neighbour class can
be used for getting a class loader in most cases (i.e., another already loaded class that
should be from the same JAR).

I'll try to add some integration tests that create sub-classloaders that isolate contexts
from one another to ensure correctness.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message