[
https://issues.apache.org/jira/browse/S2GRAPH-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563445#comment-15563445
]
Jong Wook Kim commented on S2GRAPH-117:
---------------------------------------
just a clarification about the confusion about netty,
—
Netty 3.x is an old but stable library. It used to come as “org.jboss.netty”
group id until like 2013 (netty 3.2), but after that they parted with JBoss and
changed to “io.netty” starting 3.3.
So it is best to avoid the “org.jboss.netty” dependency to prevent the old 3.2
overriding the newer one, since it (confusingly) still uses org.jboss.netty as
its java package.
Another complication is that [Netty broke some backward compatibility in
3.10|http://netty.io/news/2014/12/17/3-9-6-Final-and-3-10-0-Final.html], making
some old libraries calling deprecated methods spit some NoSuchMethodError or
something.
So about netty 3: use 3.9.x, avoid 3.10 and org.jboss.netty group id.
—
Then Netty 4.0 came out with the shiny new interfaces, using the same group ID
io.netty but different artifact id: anything other than “netty”, AND now really
using the java package “io.netty”.
Using different package it prevents the version conflicts from the libraries
using Netty 3.x, and we can use Netty 3.x and 4.x concurrently in a JVM, as we
are now.
They release two types of artifacts, netty-all that is a single jar that
contains all functionalities of Netty, like netty 3.x, and individual jars that
are more modular for the people who care about that.
Previously our dependencies including HBase and Play using Netty 4.x were
dependent on netty-all, but Play 2.5 is now dependent on the modular jars.
So in our package netty-all (4.0.33) and netty-(others) (4.0.41) were both
present, but it is not much of a problem, since when I even did “rm
netty*4.0.41*”, the server was running without producing NoSuchMethodError.
Later on, we may want to use only one of netty-all or netty-(others), but for
now having both is not much of a problem I guess.
Please update if you could reproduce the error.
JW
> Cleaner logging library usage
> -----------------------------
>
> Key: S2GRAPH-117
> URL: https://issues.apache.org/jira/browse/S2GRAPH-117
> Project: S2Graph
> Issue Type: Improvement
> Reporter: Jong Wook Kim
> Assignee: DOYUNG YOON
> Fix For: 0.1.0
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> Our SBT project is currently dependent on both log4j and logback, while using
> two logging backends is not ideal.
> Furthermore, there has been report that in some configuration we have both
> slf4j-log4j12 and log4j-over-slf4j in the classpath which leads to
> StackOverflowError.
> The current codebase is not written with a clean usage of logging library in
> mind, and I propose the following improvements to make our logging usage
> conform with the de-facto standard of slf4j.
> - Figure out how the dependencies are using slf4j, log4j, and logback.
> - Use slf4j-api everywhere, named with the fully qualified class names.
> - Exclude slf4j backends from the library projects
> - Add either log4j or logback backends to the application projects,
> preferably log4j.
> - Add a test case checking that the classpath has the correct configuration
> of jars.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
