[
https://issues.apache.org/jira/browse/LOG4J2-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Harrington updated LOG4J2-756:
------------------------------------
Description:
The PluginManagerPackagesTest runs an embedded JavaCompiler to get the
"FixedStringLayout" class that is needed for the test.
The classpath used by JavaCompiler may or may not have a valid PluginProcessor
available. I assume if it did, it would have placed the Log4j2Plugins.dat
somewhere in a META-INF subdirectory, but instead (for me) it appears in the
current directory, which is log4j-core.
Simple fix is to add "-proc:none" to the compiler options to disable annotation
processing, like this:
{code:java}
// compile generated source
compiler.getTask(null, fileManager, diagnostics, Arrays.asList("-proc:none"),
null, compilationUnits).call();
{code}
This assumes we really don't need the annotation processing for the test. If we
do, then perhaps an explicit classpath needs to be provided to the JavaCompiler
so we know we're getting the expected PluginProcessor (presumably one just
built moments before). And we would want the test to clean up after itself
(remove the DAT file, and probably the compiled classes as well).
was:
The PluginManagerPackagesTest runs an embedded JavaCompiler to get the
"FixedStringLayout" class that is needed for the test.
At this point, the classpath may or may not have a valid PluginProcessor
available. I assume it did, if would have placed the Log4j2Plugins.dat
somewhere in a META-INF subdirectory, but instead (for me) it appears in the
current directory, which is log4j-core.
Simple fix is to add "-proc:none" to the compiler options to disable annotation
processing, like this:
{code:java}
// compile generated source
compiler.getTask(null, fileManager, diagnostics, Arrays.asList("-proc:none"),
null, compilationUnits).call();
{code}
This assumes we really don't need the annotation processing for the test. If we
do, then perhaps an explicit classpath needs to be provided to the JavaCompiler
so we know we're getting the expected PluginProcessor (presumably one just
built moments before). And we would want the test to clean up after itself
(remove the DAT file, and probably the compiled classes as well).
> Stray Log4j2Plugins.dat appears during build
> --------------------------------------------
>
> Key: LOG4J2-756
> URL: https://issues.apache.org/jira/browse/LOG4J2-756
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Reporter: Scott Harrington
> Priority: Trivial
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The PluginManagerPackagesTest runs an embedded JavaCompiler to get the
> "FixedStringLayout" class that is needed for the test.
> The classpath used by JavaCompiler may or may not have a valid
> PluginProcessor available. I assume if it did, it would have placed the
> Log4j2Plugins.dat somewhere in a META-INF subdirectory, but instead (for me)
> it appears in the current directory, which is log4j-core.
> Simple fix is to add "-proc:none" to the compiler options to disable
> annotation processing, like this:
> {code:java}
> // compile generated source
> compiler.getTask(null, fileManager, diagnostics, Arrays.asList("-proc:none"),
> null, compilationUnits).call();
> {code}
> This assumes we really don't need the annotation processing for the test. If
> we do, then perhaps an explicit classpath needs to be provided to the
> JavaCompiler so we know we're getting the expected PluginProcessor
> (presumably one just built moments before). And we would want the test to
> clean up after itself (remove the DAT file, and probably the compiled classes
> as well).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
