You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Matt Sicker (JIRA)" <ji...@apache.org> on 2014/04/27 22:00:15 UTC

[jira] [Assigned] (LOG4J2-604) Audit use of ClassLoader, Class.forName, etc.

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

Matt Sicker reassigned LOG4J2-604:
----------------------------------

    Assignee: Matt Sicker

> 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
>            Assignee: 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
(v6.2#6252)

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