-
Notifications
You must be signed in to change notification settings - Fork 460
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
Common Eclipse logging support #236
Comments
@nedtwigg / @jbduncan : I would like to have your feedback before I continue... No hurry, whenever you find time... I provided a POC for this enhancement.
I want logging in particular for Eclipse. Some Eclipse plugins already have and need a logging service. These individual implementations will be removed. Others (like JDT) had no service. In case no logging service is provided, Eclipse log messages are dropped, which I like to avoid. The Local-First class loader would allow any class (extension or not) to use Slf4J. It has the benefit, that it has direct access to the log-level set by Maven and Gradle (tested with JUnit5 and Jung), and logs can be more gradual than std-err / std-out. However, it is quite a big change to the framework, and I saw that e.g. for Eclipse log messages the std-err std-out is in the end sufficient. So if no one sees a benefit in using Slf4J, I would agree to drop it. @nedtwigg
Can you give me a hint, why that fails? Otherwise I'll investigate myself. First time I used my own class loader. Thought I understood the concept, but Fresh Mark proved me wrong. Regardless the outcome of this discussion, I would like to understand the problem. So if you can give me a nudge in the right direction, I would appreciate it. |
Hi @fvgh. Thank you for asking me to have a look at this issue, but I fear I won't have the time and mental bandwidth to review it because I'm still getting adjusted to work and trying to tackle #277. @nedtwigg, is this issue something you can review on your own? Or would you like me to have a look at it as well at some point? |
Hi @jbduncan, sorry, I should have formulated the request clearer. I don't want a code review, since it is just a POC. Since you guys worked a lot on Spotless, I wanted your opinion, whether Slf4J logging would be beneficial enough for all Spotless components, so that it justifies the overhead (local-first class loader). Or maybe you can see other use cases where you would profit from such a class loading concept. For Eclipse alone, it is not worth it. |
So let's say I have this (pseudo-script). buildscriptClasspath {
'spotless'
'google-java-format:v1'
}
spotless {
java {
googleJavaFormat('v2')
}
} In this example, LocalClassLoader is going to use If you want to pass some kind of logging classloader from the root classloader to the others, I think you'll have to enumerate exactly which packages you need to load, along these lines: I personally have better luck stepping through a debugger than figuring out how to enable the log-level that I need, but I'm all for people using whichever tool they prefer. If we can figure out a way to accomplish this without adding too much code into |
@nedtwigg Thanks for the link. I had something similar in mind. What is vexing me is the fact that the Fresh Mark worked before. All the In that case, I find it still suspicious, that Fresh Mark fails. Spotless should provide all Fresh Mark it needs in the URLs. So FreshMark should never bother the Gradle/Maven class loader (except of course for java/javax). Or is this assumption wrong? |
Not quite, the bootstrap classloader (Object.class, Class.class, jdk/nashorn/internal/runtime/ScriptObject.class, etc.) will be needed too. Classloaders are really difficult. Might wanna take a look at this: https://stackoverflow.com/questions/5445511/how-do-i-create-a-parent-last-child-first-classloader-in-java-or-how-to-overr |
@nedtwigg After looking at JVMS §5.3, I hope I understand now, why for example the In opposite to the "parent last" class loader implementation you mentioned, I see no harm to derive from URLClassLoader, do you? You mentioned also the possibility to enumerate SLF4J packages. I don't like this approach since:
Hence I prefer to stick with explicitly reduce the dependency scope. When it comes to naming the classes, I thought it is more readable to mention the purpose (loading features), instead of the current implementation (load missing classes from build tool class loader). Please let me know what you think. |
Assuming it works, I like the design of your FeatureClassLoader. However, I would still limit its packages to slf4j, as such: bbdc876
The entire point of SLF4J is to be a stable set of interfaces that can be implemented by any jar, thus we don't need to worry about them changing
See my linked commit above, I don't think this is true
It's common to use |
Sure.
Not sure about that. What worries me is the following part of the SLF4J compatibility statement:
So in my opinion I cannot make a dependency to slf4j-api in the Eclipse-Base (feature) and expect that the binding used by Maven and Gradle (build tools) will work. I must ensure that the slf4j-api classes of build tools are used by the feature classes. Hence I thought that it would be funny to declare the slf4j-api as a run-time dependency. I understand your point about checking of available features at run-time. But in this case maybe it is cleaner to omit the dependency scope reduction on the feature, but assure that the class loader always select the build-tool class loader for |
From that same compatibility statement:
I thought the whole point of punching through to the buildscript classpath was to get SLF4J. If that isn't the point, what is? |
Maybe I misinterpreted your previous statement
Yes, the slf4j-api.jar is stable, so the feature can compile against version N and use later on M. But the feature needs a binding. That's provided by the build tool. So the FeatureClassLoader needs to assure that the binding classes, which are missing in the feature, are taken from the build tool. But the SLF4J compatibility statement states that the feature can't use binding M with API N. As a solution, the feature dependency scope for slf4j-api.jar is reduced to compile time, to ensure that API and binding are both not part of the feature itself. With my current solution, the FeatureClassLoader in the spotless-lib and the Eclipse feature build script, which reduces the compile scope of the slf4j-api.jar, are independent. The FeatureClassLoader does not know anything about SLF4J. I just want to keep this independence. I understand your remark, why my current solution lead to unexpected results (feature testing). So my proposal would be something like this: protected Class<?> findClass(String name) throws ClassNotFoundException {
if (name.startsWith("org.slf4j.")) {
return buildToolClassLoader.loadClass(name);
} else {
return super.findClass(name);
} Then the feature does not need to take care of any SLF4J specific dependency scope reductions. OK for you? |
Ranked priorities. If we have to make a sacrifice, we should sacrifice 3 rather than 1 or 2.
Looks good to me, if it works ;-) I think it will.
I don't follow, but that's okay. I also think this is likely to affect formatters besides just the eclipse one. I would be surprised if slf4j wasn't supported by some of our formatters already. e.g. the currently open PR #328 https://github.com/antlr/Antlr4Formatter/search?q=slf4j&unscoped_q=slf4j |
Published in 1.18.0 |
@nedtwigg I did not delete eclipse_base_logger_limited branch since it is yours. I don't need it anymore. Do you? |
I don't, feel free to delete :) |
With the integration of new Eclipse formatters, a common logging manager should be provided, supporting the following features:
org.eclipse.core.runtime.Plugin
(seegreclipse
for implementation details)The text was updated successfully, but these errors were encountered: