This is the general process I follow when it is time for a release:
1. Look through the outstanding PRs and determine if there are any I can easily
address.
2. Look through the Jira issues and determine if there are any that are very
serious or are very easy to remedy.
3. After working through th
Hello Piotr,
> Piotr P. Karwasz hat am 29.08.2022 20:03 CEST
> geschrieben:
> The next release (2.19.0) will require updating our Log4j2 -> SLF4J
> and SLF4J -> Log4j2 bridges to SLF4J 2.0. If that is also a blocker
> for Wildfly we'll probably manage to release 2.19.0 before your next
> Wildfly
Hi Boris,
On Tue, 23 Aug 2022 at 09:37, Boris Unckel wrote:
> LOG4J2-3579 is as blocker to integrate 2.18.0 in WildFly, would it be
> possible to release 2.18.1 soon? Could you provide a tag for 2.18.1 in git,
> please? 2.18.0 has only be released to Maven Central, without tag.
The release pro
Hello,
I have a small HelloWorld to test the issue.
https://github.com/apache/logging-log4j2/pull/1008 works with it, the
privileges are obtained from the caller, both in a positive (caller is the
appserver) and a negative (caller is the app) way.
LOG4J2-3579 is as blocker to integrate 2.18.0
Hi Ralph,
On Mon, 22 Aug 2022 at 09:50, Ralph Goers wrote:
> It looks to me that the issue in 2.18.0 is that ServiceLoaderUtil is
> accessing ServiceLoader via a MethodHandle and that must be requiring the
> SecurityManager. We are using MethodHandlers so that it will work properly in
> a JPMS
I we don’t have permission to use ServiceLoader Log4j will simply fail to
initialize with anything other than SimpleLoggerContextFactory (i.e. - nothing
in log4j-core will work).
It looks to me that the issue in 2.18.0 is that ServiceLoaderUtil is accessing
ServiceLoader via a MethodHandle and
Fixing semantics of running with a SecurityManager in the 2.x branch makes
perfect sense. In 3.x, we might be able to relax that type of code as it’s
mostly module related security boundaries we need to continue supporting.
—
Matt Sicker
> On Aug 21, 2022, at 11:32, . . wrote:
>
> Hello all,
Hello all,
thanks Piotr to take care for the topic. One thing to consider:
> The environment and system properties sources are protected by internal Java
> security checks,...
Unfortunately not after applying the fix: PropertiesUtil[1] loads all the
services which provide a PropertySource ins
Side note: The SecurityManager will eventually go away, which might not
matter for us for a long time!
See https://openjdk.org/jeps/411
Gary
On Sun, Aug 21, 2022 at 8:12 AM Piotr P. Karwasz
wrote:
> Hello,
>
> As noticed by Boris Unckel in LOG4J2-3579[1], there are some issues
> when running Lo
