unable to build from source

[Joseph Tsai]

Hi everyone,

I forked and cloned the project from GitHub
. And spent the past couple of
hours trying to build from source with mvn install.

It is failing with errors saying "class file has wrong version 55.0, should
be 53.0" for "bad class file: /modules/java.base/java/util/EnumSet.class",
which I think it means I probably need to find a Java 9 to install and
build the project with? But since Java 9 was discontinued, I haven't been
able to find an Oracle nor an OpenJDK version to install.

I have attached an output txt file for maven install and my current maven
toolchain.xml if it helps clarifying what I might have been doing wrong.

Thanks,
Joseph
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective 
model for org.apache.logging.log4j:log4j-jmx-gui:jar:3.0.0-SNAPSHOT
[WARNING] 'dependencies.dependency.systemPath' for 
com.sun:jconsole:jar refers to a non-existing file 
/usr/lib/jvm/java-11-oracle/../lib/jconsole.jar. Please verify that you run 
Maven using a JDK and not just a JRE. @ line 196, column 23
[WARNING] 
[WARNING] Some problems were encountered while building the effective 
model for 
org.apache.logging.log4j.samples:log4j-spring-cloud-config-sample-server:jar:3.0.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for 
com.github.spotbugs:spotbugs-maven-plugin is missing. @ line 140, column 15
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they 
threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer 
support building such malformed projects.
[WARNING] 
[INFO] 

[INFO] Reactor Build Order:
[INFO] 
[INFO] Apache Log4j 2 
[pom]
[INFO] Apache Log4j API Java 9 support
[pom]
[INFO] Apache Log4j API   
[jar]
[INFO] Apache Log4j Plugins Module support
[pom]
[INFO] Apache Log4j Plugins   
[jar]
[INFO] Apache Log4j Core Java 9 support   
[pom]
[INFO] Apache Log4j Core  
[jar]
[INFO] Apache Log4j Layout for Jackson
[jar]
[INFO] Apache Log4j Layout for Jackson JSON   
[jar]
[INFO] Apache Log4j 1.x Compatibility API 
[jar]
[INFO] Apache Log4j Layout for Jackson XML
[jar]
[INFO] Apache Log4j Layout for Jackson YAML   
[jar]
[INFO] Apache Log4j Layout for JSON template  
[jar]
[INFO] Apache Log4j Core Integration Tests
[jar]
[INFO] Apache Log4j to SLF4J Adapter  
[jar]
[INFO] Apache Log4j SLF4J Binding 
[jar]
[INFO] Apache Log4j SLF4J 1.8+ Binding
[jar]
[INFO] Apache Log4j Commons Logging Bridge
[jar]
[INFO] Apache Log4j CSV   
[jar]
[INFO] Apache Log4j Flume Bridge  
[jar]
[INFO] Apache Log4j Web   
[jar]
[INFO] Apache Log4j Tag Library   
[jar]
[INFO] Apache Log4j JMX GUI   
[jar]
[INFO] Apache Log4j Samples   
[pom]
[INFO] Apache Log4j Samples: Flume - Common   
[jar]
[INFO] Apache Log4j Samples: Flume - Remote   
[war]
[INFO] Apache Log4j Samples: Flume - Embedded 
[war]
[INFO] Apache Log4j Samples: Configuration
[jar]
[INFO] Apache Log4j Samples: LoggerProperties 
[jar]
[INFO] Apache Log4j BOM   
[pom]
[INFO] Apache Log4j JDBC  
[jar]
[INFO] Apache Log4j JDBC DBCP 2   
[jar]
[INFO] Apache Log4j JPA   
[jar]
[INFO] Apache Log4j Jer

Re: unable to build from source

[Volkan Yazıcı]

Hello Joseph,

You need to have both JDK 8 and 11 installed and configured in your
toolchains.xml file. For reference, you can check how we do it in GitHub
Actions workflow: maven.yml

and maven-toolchains.xml
.
Once this is done, *./mvnw package -DskipTests* should succeed. Let us know
if you encounter any further troubles.

Kind regards.

On Tue, Dec 8, 2020 at 12:22 PM Joseph Tsai  wrote:

> Hi everyone,
>
> I forked and cloned the project from GitHub
> . And spent the past couple of
> hours trying to build from source with mvn install.
>
> It is failing with errors saying "class file has wrong version 55.0,
> should be 53.0" for "bad class file:
> /modules/java.base/java/util/EnumSet.class", which I think it means I
> probably need to find a Java 9 to install and build the project with? But
> since Java 9 was discontinued, I haven't been able to find an Oracle nor an
> OpenJDK version to install.
>
> I have attached an output txt file for maven install and my current maven
> toolchain.xml if it helps clarifying what I might have been doing wrong.
>
> Thanks,
> Joseph
>

Re: unable to build from source

[Joseph Tsai]

Hi Volkan,

I just installed both JDK8 and 11 and tried to do mvn clean install. The
same error persists, and I think it's looking at my default Java
installation?
Running "sudo update-alternatives --config java" shows the following:
[image: image.png]
Currently it is defaulted to Java15, and everytime I change the default
Java the wrong version circled in blue changes.
[image: image.png]
I also looked up what version 53 is, it is apparently Java9?

My questions are:

   - Am I supposed to update the default Java to Java11 or 8? If not, is
   simply putting in more toolchain entries under toolchains.xml is enough?
   - How is Java9 related to the error message, if at all?
   - Honestly I am not sure what I'm supposed to do with the maven.yml
   example you linked...

I have also attached a new copy of my updated toolchains.xml. A bit of
information on my environment, I'm using Windows and do development through
WSL2.0.

Thanks once again,
Joseph

On Tue, 8 Dec 2020 at 22:44, Volkan Yazıcı  wrote:

> Hello Joseph,
>
> You need to have both JDK 8 and 11 installed and configured in your
> toolchains.xml file. For reference, you can check how we do it in GitHub
> Actions workflow: maven.yml
> <
> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml
> >
> and maven-toolchains.xml
> <
> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven-toolchains.xml
> >.
> Once this is done, *./mvnw package -DskipTests* should succeed. Let us know
> if you encounter any further troubles.
>
> Kind regards.
>
> On Tue, Dec 8, 2020 at 12:22 PM Joseph Tsai  wrote:
>
> > Hi everyone,
> >
> > I forked and cloned the project from GitHub
> > . And spent the past couple of
> > hours trying to build from source with mvn install.
> >
> > It is failing with errors saying "class file has wrong version 55.0,
> > should be 53.0" for "bad class file:
> > /modules/java.base/java/util/EnumSet.class", which I think it means I
> > probably need to find a Java 9 to install and build the project with? But
> > since Java 9 was discontinued, I haven't been able to find an Oracle nor
> an
> > OpenJDK version to install.
> >
> > I have attached an output txt file for maven install and my current maven
> > toolchain.xml if it helps clarifying what I might have been doing wrong.
> >
> > Thanks,
> > Joseph
> >
>


	
		jdk

			1.8


			/usr/lib/jvm/java-8-openjdk-amd64


	
jdk

11


			/usr/lib/jvm/java-11-openjdk-amd64
		
	

Re: unable to build from source

[Volkan Yazıcı]

Would you mind changing the default JDK you start *mvnw* to version 8 and
retrying via *./mvnw clean package -DskipTests*, please? (Here *clean* goal
is necessary for removing the class files compiled earlier with the wrong
JDK.)
[Sorry for the short answer, struggling with my day-job in the meantime.]

On Tue, Dec 8, 2020 at 3:02 PM Joseph Tsai  wrote:

> Hi Volkan,
>
> I just installed both JDK8 and 11 and tried to do mvn clean install. The
> same error persists, and I think it's looking at my default Java
> installation?
> Running "sudo update-alternatives --config java" shows the following:
> [image: image.png]
> Currently it is defaulted to Java15, and everytime I change the default
> Java the wrong version circled in blue changes.
> [image: image.png]
> I also looked up what version 53 is, it is apparently Java9?
>
> My questions are:
>
>- Am I supposed to update the default Java to Java11 or 8? If not, is
>simply putting in more toolchain entries under toolchains.xml is enough?
>- How is Java9 related to the error message, if at all?
>- Honestly I am not sure what I'm supposed to do with the maven.yml
>example you linked...
>
> I have also attached a new copy of my updated toolchains.xml. A bit of
> information on my environment, I'm using Windows and do development through
> WSL2.0.
>
> Thanks once again,
> Joseph
>
> On Tue, 8 Dec 2020 at 22:44, Volkan Yazıcı 
> wrote:
>
>> Hello Joseph,
>>
>> You need to have both JDK 8 and 11 installed and configured in your
>> toolchains.xml file. For reference, you can check how we do it in GitHub
>> Actions workflow: maven.yml
>> <
>> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml
>> >
>> and maven-toolchains.xml
>> <
>> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven-toolchains.xml
>> >.
>> Once this is done, *./mvnw package -DskipTests* should succeed. Let us
>> know
>> if you encounter any further troubles.
>>
>> Kind regards.
>>
>> On Tue, Dec 8, 2020 at 12:22 PM Joseph Tsai  wrote:
>>
>> > Hi everyone,
>> >
>> > I forked and cloned the project from GitHub
>> > . And spent the past couple
>> of
>> > hours trying to build from source with mvn install.
>> >
>> > It is failing with errors saying "class file has wrong version 55.0,
>> > should be 53.0" for "bad class file:
>> > /modules/java.base/java/util/EnumSet.class", which I think it means I
>> > probably need to find a Java 9 to install and build the project with?
>> But
>> > since Java 9 was discontinued, I haven't been able to find an Oracle
>> nor an
>> > OpenJDK version to install.
>> >
>> > I have attached an output txt file for maven install and my current
>> maven
>> > toolchain.xml if it helps clarifying what I might have been doing wrong.
>> >
>> > Thanks,
>> > Joseph
>> >
>>
>

Re: unable to build from source

[Matt Sicker]

The full build isn't compatible with Java 11 yet, so you need both 8 and 11
configured in a toolchains.xml config. Then you need to use Java 8 as the
default JVM (or at least the contents of JAVA_HOME), and the build will
switch to higher version compilers for the modules that require it.
Ideally, the build would be updated to simplify this, but it's a fairly
difficult problem as it's still a relatively new area in Maven with
multiple alternatives to how to support it.

On Tue, 8 Dec 2020 at 08:13, Volkan Yazıcı  wrote:

> Would you mind changing the default JDK you start *mvnw* to version 8 and
> retrying via *./mvnw clean package -DskipTests*, please? (Here *clean*
> goal is necessary for removing the class files compiled earlier with the
> wrong JDK.)
> [Sorry for the short answer, struggling with my day-job in the meantime.]
>
> On Tue, Dec 8, 2020 at 3:02 PM Joseph Tsai  wrote:
>
>> Hi Volkan,
>>
>> I just installed both JDK8 and 11 and tried to do mvn clean install. The
>> same error persists, and I think it's looking at my default Java
>> installation?
>> Running "sudo update-alternatives --config java" shows the following:
>> [image: image.png]
>> Currently it is defaulted to Java15, and everytime I change the default
>> Java the wrong version circled in blue changes.
>> [image: image.png]
>> I also looked up what version 53 is, it is apparently Java9?
>>
>> My questions are:
>>
>>- Am I supposed to update the default Java to Java11 or 8? If not, is
>>simply putting in more toolchain entries under toolchains.xml is enough?
>>- How is Java9 related to the error message, if at all?
>>- Honestly I am not sure what I'm supposed to do with the maven.yml
>>example you linked...
>>
>> I have also attached a new copy of my updated toolchains.xml. A bit of
>> information on my environment, I'm using Windows and do development through
>> WSL2.0.
>>
>> Thanks once again,
>> Joseph
>>
>> On Tue, 8 Dec 2020 at 22:44, Volkan Yazıcı 
>> wrote:
>>
>>> Hello Joseph,
>>>
>>> You need to have both JDK 8 and 11 installed and configured in your
>>> toolchains.xml file. For reference, you can check how we do it in GitHub
>>> Actions workflow: maven.yml
>>> <
>>> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml
>>> >
>>> and maven-toolchains.xml
>>> <
>>> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven-toolchains.xml
>>> >.
>>> Once this is done, *./mvnw package -DskipTests* should succeed. Let us
>>> know
>>> if you encounter any further troubles.
>>>
>>> Kind regards.
>>>
>>> On Tue, Dec 8, 2020 at 12:22 PM Joseph Tsai  wrote:
>>>
>>> > Hi everyone,
>>> >
>>> > I forked and cloned the project from GitHub
>>> > . And spent the past couple
>>> of
>>> > hours trying to build from source with mvn install.
>>> >
>>> > It is failing with errors saying "class file has wrong version 55.0,
>>> > should be 53.0" for "bad class file:
>>> > /modules/java.base/java/util/EnumSet.class", which I think it means I
>>> > probably need to find a Java 9 to install and build the project with?
>>> But
>>> > since Java 9 was discontinued, I haven't been able to find an Oracle
>>> nor an
>>> > OpenJDK version to install.
>>> >
>>> > I have attached an output txt file for maven install and my current
>>> maven
>>> > toolchain.xml if it helps clarifying what I might have been doing
>>> wrong.
>>> >
>>> > Thanks,
>>> > Joseph
>>> >
>>>
>>

Re: LOG4J2-2965 deadlock brainstorming

[Matt Sicker]

As one of the biggest tinkerers in log4j-jul myself, I have to say
that sounds like a decent idea. I haven't revisited my assumptions in
that module in a long time as I haven't had to integrate with JUL
lately (at least outside Jenkins, but there I'm using log4j-audit in a
plugin which doesn't interact with the JUL config), so I have no
objections to that.

On Sun, 6 Dec 2020 at 17:16, Carter Kozak  wrote:
>
> Hi Friends,
>
> I've been thinking about ways that we can solve LOG4J2-2965 which is a 
> deadlock between JUL init and log4j init, both of which use synchronization. 
> The crux of the issue is that JUL LogManager uses a synchronized block to 
> initialize, which requests log4j-core initialization and log4j-core attempts 
> to initialize the JUL LogManager if Disruptor is used. If One thread attempts 
> to initialize JUL directly while another begins to initialize log4j via a 
> non-jul path, we may deadlock. I have an example stack trace in the ticket.
>
> This problem is specific to JUL due to the synchronization incurred while 
> initializing our LogManager via java.util.logging.LogManager, so we could 
> update our JUL implementation to lazily connect jul logger instances to the 
> log4j framework. Instead of reaching out to the loggercontext when JUL 
> loggers are requested, we can initialize the delegate log4j components upon 
> the first interaction rather than when the logger is requested, decoupling 
> JUL LogManager initialization from log4j init so it behaves like other 
> bindings. We would need to be careful to track the original caller data to 
> avoid associating JUL loggers with incorrect log4j contexts.
>
> What do you think? Any alternative ideas or suggestions?
>
> Thanks,
> Carter

Re: unable to build from source

[Ralph Goers]

You are making progress! I saw those same errors in one of our automated builds 
the other day. I am not sure what the problem is but haven’t looked into it yet.

Ralph

> On Dec 8, 2020, at 9:23 AM, Joseph Tsai  wrote:
> 
> I kinda inferred that from reading the mvnw script when Volkan directed me to 
> run command. So I exported JAVA_HOME=[path/to/my/Java8] into my .bashrc and 
> I'm not failing the same thing anymore.
> 
> But I'm still getting errors, this time it is failing some unit tests from 
> the surefire plugin. I tried to fix it but I couldn't.
> 
> 
> 
> From reading some 
> 
>  StackOverflow 
> 
>  posts, it seems to have something to do with the surefire plugin version 
> number? I tried to downgrade it to some lower versions but it didn't work.
> 
> I have also attached a zip of the surefire reports.
> 
> Thanks,
> 
> 
> On Wed, 9 Dec 2020 at 02:37, Matt Sicker  > wrote:
> The full build isn't compatible with Java 11 yet, so you need both 8 and 11
> configured in a toolchains.xml config. Then you need to use Java 8 as the
> default JVM (or at least the contents of JAVA_HOME), and the build will
> switch to higher version compilers for the modules that require it.
> Ideally, the build would be updated to simplify this, but it's a fairly
> difficult problem as it's still a relatively new area in Maven with
> multiple alternatives to how to support it.
> 
> On Tue, 8 Dec 2020 at 08:13, Volkan Yazıcı  > wrote:
> 
> > Would you mind changing the default JDK you start *mvnw* to version 8 and
> > retrying via *./mvnw clean package -DskipTests*, please? (Here *clean*
> > goal is necessary for removing the class files compiled earlier with the
> > wrong JDK.)
> > [Sorry for the short answer, struggling with my day-job in the meantime.]
> >
> > On Tue, Dec 8, 2020 at 3:02 PM Joseph Tsai  > > wrote:
> >
> >> Hi Volkan,
> >>
> >> I just installed both JDK8 and 11 and tried to do mvn clean install. The
> >> same error persists, and I think it's looking at my default Java
> >> installation?
> >> Running "sudo update-alternatives --config java" shows the following:
> >> [image: image.png]
> >> Currently it is defaulted to Java15, and everytime I change the default
> >> Java the wrong version circled in blue changes.
> >> [image: image.png]
> >> I also looked up what version 53 is, it is apparently Java9?
> >>
> >> My questions are:
> >>
> >>- Am I supposed to update the default Java to Java11 or 8? If not, is
> >>simply putting in more toolchain entries under toolchains.xml is enough?
> >>- How is Java9 related to the error message, if at all?
> >>- Honestly I am not sure what I'm supposed to do with the maven.yml
> >>example you linked...
> >>
> >> I have also attached a new copy of my updated toolchains.xml. A bit of
> >> information on my environment, I'm using Windows and do development through
> >> WSL2.0.
> >>
> >> Thanks once again,
> >> Joseph
> >>
> >> On Tue, 8 Dec 2020 at 22:44, Volkan Yazıcı  >> >
> >> wrote:
> >>
> >>> Hello Joseph,
> >>>
> >>> You need to have both JDK 8 and 11 installed and configured in your
> >>> toolchains.xml file. For reference, you can check how we do it in GitHub
> >>> Actions workflow: maven.yml
> >>> <
> >>> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml
> >>>  
> >>> 
> >>> >
> >>> and maven-toolchains.xml
> >>> <
> >>> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven-toolchains.xml
> >>>  
> >>> 
> >>> >.
> >>> Once this is done, *./mvnw package -DskipTests* should succeed. Let us
> >>> know
> >>> if you encounter any further troubles.
> >>>
> >>> Kind regards.
> >>>
> >>> On Tue, Dec 8, 2020 at 12:22 PM Joseph Tsai  >>> > wrote:
> >>>
> >>> > Hi everyone,
> >>> >
> >>> > I forked and cloned the project from GitHub
> >>> >  >>> > >. And spent the past couple
> >>> of
> >>> > hours trying to build from source with mvn install.
> >>> >
> >>> > It is failing with errors saying "class file has wrong version 55.0,
> >>> > should be 53.0" for "bad class file:
> >>> > /modules/java.base/java/util/EnumSet.class", which I think it means I
> >>> > probably need to find a Java 9 to install and build the project with?
> >>> But
> >>> > since Java 9 was discontinued, I haven't been able to find an Oracle
> >>> nor an
> >>> > OpenJDK version to ins

Re: LOG4J2-2965 deadlock brainstorming

[Remko Popma]

Hi Carter,

I’m not sure if I understand the problem and your proposed solution fully
but it sounds like it may reduce the probability of a deadlock occurring
but not fully eliminate the possibility.

(Without looking at the code, away from pc),
would it be an idea to expose a status (or perhaps we already have a
life-cycle status) that components like JUL can query, perhaps with a
notification (a countdown latch?) so that these components can wait and
continue initialization when the core is completely initialized?

Remko


On Mon, Dec 7, 2020 at 8:16 Carter Kozak  wrote:

> Hi Friends,
>
> I've been thinking about ways that we can solve LOG4J2-2965 which is a
> deadlock between JUL init and log4j init, both of which use
> synchronization. The crux of the issue is that JUL LogManager uses a
> synchronized block to initialize, which requests log4j-core initialization
> and log4j-core attempts to initialize the JUL LogManager if Disruptor is
> used. If One thread attempts to initialize JUL directly while another
> begins to initialize log4j via a non-jul path, we may deadlock. I have an
> example stack trace in the ticket.
>
> This problem is specific to JUL due to the synchronization incurred while
> initializing our LogManager via java.util.logging.LogManager, so we could
> update our JUL implementation to lazily connect jul logger instances to the
> log4j framework. Instead of reaching out to the loggercontext when JUL
> loggers are requested, we can initialize the delegate log4j components upon
> the first interaction rather than when the logger is requested, decoupling
> JUL LogManager initialization from log4j init so it behaves like other
> bindings. We would need to be careful to track the original caller data to
> avoid associating JUL loggers with incorrect log4j contexts.
>
> What do you think? Any alternative ideas or suggestions?
>
> Thanks,
> Carter
>

Re: LOG4J2-2965 deadlock brainstorming

[Carter Kozak]

Hi Remko,

I had thought exactly the same thing until I drafted my email, but in doing so 
I came to the realization (hopefully correctly) that the problem is the direct 
result of jul.LogManager synchronizing initialization, so if we can avoid log4j 
initialization within the locked region and defer to a later point, the 
concurrency model will match our other API bindings and should be safe.
I don't think we can provide a mechanism to wait for initialization because JUL 
may be bootstrapped by log4j via disruptor, or it may be the component which 
results in log4j initialization, so I think the solutions which involve waiting 
can also deadlock. The tricky case is when thread logs using JUL an acquires 
the lock while another thread is initializing log4j, but blocks attempting to 
initialize Disruptor classes with static JUL loggers. I have a consistent 
minimal reproducer here: 
https://github.com/apache/logging-log4j2/pull/447

Carter

On Tue, Dec 8, 2020, at 18:44, Remko Popma wrote:
> Hi Carter,
> 
> I’m not sure if I understand the problem and your proposed solution fully
> but it sounds like it may reduce the probability of a deadlock occurring
> but not fully eliminate the possibility.
> 
> (Without looking at the code, away from pc),
> would it be an idea to expose a status (or perhaps we already have a
> life-cycle status) that components like JUL can query, perhaps with a
> notification (a countdown latch?) so that these components can wait and
> continue initialization when the core is completely initialized?
> 
> Remko
> 
> 
> On Mon, Dec 7, 2020 at 8:16 Carter Kozak  wrote:
> 
> > Hi Friends,
> >
> > I've been thinking about ways that we can solve LOG4J2-2965 which is a
> > deadlock between JUL init and log4j init, both of which use
> > synchronization. The crux of the issue is that JUL LogManager uses a
> > synchronized block to initialize, which requests log4j-core initialization
> > and log4j-core attempts to initialize the JUL LogManager if Disruptor is
> > used. If One thread attempts to initialize JUL directly while another
> > begins to initialize log4j via a non-jul path, we may deadlock. I have an
> > example stack trace in the ticket.
> >
> > This problem is specific to JUL due to the synchronization incurred while
> > initializing our LogManager via java.util.logging.LogManager, so we could
> > update our JUL implementation to lazily connect jul logger instances to the
> > log4j framework. Instead of reaching out to the loggercontext when JUL
> > loggers are requested, we can initialize the delegate log4j components upon
> > the first interaction rather than when the logger is requested, decoupling
> > JUL LogManager initialization from log4j init so it behaves like other
> > bindings. We would need to be careful to track the original caller data to
> > avoid associating JUL loggers with incorrect log4j contexts.
> >
> > What do you think? Any alternative ideas or suggestions?
> >
> > Thanks,
> > Carter
> >
> 

Re: unable to build from source

[Joseph Tsai]

I have been trying to figure out why I'm failing the assertion test
[image: image.png]

So far from looking at LocalizedMessage.java
[image: image.png]
I think $locale is always null and therefore $bundle is always null, and
this sets $msgPattern to $myKey which $myKey is just "hello_world". And
eventually the getFormattedMessage() would just chain return
$formattedMessage.

But in ParameterizedMessage.java, $formattedMessage is set to be $buffer's
content
[image: image.png]

And $buffer would get its content from $messagePattern in
ParameterFormatter.java, which is just "hello_world"
[image: image.png]

So I'm getting the fix would be to have $locale != null with some default
value when passed in to getResourceBundle()? I don't know, I could be way
wrong on my whole analysis and the problem is not actually related to what
I think it is at all.


On Wed, 9 Dec 2020 at 03:37, Ralph Goers  wrote:

> You are making progress! I saw those same errors in one of our automated
> builds the other day. I am not sure what the problem is but haven’t looked
> into it yet.
>
> Ralph
>
> > On Dec 8, 2020, at 9:23 AM, Joseph Tsai  wrote:
> >
> > I kinda inferred that from reading the mvnw script when Volkan directed
> me to run command. So I exported JAVA_HOME=[path/to/my/Java8] into my
> .bashrc and I'm not failing the same thing anymore.
> >
> > But I'm still getting errors, this time it is failing some unit tests
> from the surefire plugin. I tried to fix it but I couldn't.
> > 
> > 
> > 
> > From reading some <
> https://stackoverflow.com/questions/36427868/failed-to-execute-goal-org-apache-maven-pluginsmaven-surefire-plugin2-12test/55835974>
> StackOverflow <
> https://stackoverflow.com/questions/46831762/maven-build-and-maven-failsafe-plugin-the-forked-vm-terminated-without-properl>
> posts, it seems to have something to do with the surefire plugin version
> number? I tried to downgrade it to some lower versions but it didn't work.
> >
> > I have also attached a zip of the surefire reports.
> >
> > Thanks,
> >
> >
> > On Wed, 9 Dec 2020 at 02:37, Matt Sicker  boa...@gmail.com>> wrote:
> > The full build isn't compatible with Java 11 yet, so you need both 8 and
> 11
> > configured in a toolchains.xml config. Then you need to use Java 8 as the
> > default JVM (or at least the contents of JAVA_HOME), and the build will
> > switch to higher version compilers for the modules that require it.
> > Ideally, the build would be updated to simplify this, but it's a fairly
> > difficult problem as it's still a relatively new area in Maven with
> > multiple alternatives to how to support it.
> >
> > On Tue, 8 Dec 2020 at 08:13, Volkan Yazıcı  > wrote:
> >
> > > Would you mind changing the default JDK you start *mvnw* to version 8
> and
> > > retrying via *./mvnw clean package -DskipTests*, please? (Here *clean*
> > > goal is necessary for removing the class files compiled earlier with
> the
> > > wrong JDK.)
> > > [Sorry for the short answer, struggling with my day-job in the
> meantime.]
> > >
> > > On Tue, Dec 8, 2020 at 3:02 PM Joseph Tsai  > wrote:
> > >
> > >> Hi Volkan,
> > >>
> > >> I just installed both JDK8 and 11 and tried to do mvn clean install.
> The
> > >> same error persists, and I think it's looking at my default Java
> > >> installation?
> > >> Running "sudo update-alternatives --config java" shows the following:
> > >> [image: image.png]
> > >> Currently it is defaulted to Java15, and everytime I change the
> default
> > >> Java the wrong version circled in blue changes.
> > >> [image: image.png]
> > >> I also looked up what version 53 is, it is apparently Java9?
> > >>
> > >> My questions are:
> > >>
> > >>- Am I supposed to update the default Java to Java11 or 8? If not,
> is
> > >>simply putting in more toolchain entries under toolchains.xml is
> enough?
> > >>- How is Java9 related to the error message, if at all?
> > >>- Honestly I am not sure what I'm supposed to do with the maven.yml
> > >>example you linked...
> > >>
> > >> I have also attached a new copy of my updated toolchains.xml. A bit of
> > >> information on my environment, I'm using Windows and do development
> through
> > >> WSL2.0.
> > >>
> > >> Thanks once again,
> > >> Joseph
> > >>
> > >> On Tue, 8 Dec 2020 at 22:44, Volkan Yazıcı  >
> > >> wrote:
> > >>
> > >>> Hello Joseph,
> > >>>
> > >>> You need to have both JDK 8 and 11 installed and configured in your
> > >>> toolchains.xml file. For reference, you can check how we do it in
> GitHub
> > >>> Actions workflow: maven.yml
> > >>> <
> > >>>
> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml
> <
> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven.yml
> >
> > >>> >
> > >>> and maven-toolchains.xml
> > >>> <
> > >>>
> https://github.com/apache/logging-log4j2/blob/master/.github/workflows/maven-toolchains.xml
> <
> https://gi