Bugzilla – Full Text Bug Listing
| Summary: | Logging library conflict | ||
|---|---|---|---|
| Product: | [Technology] EPP | Reporter: | Zeb Ford-Reitz <zeb.ford-reitz> |
| Component: | testing-package | Assignee: | Zeb Ford-Reitz <zeb.ford-reitz> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | david_williams, gunnar, markus.tiede, remy.suen |
| Version: | unspecified | ||
| Target Milestone: | 1.4.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 370690 | ||
|
Description
Zeb Ford-Reitz
Manually removing the org.slf4j.api_1.6.4.v20111214-2030 bundle from the plugins directory seems to workaround the issue. I'm not sure how this bundle made its way into the package, but the resulting situation is very similar to bug 351121. Adding Gunnar, our Orbit-resident logging expert. to CC list, in case any obvious insights into details. My guess is that since EPP packages are built against Juno staging repo, there are "tons of stuff" in there that might satisfy the "requirement" (possibly optional?) of some "import packages" statement. The cure might be to "tighten" the requirement in some way, but, I am not sure how to do that. Another cure might be to find out who specifies it (in content metadata) as "optional, but greedily installable". It should probably be optional="true" greedy="false" (just guessing). Thanks for the pointer to bug 370690. The root cause seem to be a ClassCastException. Caused by: java.lang.ClassCastException: org.slf4j.helpers.NOPLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext at org.eclipse.jubula.client.core.Activator.start(Activator.java:53) I haven't looked at the Activator source code but you need to add a check before you actually do the cast. Even if LogBack is available in the IDE there is no 100% guarantee that it will be used as the actual SLF4J implementation on every installation. The reason is simply that you can't control what a user installs at any point in time in the future. SLF4J 1.6.4 + LogBack 1.0 (both in Orbit) will be part of Juno. The previous versions are still part of Orbit. Thus, technically they will also be available. But I recommend upgrading. Thanks for the tip, Gunnar! I guess I just assumed that we had more control over logging configuration. I've added the instanceof check with http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/commit/?id=d541d518665e71919862571f1382d2c02a9ca566. This still doesn't address how the rogue org.slf4j.api_1.6.4.v20111214-2030 bundle ended up in Eclipse for Testers, and logging is essentially disabled in such a configuration. However, I will take a closer look at this in the near future, and resolve the bug once I have more information. (In reply to comment #4) > This still doesn't address how the rogue org.slf4j.api_1.6.4.v20111214-2030 > bundle ended up in Eclipse for Testers, and logging is essentially disabled in > such a configuration. However, I will take a closer look at this in the near > future, and resolve the bug once I have more information. Maybe you only have a dependency but no strict include? In such a case p2 might just use the latest versions which is 1.6.4. I've put in CQs for SLF4J 1.6.4 + LogBack 1.0, so hopefully we will be able to use them for Juno, which should prevent the conflict in this case. Logging libraries updated for master: http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/commit/?id=0e321cb8ebf192ee37f715b2f79fa22dae1487c8 and 1.2: http://git.eclipse.org/c/jubula/org.eclipse.jubula.core.git/commit/?h=1.2&id=b0207d986771e963e0106441d8b6ab9e1602f3bb branches. This should resolve the version conflict in Eclipse for Testers Juno. In the meantime the fix has been verified - setting status accordingly. |