Re: The roadmap to Log4j 3.0.0

[Ralph Goers]

Thank you for that!

Ralph

> On Mar 31, 2022, at 12:53 PM, Piotr P. Karwasz  
> wrote:
> 
> Hello,
> 
> On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz  
> wrote:
>> The `log4j-1.2-api` code seems synchronized between `master` and
>> `release-2.x` up to January 20th. Since part of the desynchronization
>> that occurred afterwards is my fault and some of my changes are built
>> on top of Gary's, I can take care of the cherry-picking. Probably a
>> comparison of the two codes will be necessary at the end.
> 
> This is done: the Log4j 1.2 bridge in `master` is up-to-date with
> `release-2.x`. I hit a couple of bumps in the road, while merging the
> commits, but thanks to Matt everything should be Ok now.
> 
> Piotr

Re: The roadmap to Log4j 3.0.0

[Jochen Wiedmann]

On Tue, Mar 29, 2022 at 9:11 PM Matt Sicker  wrote:
>
> I don’t know if any new javax APIs are defined anymore. There’s JakartaEE for 
> the new APIs, though that’s through Eclipse at this point I think.
>
> Also, for a generic plugin library, there are some things I’d likely do 
> slightly differently than in here since backward compatibility wouldn’t be 
> relevant. Though that behavior itself could potentially be customizable.

As for that, I think that 3.0 would be a good opportunity to migrate
from javax to jakarta, if necessary.

As Core should only depend on java.base, it won't be affected. And, as
for plugins: All, that users need to do, would be to clone a plugin,
and change jakarta to javax in the sources. No duplicate maintenance
for us.

Jochen

Re: The roadmap to Log4j 3.0.0

[Gary Gregory]

Yes, thank you Piotr, it's tremendously helpful :-)

Gary

On Fri, Apr 1, 2022, 03:28 Ralph Goers  wrote:

> Thank you for that!
>
> Ralph
>
> > On Mar 31, 2022, at 12:53 PM, Piotr P. Karwasz 
> wrote:
> >
> > Hello,
> >
> > On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz 
> wrote:
> >> The `log4j-1.2-api` code seems synchronized between `master` and
> >> `release-2.x` up to January 20th. Since part of the desynchronization
> >> that occurred afterwards is my fault and some of my changes are built
> >> on top of Gary's, I can take care of the cherry-picking. Probably a
> >> comparison of the two codes will be necessary at the end.
> >
> > This is done: the Log4j 1.2 bridge in `master` is up-to-date with
> > `release-2.x`. I hit a couple of bumps in the road, while merging the
> > commits, but thanks to Matt everything should be Ok now.
> >
> > Piotr
>
>

Re: The roadmap to Log4j 3.0.0

[Matt Sicker]

On the javax->jakarta idea, I think that's a good idea. Every plugin
we have that uses a javax API should have a jakarta equivalent created
and promoted over the old version. We have several of them already;
I'm not sure which ones remain.

On Fri, Apr 1, 2022 at 6:22 AM Gary Gregory  wrote:
>
> Yes, thank you Piotr, it's tremendously helpful :-)
>
> Gary
>
> On Fri, Apr 1, 2022, 03:28 Ralph Goers  wrote:
>
> > Thank you for that!
> >
> > Ralph
> >
> > > On Mar 31, 2022, at 12:53 PM, Piotr P. Karwasz 
> > wrote:
> > >
> > > Hello,
> > >
> > > On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz 
> > wrote:
> > >> The `log4j-1.2-api` code seems synchronized between `master` and
> > >> `release-2.x` up to January 20th. Since part of the desynchronization
> > >> that occurred afterwards is my fault and some of my changes are built
> > >> on top of Gary's, I can take care of the cherry-picking. Probably a
> > >> comparison of the two codes will be necessary at the end.
> > >
> > > This is done: the Log4j 1.2 bridge in `master` is up-to-date with
> > > `release-2.x`. I hit a couple of bumps in the road, while merging the
> > > commits, but thanks to Matt everything should be Ok now.
> > >
> > > Piotr
> >
> >

Re: The roadmap to Log4j 3.0.0

[Ralph Goers]

While we need to support jakarta I am not sure it is time to drop javax. Our 
history 
is to support things until the active user base is very low. Last I heard javax 
usage 
was still larger than jakarta.

Ralph

> On Apr 1, 2022, at 9:24 AM, Matt Sicker  wrote:
> 
> On the javax->jakarta idea, I think that's a good idea. Every plugin
> we have that uses a javax API should have a jakarta equivalent created
> and promoted over the old version. We have several of them already;
> I'm not sure which ones remain.
> 
> On Fri, Apr 1, 2022 at 6:22 AM Gary Gregory  wrote:
>> 
>> Yes, thank you Piotr, it's tremendously helpful :-)
>> 
>> Gary
>> 
>> On Fri, Apr 1, 2022, 03:28 Ralph Goers  wrote:
>> 
>>> Thank you for that!
>>> 
>>> Ralph
>>> 
 On Mar 31, 2022, at 12:53 PM, Piotr P. Karwasz 
>>> wrote:
 
 Hello,
 
 On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz 
>>> wrote:
> The `log4j-1.2-api` code seems synchronized between `master` and
> `release-2.x` up to January 20th. Since part of the desynchronization
> that occurred afterwards is my fault and some of my changes are built
> on top of Gary's, I can take care of the cherry-picking. Probably a
> comparison of the two codes will be necessary at the end.
 
 This is done: the Log4j 1.2 bridge in `master` is up-to-date with
 `release-2.x`. I hit a couple of bumps in the road, while merging the
 commits, but thanks to Matt everything should be Ok now.
 
 Piotr
>>> 
>>> 

OSGI service lookup

[Piotr P. Karwasz]

Hello,
In my initial version of the release 2.x `ServiceLoaderUtil` I used an
external OSGI bundle (`osgi-resource-locator`) to lookup services in other
bundles (cf. source code
).
The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
use it too.

However, after discussing this with Ralph, I am no longer convinced that
this is the best tool for the job, because:

   - since Eclipse took over Java EE, the artifact seems unmaintained
(cf. Github
   project ) and does
   not even have a stable JPMS module name, which is problematic for `master
   `,
   - it is not included by default in the OSGI containers I checked
   (although I didn't check very hard).

Because of these reasons and the difficulties I had in using
`osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
, waiting for a better
solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
BC to take care of). Among the alternatives we could:

   1. duplicate the functionality of `osgi-service-locator` (but not the
   code which is licensed under EPL),
   2. rely on the Service Loader Mediator
   ,
   which requires an additional OSGI service. I am not sure if this would work
   in our case, since I am not calling `ServiceLoader` directly, but
   through `MethodHandles.Lookup` as a workaround for Java 9+ caller
   sensitivity. From what I have read the Service Loader Mediator weaves
   the bundles code looking for calls of `ServiceLoader` methods.
   3. keep the *status quo*, which requires all OSGI bundles to register
   their services as OSGI services. If I am not mistaken, currently only
   implementation providers do it. While this might seem as the most
   cumbersome solution, Declarative OSGI Services
   ,
   which were already proposed by Matt in LOG4J2-515
   , should help keep the
   maintenance work minimal, since Declarative Services Runtimes seem quite
   commonly deployed these days.

Which solution should be adopted? I think that the main concern here should
be to provide a simple way for plugin authors to deploy their modules in
OSGI.

Piotr

Re: The roadmap to Log4j 3.0.0

[Matt Sicker]

Given the modularity of 3.x, as long as we provide both the jakarta
and javax versions of each, I think we'll be ok. We can revisit
removal of javax variants in the future if they become a burden on
maintenance (e.g., incompatible with newer versions of Java).

On Fri, Apr 1, 2022 at 12:08 PM Ralph Goers  wrote:
>
> While we need to support jakarta I am not sure it is time to drop javax. Our 
> history
> is to support things until the active user base is very low. Last I heard 
> javax usage
> was still larger than jakarta.
>
> Ralph
>
> > On Apr 1, 2022, at 9:24 AM, Matt Sicker  wrote:
> >
> > On the javax->jakarta idea, I think that's a good idea. Every plugin
> > we have that uses a javax API should have a jakarta equivalent created
> > and promoted over the old version. We have several of them already;
> > I'm not sure which ones remain.
> >
> > On Fri, Apr 1, 2022 at 6:22 AM Gary Gregory  wrote:
> >>
> >> Yes, thank you Piotr, it's tremendously helpful :-)
> >>
> >> Gary
> >>
> >> On Fri, Apr 1, 2022, 03:28 Ralph Goers  wrote:
> >>
> >>> Thank you for that!
> >>>
> >>> Ralph
> >>>
>  On Mar 31, 2022, at 12:53 PM, Piotr P. Karwasz 
> >>> wrote:
> 
>  Hello,
> 
>  On Mon, 28 Mar 2022 at 22:02, Piotr P. Karwasz 
> >>> wrote:
> > The `log4j-1.2-api` code seems synchronized between `master` and
> > `release-2.x` up to January 20th. Since part of the desynchronization
> > that occurred afterwards is my fault and some of my changes are built
> > on top of Gary's, I can take care of the cherry-picking. Probably a
> > comparison of the two codes will be necessary at the end.
> 
>  This is done: the Log4j 1.2 bridge in `master` is up-to-date with
>  `release-2.x`. I hit a couple of bumps in the road, while merging the
>  commits, but thanks to Matt everything should be Ok now.
> 
>  Piotr
> >>>
> >>>
>

Re: OSGI service lookup

[Matt Sicker]

I'd most prefer whichever approach is most compatible with the
non-OSGi use case. For anything OSGi-specific that needs to be added
to our metadata, it would be best provided in a format that's easily
merged with other metadata (e.g., via the manifest.mf file). The DSR
idea still sounds pretty good.

On Fri, Apr 1, 2022 at 1:32 PM Piotr P. Karwasz  wrote:
>
> Hello,
> In my initial version of the release 2.x `ServiceLoaderUtil` I used an
> external OSGI bundle (`osgi-resource-locator`) to lookup services in other
> bundles (cf. source code
> ).
> The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
> use it too.
>
> However, after discussing this with Ralph, I am no longer convinced that
> this is the best tool for the job, because:
>
>- since Eclipse took over Java EE, the artifact seems unmaintained
> (cf. Github
>project ) and does
>not even have a stable JPMS module name, which is problematic for `master
>`,
>- it is not included by default in the OSGI containers I checked
>(although I didn't check very hard).
>
> Because of these reasons and the difficulties I had in using
> `osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
> , waiting for a better
> solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
> BC to take care of). Among the alternatives we could:
>
>1. duplicate the functionality of `osgi-service-locator` (but not the
>code which is licensed under EPL),
>2. rely on the Service Loader Mediator
>,
>which requires an additional OSGI service. I am not sure if this would work
>in our case, since I am not calling `ServiceLoader` directly, but
>through `MethodHandles.Lookup` as a workaround for Java 9+ caller
>sensitivity. From what I have read the Service Loader Mediator weaves
>the bundles code looking for calls of `ServiceLoader` methods.
>3. keep the *status quo*, which requires all OSGI bundles to register
>their services as OSGI services. If I am not mistaken, currently only
>implementation providers do it. While this might seem as the most
>cumbersome solution, Declarative OSGI Services
>
> ,
>which were already proposed by Matt in LOG4J2-515
>, should help keep the
>maintenance work minimal, since Declarative Services Runtimes seem quite
>commonly deployed these days.
>
> Which solution should be adopted? I think that the main concern here should
> be to provide a simple way for plugin authors to deploy their modules in
> OSGI.
>
> Piotr

Re: OSGI service lookup

[Ralph Goers]

Actually, I’d prefer the one that is the most OSGi-like so that it is easily 
usable 
by OSGi users (if there are any). It seems to me that what we are currently 
doing fits that the best - requiring them to be OSGi services.

Ralph

> On Apr 1, 2022, at 1:23 PM, Matt Sicker  wrote:
> 
> I'd most prefer whichever approach is most compatible with the
> non-OSGi use case. For anything OSGi-specific that needs to be added
> to our metadata, it would be best provided in a format that's easily
> merged with other metadata (e.g., via the manifest.mf file). The DSR
> idea still sounds pretty good.
> 
> On Fri, Apr 1, 2022 at 1:32 PM Piotr P. Karwasz  
> wrote:
>> 
>> Hello,
>> In my initial version of the release 2.x `ServiceLoaderUtil` I used an
>> external OSGI bundle (`osgi-resource-locator`) to lookup services in other
>> bundles (cf. source code
>> ).
>> The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
>> use it too.
>> 
>> However, after discussing this with Ralph, I am no longer convinced that
>> this is the best tool for the job, because:
>> 
>>   - since Eclipse took over Java EE, the artifact seems unmaintained
>> (cf. Github
>>   project ) and does
>>   not even have a stable JPMS module name, which is problematic for `master
>>   `,
>>   - it is not included by default in the OSGI containers I checked
>>   (although I didn't check very hard).
>> 
>> Because of these reasons and the difficulties I had in using
>> `osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
>> , waiting for a better
>> solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
>> BC to take care of). Among the alternatives we could:
>> 
>>   1. duplicate the functionality of `osgi-service-locator` (but not the
>>   code which is licensed under EPL),
>>   2. rely on the Service Loader Mediator
>>   ,
>>   which requires an additional OSGI service. I am not sure if this would work
>>   in our case, since I am not calling `ServiceLoader` directly, but
>>   through `MethodHandles.Lookup` as a workaround for Java 9+ caller
>>   sensitivity. From what I have read the Service Loader Mediator weaves
>>   the bundles code looking for calls of `ServiceLoader` methods.
>>   3. keep the *status quo*, which requires all OSGI bundles to register
>>   their services as OSGI services. If I am not mistaken, currently only
>>   implementation providers do it. While this might seem as the most
>>   cumbersome solution, Declarative OSGI Services
>>   
>> ,
>>   which were already proposed by Matt in LOG4J2-515
>>   , should help keep the
>>   maintenance work minimal, since Declarative Services Runtimes seem quite
>>   commonly deployed these days.
>> 
>> Which solution should be adopted? I think that the main concern here should
>> be to provide a simple way for plugin authors to deploy their modules in
>> OSGI.
>> 
>> Piotr

Re: OSGI service lookup

[Matt Sicker]

OSGi services are the lowest level primitive they have besides bundles and 
wires. The declarative services runtime was my preferred system when I was 
using OSGi several years ago, though I don’t know if that’s the preferred 
standard.

—
Matt Sicker

> On Apr 1, 2022, at 18:16, Ralph Goers  wrote:
> 
> Actually, I’d prefer the one that is the most OSGi-like so that it is easily 
> usable 
> by OSGi users (if there are any). It seems to me that what we are currently 
> doing fits that the best - requiring them to be OSGi services.
> 
> Ralph
> 
>> On Apr 1, 2022, at 1:23 PM, Matt Sicker  wrote:
>> 
>> I'd most prefer whichever approach is most compatible with the
>> non-OSGi use case. For anything OSGi-specific that needs to be added
>> to our metadata, it would be best provided in a format that's easily
>> merged with other metadata (e.g., via the manifest.mf file). The DSR
>> idea still sounds pretty good.
>> 
>>> On Fri, Apr 1, 2022 at 1:32 PM Piotr P. Karwasz  
>>> wrote:
>>> 
>>> Hello,
>>> In my initial version of the release 2.x `ServiceLoaderUtil` I used an
>>> external OSGI bundle (`osgi-resource-locator`) to lookup services in other
>>> bundles (cf. source code
>>> ).
>>> The main advantage I saw in it was that JAXB and other Jakarta EE artifacts
>>> use it too.
>>> 
>>> However, after discussing this with Ralph, I am no longer convinced that
>>> this is the best tool for the job, because:
>>> 
>>>  - since Eclipse took over Java EE, the artifact seems unmaintained
>>> (cf. Github
>>>  project ) and does
>>>  not even have a stable JPMS module name, which is problematic for `master
>>>  `,
>>>  - it is not included by default in the OSGI containers I checked
>>>  (although I didn't check very hard).
>>> 
>>> Because of these reasons and the difficulties I had in using
>>> `osgi-resource-locator` on Java 11 I removed OSGI support in PR #804
>>> , waiting for a better
>>> solution (the `ServiceLoaderUtil` is a post-2.17.2 addition, so there is no
>>> BC to take care of). Among the alternatives we could:
>>> 
>>>  1. duplicate the functionality of `osgi-service-locator` (but not the
>>>  code which is licensed under EPL),
>>>  2. rely on the Service Loader Mediator
>>>  ,
>>>  which requires an additional OSGI service. I am not sure if this would work
>>>  in our case, since I am not calling `ServiceLoader` directly, but
>>>  through `MethodHandles.Lookup` as a workaround for Java 9+ caller
>>>  sensitivity. From what I have read the Service Loader Mediator weaves
>>>  the bundles code looking for calls of `ServiceLoader` methods.
>>>  3. keep the *status quo*, which requires all OSGI bundles to register
>>>  their services as OSGI services. If I am not mistaken, currently only
>>>  implementation providers do it. While this might seem as the most
>>>  cumbersome solution, Declarative OSGI Services
>>>  
>>> ,
>>>  which were already proposed by Matt in LOG4J2-515
>>>  , should help keep the
>>>  maintenance work minimal, since Declarative Services Runtimes seem quite
>>>  commonly deployed these days.
>>> 
>>> Which solution should be adopted? I think that the main concern here should
>>> be to provide a simple way for plugin authors to deploy their modules in
>>> OSGI.
>>> 
>>> Piotr
>