Separate out resource loading from spring core [SPR-12508]

[spring-projects-issues]

Adam Gent opened SPR-12508 and commented

I have wanted many times to use how spring does resource loading in other projects that need configuration particularly bootstrapped configuration that needs to be loaded before logging does(for example the classpath*).

While I could use spring-core as a maven dependency the spring-core has a dependency on logging. This is particularly annoying if you want to configure logging before its loaded through resources (ie classpath files). The jar in terms of footprint is also more than just resource loading but that is a minor issue.

Basically a unified resource loading library would be very useful in many non spring projects particularly since resource loading (ie low level configuration takes precedence in terms of dependency) over almost all of the other things in spring (except maybe annotations and aop).

So I think "spring-resource" library/artifact that has zero or optional dependencies that spring-core depends on would be a good thing not just for spring but for the rest of the Java community (that is spring-resource would be close to the root dependency).

Many times I have contemplated ripping out the spring io resource classes and creating my own project which I may do but I figured I would give filing an issue to see if I'm the only one with these thoughts.

---

Affects: 4.1.2

[spring-projects-issues]

Juergen Hoeller commented

It's nice to see that you find the core.io package useful enough to want it in a minimal form... However, I'm afraid it's not trivial to extract since there's also the root core package and the lower-level util package to consider, as well as the optional dependencies involved. Aside from that, a similar argument could be made for extracting core.task or core.convert, so I'm not sure the lines are easy to draw. The end result might be quite arbitrary, or resulting in way too many smallish core jars.

As for logging, I'm not sure I get the actual problem: Is it just the Maven dependency? Would a redeclaration to optional basically do the job? But that's just about the implicit inclusion of the Commons Logging jars on the classpath anyway... Many classes don't trigger logging in the first place, independent from the presence of the jars on the classpath, so can easily be used for pre-logging setup code. Or am I missing something here?

Juergen

[spring-projects-issues]

Adam Gent commented

Juergen as always you are so kind :)
I did figure it would be a rather big task especially given the cross cutting need of utilities but figured it wouldn't hurt to check.

The issue with the logging is that its hard to tell when it gets loaded. You have to basically inspect the classes and their dependent classes to make sure that logging doesn't get loaded. Or you can be lazy like me and use the debugger. Its not really commons logging as it is any logging but if you statically reference a commons logger (through dependencies or directly) you will usually kick off the default logging configuration. This is especially annoying with log4j because most of configuration outside of its config files needs to be done with system properties before its loaded.

Presumably you can use core.io and not kick off logging by avoiding certain classes I am sure but for some reason I believe I did cause logging to be loaded. I can't recall which class but I can find out.

As a related side note I did fix logback (Ceki accepted my pull request) to allow ServiceLoader configuration style loading aka Java configuration of logging:
http://stackoverflow.com/questions/22335441/configure-logback-to-defer-to-java-configuration-aka-plain-java-configuration-of
So this means you could potentially have a complete Java configured app but you wouldn't be able to use Spring core.io to do any property file loading as that will kick off the default not desired logging configuration... or worse it might even block... speaking of which I should probably test that.

Now logging is probably a fringe case (its the only time I have really had these kind of issues) so perhaps its not really separating out core.io but rather a spring project that helps configure logging particularly logback before the rest of spring loads is the real use case.

Like I said I can probably create an independent project based on a subset of spring core io and use it to bootstrap logback or perhaps see if I can put better resource loading into logback.

Anyway I don't want to waste anymore of your time so I have no problem if you close the issue :)

Cheers

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.