Re: OSGI service lookup

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

Re: OSGI service lookup

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 p

Re: OSGI service lookup

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

Re: The roadmap to Log4j 3.0.0

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

OSGI service lookup

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

Re: The roadmap to Log4j 3.0.0

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

Re: The roadmap to Log4j 3.0.0

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: > > Ye

Re: The roadmap to Log4j 3.0.0

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

Re: The roadmap to Log4j 3.0.0

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 differe

Re: The roadmap to Log4j 3.0.0

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 desynchroniza