Skip to content

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

Description

@spring-projects-issues

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

Metadata

Metadata

Assignees

Labels

in: coreIssues in core modules (aop, beans, core, context, expression)type: enhancementA general enhancement

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions