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

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

Closed
spring-projects-issues opened this issue Dec 4, 2014 · 3 comments
Closed
Labels
in: core status: bulk-closed

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Dec 4, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 4, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 5, 2014

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 spring-projects-issues added status: waiting-for-triage type: enhancement in: core and removed type: enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed and removed status: bulk-closed status: waiting-for-triage labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: bulk-closed
Projects
None yet
Development

No branches or pull requests

2 participants