11:23 p.m.
Andrew Hughes created WELD-1109:
-----------------------------------
Summary: weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix this
in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
11:34 p.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Andrew Hughes commented on WELD-1109:
-------------------------------------
This bug is similar to how the gwt jar's include the servlet api classes:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4815
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
11:36 p.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Andrew Hughes edited comment on WELD-1109 at 4/18/12 12:34 AM:
---------------------------------------------------------------
This bug is similar to how the gwt jar's include the servlet api classes:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3851
http://code.google.com/p/google-web-toolkit/issues/detail?id=4815
was (Author: ahhughes):
This bug is similar to how the gwt jar's include the servlet api classes:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4815
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
11:51 p.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Andrew Hughes commented on WELD-1109:
-------------------------------------
Just for reference, you exclude slf4j from the jboss5 classified jar:
https://github.com/weld/core/blob/master/environments/servlet/build/pom.x...
I would recommend the 'default' excludes slf4j, and another 'slf4j'
classified jar should include it (but I think this is still wrong) and now you have
backwards compatibility issues to consider....
{quote}
<execution>
<id>slf4j</id>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createSourcesJar>true</createSourcesJar>
<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>slf4j-${slf4jVersion}</shadedClassifierName>
<artifactSet>
<excludes>
<exclude>xml-apis:xml-apis</exclude>
<exclude>org.apache.tomcat:catalina</exclude>
<exclude>org.apache.tomcat:servlet-api</exclude>
<exclude>org.apache.tomcat:juli</exclude>
<exclude>org.apache.tomcat:annotations-api</exclude>
<exclude>javax.faces:jsf-api</exclude>
<exclude>org.mortbay.jetty:jetty</exclude>
</excludes>
</artifactSet>
</configuration>
</execution>
<execution>
<id>default</id>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createSourcesJar>true</createSourcesJar>
<artifactSet>
<excludes>
<exclude>xml-apis:xml-apis</exclude>
<exclude>org.apache.tomcat:catalina</exclude>
<exclude>org.apache.tomcat:servlet-api</exclude>
<exclude>org.apache.tomcat:juli</exclude>
<exclude>org.apache.tomcat:annotations-api</exclude>
<exclude>javax.faces:jsf-api</exclude>
<exclude>org.mortbay.jetty:jetty</exclude>
<exclude>org.slf4j:slf4j-api</exclude>
<exclude>org.slf4j:slf4j-jdk14</exclude>
</excludes>
</artifactSet>
</configuration>
</execution>
{quote}
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
3:44 a.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Ales Justin commented on WELD-1109:
-----------------------------------
You've already got weld-servlet-core, which is bare Weld servlet int bins.
Then you're on your own to include its deps.
So I don't see why slf4j should get a special treatment.
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
4:51 a.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Ceki Gulcu commented on WELD-1109:
----------------------------------
I find quite compelling Andrew Hughes' description of the downsides of including SLF4J
classes in weld-*. Also note that SLF4J's plug-in design is, in my humble opinion,
incompatible with including slf4j-api.jar class files within Weld artifacts. In any case,
please consider the inclusion of slf4j-jar classes in any library artifact as bad
practice.
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
5:01 a.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Ales Justin commented on WELD-1109:
-----------------------------------
I agree, and that's why we have bare weld-servlet-core artifact as well.
But for simplifying things for our users, we have a shaded artifact in place, with all
current weld-servlet-core deps == weld-servlet.
And I'll repeat myself, I don't see why slf4j should be treated differently; e.g.
why should we have weld-servlet-slf4j artifact, but not weld-servlet-javassist, etc
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
5:01 a.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Ales Justin resolved WELD-1109.
-------------------------------
Resolution: Won't Fix
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
6:26 a.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Andrew Hughes commented on WELD-1109:
-------------------------------------
bq. So I don't see why slf4j should get a special treatment.
Because slf4j (as good as it is) is not part of the jre. Additionally, weld-servlet-core
(to the best of my knowledge) does not offer maven dependency resolution (the standard
modularization mechanism for, maven, you can wrap this in osgi if you like)
weld-servlet-core (or another module) could fix this issue for maven projects. But
currently it does not. I would recommend a solution that is not based on the shade plugin,
but by maven dependency resolution.
My personal 2c...
I'm Happy to see this resolved as 'won't fix', because jBoss have voting
enabled on this jira instance. If by chance others feel that this is in fact a valid issue
I suggest you vote :)
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
6:33 a.m.
[
https://issues.jboss.org/browse/WELD-1109?page=com.atlassian.jira.plugin....
]
Andrew Hughes edited comment on WELD-1109 at 4/18/12 7:32 AM:
--------------------------------------------------------------
bq. So I don't see why slf4j should get a special treatment.
Because slf4j (as good as it is) is not part of the jre.
bq. And I'll repeat myself, I don't see why slf4j should be treated differently;
e.g. why should we have weld-servlet-slf4j artifact, but not weld-servlet-javassist, etc
Additionally, weld-servlet-core (to the best of my knowledge) does not offer maven
dependency resolution (the standard modularization mechanism for, maven, you can wrap this
in osgi if you like) weld-servlet-core (or another module) could fix this issue for maven
projects. But currently it does not. I would recommend a solution that is not based on the
shade plugin, but by maven dependency resolution. This does in fact include other non
slf4j dependencies, for which the shade plugin precludes maven dependency resolution to be
fully functional.
My personal 2c...
I'm Happy to see this resolved as 'won't fix', because jBoss have voting
enabled on this jira instance. If by chance others feel that this is in fact a valid issue
I suggest you vote :)
was (Author: ahhughes):
bq. So I don't see why slf4j should get a special treatment.
Because slf4j (as good as it is) is not part of the jre. Additionally, weld-servlet-core
(to the best of my knowledge) does not offer maven dependency resolution (the standard
modularization mechanism for, maven, you can wrap this in osgi if you like)
weld-servlet-core (or another module) could fix this issue for maven projects. But
currently it does not. I would recommend a solution that is not based on the shade plugin,
but by maven dependency resolution.
My personal 2c...
I'm Happy to see this resolved as 'won't fix', because jBoss have voting
enabled on this jira instance. If by chance others feel that this is in fact a valid issue
I suggest you vote :)
weld-servlet.jar should NOT contain slf4j (still found in
2.0.0.Alpha1)
-----------------------------------------------------------------------
Key: WELD-1109
URL: https://issues.jboss.org/browse/WELD-1109
Project: Weld
Issue Type: Bug
Components: Weld SPI
Affects Versions: 2.0.0.Alpha1
Environment: WELD-845
Reporter: Andrew Hughes
Priority: Critical
Labels: slf4j
Original Estimate: 4 hours
Remaining Estimate: 4 hours
NOTE: This is intentionally a duplicate of WELD-845 (because I believe you should fix
this in BOTH 1.1.7+ and 2.0.0).
Please fix this in v2.0.0, v1.1.x is something others might care to comment on...
Inheriting weld-servlet-2.0.0.Alpha1.jar or earlier (as a dependency) should not include
the org.slf4j.** classes. Because it precludes the consuming project from (easily)
selecting which slf4j binding they want to use. I recognise that it is
"convenient" to include these classes because they are quite common in use and
maybe also quite necessary for weld. However, it's very likely to raise slf4j binding
collisions (http://www.slf4j.org/codes.html#multiple_bindings). Especially with other 3rd
party dependencies having their own slf4j dependencies. It's also likely that this
will affect future projects more so than current projects (i.e. this problem wont simply
'go away'). What would happen if every jar did this???? What if the JRE did
this????
Please remove these classes from the artifact, and please include them in the maven
pom.xml as dependencies (this allows an easy <exclusion> for maven users to fix the
slf4j collision).
Warning (using 1.1.7, but 2.0.0.Alpha contains the same classes):
{{
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/slf4j-jdk14-1.6.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/C:/dev/workspace/workspace3.7/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/acme-project/WEB-INF/lib/weld-servlet-1.1.7.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
}}
--
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
4635
days inactive
4635
days old
9 comments
3 participants
participants (3)
-
Ales Justin (JIRA) -
Andrew Hughes (JIRA)
-
Ceki Gulcu (JIRA)