-
Notifications
You must be signed in to change notification settings - Fork 14
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
Configure Plug-in Start Levels to enable slf4j-2 logging #43
Conversation
OK - lets revisit it on Thursday and I can merge before doing M3 EPP build. |
For all products this means that the implementation of the OSGi Service Loader Mediator Specification supplied by Eclipse-Platform, namly the 'org.apache.aries.spifly.dynamic.bundle' bundle has to be auto-started at level two, like it is already done for the Eclipse SDK managed by Eclipse-Platform. All products that contain the slf4j.simple logging back-end, need to auto-start slf4j.simple as well. Additionally a VM-property is set to turn slf4j.simple off by default. A user can then configure it as desired by modifying/setting the corresponding system-properties in the eclipse.ini, as defined in the SimpleLogger doc: https://www.slf4j.org/api/org/slf4j/simple/SimpleLogger.html If a product uses the o.e.m2e.logback feature, and therefore logback as logging back-end, nothing needs to be done. The m2e.logback feature already performs all necessary configuration upon its installation. Fixes eclipse-packaging#27
The fixed WebTools version was contributed to SimRel as well as the M2E M3 snapshot that contains the m2e.logback feature which contains p2-advices to configure logback automatically. |
@jonahgraham everything should be ready now. The RAP devs thankfully submitted the fix and contributed it to SimRel just in time. |
Thanks Hannes. I'll aim to include this change in M3 tomorrow. |
I have run into a couple of problems with getting this integrated.
I am working on solutions to the above now and I mostly understand what is going on. My vacation has left little time to resolve this before M3 which I really need to have kicked off in the next couple of hours to make the publishing deadline of 10am tomorrow. |
I have merged this change + disabling slf4j.simple on php, committers and scout so I can build M3. If I can resolve it fully soon I will cancel and restart the build. Otherwise we'll fix those products for RC1. |
Thanks Jonah. Sorry I don't have time to help today and probably only little time at the weekend, but I'll also try to look into this and help where it is needed.
This is indeed a fundamental problem I encountered as well just recently. I havn't found a good solution yet. |
Please see #47 for a possible fix for these.
On further reflection I am unconcerned about this part of the change for now. |
Yes, it isn't very bad, I meant it is quite low level. |
Fixes #27
For all products this means that the implementation of the OSGi Service Loader Mediator Specification supplied by Eclipse-Platform, namly the 'org.apache.aries.spifly.dynamic.bundle' bundle has to be auto-started at level two, like it is already done for the Eclipse SDK managed by Eclipse-Platform.
All products that contain the slf4j.simple logging back-end, need to auto-start slf4j.simple as well.
Additionally a VM-property is set to turn slf4j.simple off by default. A user can then configure it as desired by modifying/setting the corresponding system-properties in the eclipse.ini, as defined in the SimpleLogger doc:
https://www.slf4j.org/api/org/slf4j/simple/SimpleLogger.html
If a product uses the o.e.m2e.logback feature, and therefore logback as logging back-end, nothing needs to be done. The m2e.logback feature already performs all necessary configuration upon its installation.
For the products that don't include m2e.logback this is the same change like it was done with the following two changes
At the moment I just opened this as a draft since the following changes are still pending and need to be contributed to SimRel in order to make the logging fully functional:
Theoretically we could already merge this even before the mentioned issues are resolved respectively before the solution is contributed to SimRel, but we could only verify if it really works afterwards.