Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide an Apache Commons Logging's LogFactory provider in spring-jcl to support WebSphere's Parent-First classloader [SPR-15903] #20457

Closed
spring-projects-issues opened this issue Aug 26, 2017 · 1 comment
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Aug 26, 2017

Ibrahim Ghazal opened SPR-15903 and commented

In #19081 (specifically this comment), Juergen Hoeller said:

In "Parent First" mode, it's always WebSphere's own version of Commons Logging getting picked up. It does not make a difference whether the application contains a variant of Commons Logging itself: an application-level variant is always being ignored. Therefore it doesn't make a difference whether we embed our own variant versus JCL-over-X bridges or the standard Commons Logging jar.

In practice, there is a difference. When a real Commons Logging JAR is picked up (such as when using WebSphere's Parent-First classloader), spring-jcl is not used and spring's logs end up going to Commons Logging's default implementation (most likely JUL). But when log4j-jcl or jcl-over-slf4j are used instead of spring-jcl, logs are redirected to Log4j2 or SLF4J respectively.

This is because Commons Logging searches for a provider using the JAR Services Discovery mechanism (META-INF/services/org.apache.commons.logging.LogFactory file). Both log4j-jcl and jcl-over-slf4j provide this and so they just work even in such situations.

I think it's quite easy to provide this in spring-jcl too.

(The linked comment above mentions implementing the discovery mechanism in spring-jcl, but this issue is asking for the opposite (providing a provider)).


Affects: 5.0 RC3

Issue Links:

Referenced from: commits 0b86c71

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jul 3, 2018

Juergen Hoeller commented

This should finally be sorted out through #21127, with standard Commons Logging service discovery supported through a LogFactoryService class and a corresponding META-INF entry.

This will be available in the upcoming 5.1.0.BUILD-SNAPSHOT. Feel free to give it an early try, or otherwise in the official 5.1 RC1 release coming up in late July. Let's reopen this issue if any issues with JCL on WebSphere remain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants