[
https://issues.jboss.org/browse/WELD-935?page=com.atlassian.jira.plugin.s...
]
Bob Obringer edited comment on WELD-935 at 5/31/12 1:35 AM:
------------------------------------------------------------
It appears that this is still an issue in Weld 2.0.0.Alpha2.
Our development/build process is so tied to maven that this issue makes weld a
non-starter. Is there ANY way to use Maven to include a dependency on Weld without
breaking our existing SLF4J implementation?
We've also got other dependencies on javassist.
Seems that for those of us who don't include our dependencies by hand, we really need
a way to include weld-servlet in our projects.
was (Author: bobringer):
It appears that this is still an issue in Weld 2.0.0.Alpha2.
Our development/build process is so tied to maven that this issue makes weld a
non-starter. Is there ANY way to use Maven to include a dependency on Weld without
breaking our existing SLF4J implementation?
Do not deploy shaded jars like weld-servlet (as a bad replacement for
weld-servlet-core) because they break dependency conflict resolution and introduce
classpath issues
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: WELD-935
URL:
https://issues.jboss.org/browse/WELD-935
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.1.Final
Reporter: Geoffrey De Smet
Shading = repackaging a dependency class inside your own jar (instead of depending on the
jar of that class).
I've just spend quite some time trying to find such a classpath issue, which
manifested it self as "NoSuchMethodError on slf4j LocationAwareLogger.log(...)"
It turns out the weld-servlet jar was shading some of the slf4j classes.
Shading is evil. Here's why:
- It breaks maven/gradle/buildr/ivy dependency conflict resolution. If guvnor uses slf4j
1.6 and weld-servlet; and weld-servlet shades slf4J 1.5; maven will not detect a slf4j
version conflict and will therefor have no chance to put only 1 version of slf4J in the
classpath. As a result, there's no telling which slf4J version will be used (the first
in the classpath, but that is very unstable)
- It distorts ANT's classpath: putting the weld-servlet jar (with slf4J 1.5) in your
classpath can effectively turn the explicit slf4j-1.6.0.jar in your classpath into dead
code or combine it with binary incompatibly slf4j extensions such as
xstream-for-slf4j-1.6.0.jar (fictive example).
- Because the slf4j classes are actually in the weld-servlet jar, they cause bloat: the
user might have already downloaded the real slf4j jar.
- Most importantly, because the (Red Hat and other) guys who create RPM's out of our
jars say so. See slide 13 of this Fosdem presentation:
http://sochotni.fedorapeople.org/fosdem2011-sochotnicky.pdf (video :
http://ia600608.us.archive.org/16/items/fosdem_2011_free_java_guide_to_pa...)
Summary: shading will cause grief for your users. Why subject your users to grief? In
this case, don't give them a good and a bad choice, only give them a good choice.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira