jvz commented on pull request #804: URL: https://github.com/apache/logging-log4j2/pull/804#issuecomment-1075350519
> * OSGI support was also removed from `LoaderServiceUtil`, because it uses an artifact (`osgi-resource-locator`) that seems to be abandoned (it is still supported by JAXB API and similar, but I found no other references). Log4j registers (and probably should register) its services as native OSGI services. This is something I still struggle with. In master, I've refactored the OSGi service registration to mostly use ServiceLoader invoked from a bundle activator class for each module. That then calls `ServiceRegistry` (a new class for holding known services) which can add and remove services. My problem with either approach is that it requires OSGi users to do something additional to support their own custom plugins that we can't exactly automate for them. It's already annoying enough that users currently need to manually update their module-info.java to export the service class; having to do even more manual work for OSGi means that most plugins out there won't bother supporting OSGi which is a bummer. > * the number of `ServiceLoader#load` calls has been reduced to at most 2: one for the caller's classloader and possibly one for the thread context classloader, This is a great change! > * most `ServiceLoaderUtil#loadServices` call sites store the result in a static variable. To prevent memory leaks those calls don't use the TCCL. This is an interesting limitation. I think we'll need to examine master to see any similar issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
