Re: Upcoming changes to main for Log4j 3.x

[Piotr P. Karwasz]

Hi Matt,

On Mon, 13 Nov 2023 at 19:18, Matt Sicker  wrote:
> * Removal of legacy OSGi support. We will rely on ServiceLoader and things 
> like SPI Fly or other common OSGi mechanisms for supporting ServiceLoader 
> while deferring lower level OSGi integration to libraries like Pax-Logging.

We must just check if SPI Fly supports weaving code like this:

final MethodHandle loadHandle = lookup.findStatic(ServiceLoader.class, "load",
MethodType.methodType(ServiceLoader.class, Class.class,
ClassLoader.class));

Otherwise we need to use a simple `ServiceLoader.load(..., ...)`.

Maybe, instead of passing `MethodHandles.Lookup` to
`ServiceLoaderUtil`, we could pass the result of
`ServiceLoader.load(Class)` and get rid of all this JPMS crap?

Piotr

Upcoming changes to main for Log4j 3.x

[Matt Sicker]

After some discussions yesterday about what’s up for 3.0 (notes are somewhere), 
I wanted to share the list of action items I'm planning to implement in main:

* Removal of legacy OSGi support. We will rely on ServiceLoader and things like 
SPI Fly or other common OSGi mechanisms for supporting ServiceLoader while 
deferring lower level OSGi integration to libraries like Pax-Logging.
* Removal of support for SecurityManager. Since Java 21 doesn’t allow for 
specifying a SecurityManager, and considering our anemic support for running 
with one, we thought it would be simpler to deprecate support for this and log 
a warning at startup if a custom SecurityManager is installed.
* Further refactoring in log4j-api/core to better support more context-scoped 
properties (we still have various things relying on static fields for this)

We also talked about upgrading the JavaEE API integrations to all use 
JakartaEE, switching the baseline Java version for 3.0 to be 17 (to match 
Spring Boot 3 et al.), and some other things I can’t recall at the moment. 
These encompassed most of what we wanted to definitely have before 3.0 GA, 
though we also plan to make some regular beta releases. There was also a desire 
to split out all the JakartaEE stuff into its own git repository (SMTP, JMS, 
JDBC, JNDI, JPA, and anything else using JavaEE/JakartaEE libs).

I know that Volkan plans on working on the Recycler API which touches things 
largely in the Layout implementations along with reusable Message and LogEvent 
objects, though this is largely an implementation detail until we expose the 
Recycler API for more general reuse. What else have I missed in this email?

—
Matt Sicker