You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anthony Baker <ab...@pivotal.io> on 2016/04/07 07:51:07 UTC
Bundled jar dependencies
Here’s a comparison of the bundled jar dependencies present in the binary distribution from the M1 release versus the current develop branch. The good news is there aren’t that many changes despite lots of build refactoring and new source code in pulse / modules / wan / cq.
If you see something that looks wrong, please speak up. I see a possible version conflict on sl4j.
Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines license.M1/M1-jars license.M2/M2-jars
activation-1.1.1.jar | activation-1.1.jar
> commons-beanutils-1.8.3.jar
> commons-collections-3.2.2.jar
> commons-digester-2.1.jar
commons-logging-1.1.1.jar | commons-logging-1.2.jar
hbase-0.94.27.jar <
jgroups-3.6.6.Final.jar | jgroups-3.6.7.Final.jar
> servlet-api-2.5.jar
> slf4j-api-1.7.12.jar
> slf4j-jdk14-1.7.7.jar
spring-aop-3.2.12.RELEASE.jar | spring-aop-4.2.4.RELEASE.jar
spring-aspects-3.2.12.RELEASE.jar | spring-aspects-4.2.4.RELEASE.jar
spring-beans-3.2.12.RELEASE.jar | spring-beans-4.2.4.RELEASE.jar
spring-context-3.2.12.RELEASE.jar | spring-context-4.2.4.RELEASE.jar
spring-context-support-3.2.12.RELEASE.jar | spring-context-support-4.2.4.RELEASE.jar
spring-core-3.2.12.RELEASE.jar | spring-core-4.2.4.RELEASE.jar
spring-data-gemfire-1.5.1.RELEASE.jar | spring-data-gemfire-1.7.2.RELEASE.jar
spring-expression-3.2.12.RELEASE.jar | spring-expression-4.2.4.RELEASE.jar
spring-oxm-3.2.12.RELEASE.jar | spring-ldap-core-1.3.2.RELEASE.jar
> spring-oxm-4.2.4.RELEASE.jar
> spring-security-config-3.1.7.RELEASE.jar
> spring-security-core-3.1.7.RELEASE.jar
> spring-security-ldap-3.1.7.RELEASE.jar
> spring-security-web-3.1.7.RELEASE.jar
spring-tx-3.2.12.RELEASE.jar | spring-tx-4.2.4.RELEASE.jar
spring-web-3.2.12.RELEASE.jar | spring-web-4.2.4.RELEASE.jar
spring-webmvc-3.2.12.RELEASE.jar | spring-webmvc-4.2.4.RELEASE.jar
Anthony
Re: Bundled jar dependencies
Posted by Dan Smith <ds...@pivotal.io>.
I think these gfsh failures were caused by my changes for GEODE-1025. By
removing the rest of the spring jars from the geode-core depencies, we
reverted to using the version of spring-core that spring-shell depends on.
I have a fix to force the version of spring core to be 4.2.4:
https://reviews.apache.org/r/45945/
-Dan
On Fri, Apr 8, 2016 at 11:52 AM, Swapnil Bawaskar <sb...@pivotal.io>
wrote:
> With the latest revision: dd9e5af4b4324e5511d170238f6532217384e15b
> I can't even start gfsh. I get this message:
>
> $ ./bin/gfsh
> Required (Spring Core) libraries not found in the classpath. gfsh can't
> start.
>
> On Fri, Apr 8, 2016 at 11:00 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > Looks like the error is due to the fact that geode-dependencies.jar and
> > gfsh-dependencies.jar includes both spring-core versions in it's
> classpath,
> > and it fails to find ResolvableTypeProvider.java which only exists in the
> > later version. I tried turning off the transitive dependency of
> > spring-shell, and only include the spring-core-4.2.4.RELEASE in the
> > classpath, then the locator started with no errors.
> >
> > On Fri, Apr 8, 2016 at 10:00 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> >
> > > On a similar note, I just did a pull from develop and ran a clean
> > > installDist. When I tried to start a locator in GFSH, I got the
> > following
> > > error in the log file:
> > >
> > > [error 2016/04/08 09:53:12.979 PDT locator1 <locator request thread[1]>
> > > tid=0x27] Jmx manager could not be started because HTTP service failed
> to
> > > start
> > >
> > > com.gemstone.gemfire.management.ManagementException: HTTP service
> failed
> > > to start
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:279)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.management.internal.ManagementAgent.startAgent(ManagementAgent.java:125)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.management.internal.SystemManagementService.startManager(SystemManagementService.java:475)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.management.internal.JmxManagerLocator.findJmxManager(JmxManagerLocator.java:104)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.management.internal.JmxManagerLocator.processRequest(JmxManagerLocator.java:57)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1328)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.distributed.internal.tcpserver.TcpServer$3.run(TcpServer.java:386)
> > >
> > > at
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > >
> > > at
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > >
> > > at java.lang.Thread.run(Thread.java:745)
> > >
> > > Caused by: MultiException[java.lang.NoClassDefFoundError:
> > > org/springframework/core/ResolvableTypeProvider,
> java.net.BindException:
> > > Address already in use]
> > >
> > > at org.eclipse.jetty.server.Server.doStart(Server.java:347)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.management.internal.JettyHelper.startJetty(JettyHelper.java:147)
> > >
> > > at
> > >
> >
> com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:251)
> > >
> > > ... 9 more
> > >
> > > Suppressed: java.net.BindException: Address already in use
> > >
> > > at sun.nio.ch.Net.bind0(Native Method)
> > >
> > > at sun.nio.ch.Net.bind(Net.java:433)
> > >
> > > at sun.nio.ch.Net.bind(Net.java:425)
> > >
> > > at
> > >
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> > >
> > > at
> > > sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> > >
> > > at
> > > org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> > >
> > > at
> > org.eclipse.jetty.server.Server.doStart(Server.java:384)
> > >
> > > ... 12 more
> > >
> > > Caused by: java.lang.NoClassDefFoundError:
> > > org/springframework/core/ResolvableTypeProvider
> > >
> > > at java.lang.ClassLoader.defineClass1(Native Method)
> > >
> > > at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> > >
> > > at
> > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> > >
> > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> > >
> > > at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> > >
> > > at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> > >
> > > at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> > >
> > > at java.security.AccessController.doPrivileged(Native Method)
> > >
> > > at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.findClass(WebAppClassLoader.java:549)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:475)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
> > >
> > > at java.lang.Class.getDeclaredConstructors0(Native Method)
> > >
> > > at
> > java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
> > >
> > > at java.lang.Class.getConstructor0(Class.java:3075)
> > >
> > > at java.lang.Class.getDeclaredConstructor(Class.java:2178)
> > >
> > > at
> > >
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:104)
> > >
> > > at
> > >
> >
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:628)
> > >
> > > at
> > >
> >
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:682)
> > >
> > > at
> > >
> >
> org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:553)
> > >
> > > at
> > >
> >
> org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:494)
> > >
> > > at
> > >
> >
> org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
> > >
> > > at javax.servlet.GenericServlet.init(GenericServlet.java:244)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:626)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:405)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:875)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:346)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1379)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1341)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:259)
> > >
> > > at
> > > org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:517)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> > >
> > > at org.eclipse.jetty.server.Server.start(Server.java:405)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> > >
> > > at org.eclipse.jetty.server.Server.doStart(Server.java:372)
> > >
> > > ... 12 more
> > >
> > > Caused by: java.lang.ClassNotFoundException:
> > > org.springframework.core.ResolvableTypeProvider
> > >
> > > at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> > >
> > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> > >
> > > at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> > >
> > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:487)
> > >
> > > at
> > >
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
> > >
> > > ... 54 more
> > >
> > > On Fri, Apr 8, 2016 at 6:35 AM, Anthony Baker <ab...@pivotal.io>
> wrote:
> > >
> > >> For comparison, here’s the classpath from the M1 release:
> > >>
> > >> Manifest-Version: 1.0
> > >> Created-By: abaker
> > >> Title: gemfire
> > >> Version: 1.0.0-incubating.M1
> > >> Organization: Apache Software Foundation (ASF)
> > >> Class-Path: gemfire-common-1.0.0-incubating.M1.jar gemfire-json-1.0.0-
> > >> incubating.M1.jar gemfire-joptsimple-1.0.0-incubating.M1.jar gemfire-
> > >> core-1.0.0-incubating.M1.jar gemfire-lucene-1.0.0-incubating.M1.jar s
> > >> pring-core-3.2.12.RELEASE.jar jgroups-3.6.6.Final.jar antlr-2.7.7.jar
> > >> jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar jackson-databin
> > >> d-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar commons-logging-1
> > >> .1.1.jar netty-all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-
> > >> api-1.7.jar javax.servlet-api-3.1.0.jar javax.transaction-api-1.2.jar
> > >> jna-4.0.0.jar jline-2.12.jar hbase-0.94.27.jar log4j-api-2.5.jar log
> > >> 4j-core-2.5.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6.v201511
> > >> 06.jar jetty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v2015110
> > >> 6.jar jetty-servlet-9.3.6.v20151106.jar jetty-util-9.3.6.v20151106.ja
> > >> r jetty-webapp-9.3.6.v20151106.jar jetty-xml-9.3.6.v20151106.jar jans
> > >> i-1.8.jar slf4j-api-1.7.7.jar spring-shell-1.1.0.RELEASE.jar snappy-j
> > >> ava-1.1.1.6.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-
> > >> 2.5.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.jar lucen
> > >> e-queries-5.3.0.jar lucene-queryparser-5.3.0.jar
> > >>
> > >> The spring-core jar is not present on the classpath at all, despite
> > >> having a bunch of spring jars in the lib dir !!
> > >>
> > >> Anthony-Baker-MacBook-Pro:lib abaker$ ls -1 spring*
> > >> spring-aop-3.2.12.RELEASE.jar
> > >> spring-beans-3.2.12.RELEASE.jar
> > >> spring-context-3.2.12.RELEASE.jar
> > >> spring-context-support-3.2.12.RELEASE.jar
> > >> spring-core-3.2.12.RELEASE.jar
> > >> spring-data-commons-1.9.1.RELEASE.jar
> > >> spring-data-gemfire-1.5.1.RELEASE.jar
> > >> spring-expression-3.2.12.RELEASE.jar
> > >> spring-shell-1.1.0.RELEASE.jar
> > >> spring-tx-3.2.12.RELEASE.jar
> > >> spring-web-3.2.12.RELEASE.jar
> > >> spring-webmvc-3.2.12.RELEASE.jar
> > >>
> > >> Back to the original question: spring-shell-1.1.0 depends on
> > >> spring-core-4.0.3.RELEASE while other usages in geode rely on
> > >> spring-core-4.2.4.RELEASE. Is this ok?
> > >>
> > >> Anthony
> > >>
> > >>
> > >> > On Apr 8, 2016, at 6:12 AM, Anthony Baker <ab...@pivotal.io>
> wrote:
> > >> >
> > >> > After an update I’m seeing a conflict on spring-core. Here’s the
> > >> geode-dependencies classpath with both versions of spring-core:
> > >> >
> > >> > Class-Path: geode-common-1.0.0-incubating.M2-SNAPSHOT.jar
> geode-json-1
> > >> > .0.0-incubating.M2-SNAPSHOT.jar
> geode-joptsimple-1.0.0-incubating.M2-
> > >> > SNAPSHOT.jar geode-core-1.0.0-incubating.M2-SNAPSHOT.jar
> geode-lucene
> > >> > -1.0.0-incubating.M2-SNAPSHOT.jar
> geode-pulse-1.0.0-incubating.M2-SNA
> > >> > PSHOT.jar geode-wan-1.0.0-incubating.M2-SNAPSHOT.jar
> geode-cq-1.0.0-i
> > >> > ncubating.M2-SNAPSHOT.jar jgroups-3.6.7.Final.jar antlr-2.7.7.jar
> jac
> > >> > kson-databind-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar
> netty
> > >> > -all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-api-1.7.jar
> jn
> > >> > a-4.0.0.jar log4j-api-2.5.jar log4j-core-2.5.jar
> jetty-webapp-9.3.6.v
> > >> > 20151106.jar spring-shell-1.1.0.RELEASE.jar snappy-java-1.1.1.6.jar
> j
> > >> > ansi-1.8.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar
> log4j-jul-2.5
> > >> > .jar jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar
> javax.trans
> > >> > action-api-1.2.jar jetty-xml-9.3.6.v20151106.jar
> jetty-servlet-9.3.6.
> > >> > v20151106.jar jline-2.12.jar spring-core-4.0.3.RELEASE.jar
> slf4j-api-
> > >> > 1.7.12.jar commons-logging-1.2.jar jetty-util-9.3.6.v20151106.jar
> jet
> > >> > ty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v20151106.jar
> java
> > >> > x.servlet-api-3.1.0.jar jetty-http-9.3.6.v20151106.jar
> jetty-io-9.3.6
> > >> > .v20151106.jar lucene-analyzers-common-5.3.0.jar
> lucene-core-5.3.0.ja
> > >> > r lucene-queries-5.3.0.jar lucene-queryparser-5.3.0.jar
> spring-core-4
> > >> > .2.4.RELEASE.jar
> > >> >
> > >> > The older version is pulled in transitively:
> > >> >
> > >> > Anthony-Baker-MacBook-Pro:geode-core abaker$ gradle
> dependencyInsight
> > >> --dependency spring-core
> > >> > :geode-core:dependencyInsight
> > >> > org.springframework:spring-core:4.0.3.RELEASE
> > >> > \--- org.springframework.shell:spring-shell:1.1.0.RELEASE
> > >> > \— compile
> > >> >
> > >> > Here’s at least subproject that uses the version from
> > >> dependency-versions.properties:
> > >> >
> > >> > Anthony-Baker-MacBook-Pro:geode-rebalancer abaker$ gradle
> > >> dependencyInsight --dependency spring-core
> > >> > :geode-rebalancer:dependencyInsight
> > >> > org.springframework:spring-core:4.2.4.RELEASE
> > >> > +--- org.springframework:spring-aop:4.2.4.RELEASE
> > >> > | \--- org.springframework:spring-context:4.2.4.RELEASE
> > >> > | \--- compile
> > >> > +--- org.springframework:spring-beans:4.2.4.RELEASE
> > >> > | +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> > >> > | \--- org.springframework:spring-aop:4.2.4.RELEASE (*)
> > >> > +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> > >> > \--- org.springframework:spring-expression:4.2.4.RELEASE
> > >> > \--- org.springframework:spring-context:4.2.4.RELEASE (*)
> > >> >
> > >> > Anthony
> > >> >
> > >> >
> > >> >> On Apr 7, 2016, at 4:13 PM, Dan Smith <ds...@pivotal.io> wrote:
> > >> >>
> > >> >> 3 of these dependencies should now be gone with the changes for
> > >> GEODE-1025.
> > >> >> spring-context-support
> > >> >> spring-data-gemfire
> > >> >> spring-data-commons
> > >> >>
> > >> >> BTW, if you want to see the list of jars we ship, there's a handy
> > >> gradle
> > >> >> task I added. It will show you what is in each war file as well as
> > the
> > >> lib
> > >> >> directory:
> > >> >>
> > >> >> ./gradlew dumpInstalledJars
> > >> >>
> > >> >> On Thu, Apr 7, 2016 at 10:50 AM, Anthony Baker <ab...@pivotal.io>
> > >> wrote:
> > >> >>
> > >> >>> Added JIRA:
> > >> >>> https://issues.apache.org/jira/browse/GEODE-1193
> > >> >>>
> > >> >>> Anthony
> > >> >>>
> > >> >>>> On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io>
> wrote:
> > >> >>>>
> > >> >>>> The reason that the servlet API jar is included is because it
> gets
> > >> used
> > >> >>> on
> > >> >>>> the server classpath (where the sessions are stored). I'm going
> > >> through
> > >> >>> the
> > >> >>>> Modules docs now, so we should be able to direct users to use the
> > >> servlet
> > >> >>>> jar provided by the container. We should be OK not to ship it.
> > >> >>>>
> > >> >>>> --Jens
> > >> >>>>
> > >> >>>> On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io>
> > wrote:
> > >> >>>>
> > >> >>>>> I would not include the (javax.)servlet-api JAR with Geode. It
> > will
> > >> be a
> > >> >>>>> significant pain point for web applications (and frameworks,
> e.g.
> > >> >>> *Spring
> > >> >>>>> Session*) that expect a specific version of the Servlet API and
> > then
> > >> >>>>> suddenly encounter conflicting versions.
> > >> >>>>>
> > >> >>>>> Also, FYI, the latest release of the core *Spring Framework
> > >> >>>>> <http://projects.spring.io/spring-framework/>* [1] is now
> > >> >>> 4.2.5.RELEASE.
> > >> >>>>> The latest *Spring Security <
> > >> http://projects.spring.io/spring-security/
> > >> >>>> *
> > >> >>>>> [2]
> > >> >>>>> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9;
> > the
> > >> >>> *Spring
> > >> >>>>> Security* version used by Geode (3.1.x) is not even supported
> any
> > >> more.
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> [1] http://projects.spring.io/spring-framework/
> > >> >>>>> [2] http://projects.spring.io/spring-security/
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <
> abaker@pivotal.io>
> > >> >>> wrote:
> > >> >>>>>
> > >> >>>>>> You can’t tell from the diff below but it turns out we’re
> > >> including two
> > >> >>>>>> versions of servlet-api:
> > >> >>>>>>
> > >> >>>>>> servlet-api-2.5.jar
> > >> >>>>>> javax.servlet-api-3.1.0.jar
> > >> >>>>>>
> > >> >>>>>> Version 3.1.0 is from the geode/lib while the older jar is from
> > >> the app
> > >> >>>>>> server module. Do we need to ship these at all since they are
> > only
> > >> >>>>> needed
> > >> >>>>>> for compiling?
> > >> >>>>>>
> > >> >>>>>> Anthony
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <abaker@pivotal.io
> >
> > >> wrote:
> > >> >>>>>>>
> > >> >>>>>>> Here’s a comparison of the bundled jar dependencies present in
> > the
> > >> >>>>>> binary distribution from the M1 release versus the current
> > develop
> > >> >>>>> branch.
> > >> >>>>>> The good news is there aren’t that many changes despite lots of
> > >> build
> > >> >>>>>> refactoring and new source code in pulse / modules / wan / cq.
> > >> >>>>>>>
> > >> >>>>>>> If you see something that looks wrong, please speak up. I
> see a
> > >> >>>>>> possible version conflict on sl4j.
> > >> >>>>>>>
> > >> >>>>>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y
> > >> --suppress-common-lines
> > >> >>>>>> license.M1/M1-jars license.M2/M2-jars
> > >> >>>>>>> activation-1.1.1.jar |
> > >> >>>>>> activation-1.1.jar
> > >> >>>>>>>>
> > >> >>>>>> commons-beanutils-1.8.3.jar
> > >> >>>>>>>>
> > >> >>>>>> commons-collections-3.2.2.jar
> > >> >>>>>>>>
> > >> >>>>>> commons-digester-2.1.jar
> > >> >>>>>>> commons-logging-1.1.1.jar |
> > >> >>>>>> commons-logging-1.2.jar
> > >> >>>>>>> hbase-0.94.27.jar <
> > >> >>>>>>> jgroups-3.6.6.Final.jar
> > >> |
> > >> >>>>>> jgroups-3.6.7.Final.jar
> > >> >>>>>>>>
> > >> >>>>>> servlet-api-2.5.jar
> > >> >>>>>>>>
> > >> >>>>>> slf4j-api-1.7.12.jar
> > >> >>>>>>>>
> > >> >>>>>> slf4j-jdk14-1.7.7.jar
> > >> >>>>>>> spring-aop-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-aop-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-aspects-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-aspects-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-beans-3.2.12.RELEASE.jar
> > >> |
> > >> >>>>>> spring-beans-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-context-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-context-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-context-support-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-context-support-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-core-3.2.12.RELEASE.jar
> > >> |
> > >> >>>>>> spring-core-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-data-gemfire-1.5.1.RELEASE.jar |
> > >> >>>>>> spring-data-gemfire-1.7.2.RELEASE.jar
> > >> >>>>>>> spring-expression-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-expression-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-oxm-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-ldap-core-1.3.2.RELEASE.jar
> > >> >>>>>>>>
> > >> >>>>>> spring-oxm-4.2.4.RELEASE.jar
> > >> >>>>>>>>
> > >> >>>>>> spring-security-config-3.1.7.RELEASE.jar
> > >> >>>>>>>>
> > >> >>>>>> spring-security-core-3.1.7.RELEASE.jar
> > >> >>>>>>>>
> > >> >>>>>> spring-security-ldap-3.1.7.RELEASE.jar
> > >> >>>>>>>>
> > >> >>>>>> spring-security-web-3.1.7.RELEASE.jar
> > >> >>>>>>> spring-tx-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-tx-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-web-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-web-4.2.4.RELEASE.jar
> > >> >>>>>>> spring-webmvc-3.2.12.RELEASE.jar |
> > >> >>>>>> spring-webmvc-4.2.4.RELEASE.jar
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> Anthony
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> --
> > >> >>>>> -John
> > >> >>>>> 503-504-8657
> > >> >>>>> john.blum10101 (skype)
> > >> >>>>>
> > >> >>>
> > >> >>>
> > >> >
> > >>
> > >>
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
Re: Bundled jar dependencies
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
With the latest revision: dd9e5af4b4324e5511d170238f6532217384e15b
I can't even start gfsh. I get this message:
$ ./bin/gfsh
Required (Spring Core) libraries not found in the classpath. gfsh can't
start.
On Fri, Apr 8, 2016 at 11:00 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> Looks like the error is due to the fact that geode-dependencies.jar and
> gfsh-dependencies.jar includes both spring-core versions in it's classpath,
> and it fails to find ResolvableTypeProvider.java which only exists in the
> later version. I tried turning off the transitive dependency of
> spring-shell, and only include the spring-core-4.2.4.RELEASE in the
> classpath, then the locator started with no errors.
>
> On Fri, Apr 8, 2016 at 10:00 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > On a similar note, I just did a pull from develop and ran a clean
> > installDist. When I tried to start a locator in GFSH, I got the
> following
> > error in the log file:
> >
> > [error 2016/04/08 09:53:12.979 PDT locator1 <locator request thread[1]>
> > tid=0x27] Jmx manager could not be started because HTTP service failed to
> > start
> >
> > com.gemstone.gemfire.management.ManagementException: HTTP service failed
> > to start
> >
> > at
> >
> com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:279)
> >
> > at
> >
> com.gemstone.gemfire.management.internal.ManagementAgent.startAgent(ManagementAgent.java:125)
> >
> > at
> >
> com.gemstone.gemfire.management.internal.SystemManagementService.startManager(SystemManagementService.java:475)
> >
> > at
> >
> com.gemstone.gemfire.management.internal.JmxManagerLocator.findJmxManager(JmxManagerLocator.java:104)
> >
> > at
> >
> com.gemstone.gemfire.management.internal.JmxManagerLocator.processRequest(JmxManagerLocator.java:57)
> >
> > at
> >
> com.gemstone.gemfire.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1328)
> >
> > at
> >
> com.gemstone.gemfire.distributed.internal.tcpserver.TcpServer$3.run(TcpServer.java:386)
> >
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >
> > at java.lang.Thread.run(Thread.java:745)
> >
> > Caused by: MultiException[java.lang.NoClassDefFoundError:
> > org/springframework/core/ResolvableTypeProvider, java.net.BindException:
> > Address already in use]
> >
> > at org.eclipse.jetty.server.Server.doStart(Server.java:347)
> >
> > at
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> >
> > at
> >
> com.gemstone.gemfire.management.internal.JettyHelper.startJetty(JettyHelper.java:147)
> >
> > at
> >
> com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:251)
> >
> > ... 9 more
> >
> > Suppressed: java.net.BindException: Address already in use
> >
> > at sun.nio.ch.Net.bind0(Native Method)
> >
> > at sun.nio.ch.Net.bind(Net.java:433)
> >
> > at sun.nio.ch.Net.bind(Net.java:425)
> >
> > at
> > sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> >
> > at
> > sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> >
> > at
> > org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326)
> >
> > at
> >
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
> >
> > at
> >
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244)
> >
> > at
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> >
> > at
> org.eclipse.jetty.server.Server.doStart(Server.java:384)
> >
> > ... 12 more
> >
> > Caused by: java.lang.NoClassDefFoundError:
> > org/springframework/core/ResolvableTypeProvider
> >
> > at java.lang.ClassLoader.defineClass1(Native Method)
> >
> > at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> >
> > at
> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> >
> > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> >
> > at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> >
> > at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> >
> > at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> >
> > at java.security.AccessController.doPrivileged(Native Method)
> >
> > at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> >
> > at
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.findClass(WebAppClassLoader.java:549)
> >
> > at
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:475)
> >
> > at
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
> >
> > at java.lang.Class.getDeclaredConstructors0(Native Method)
> >
> > at
> java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
> >
> > at java.lang.Class.getConstructor0(Class.java:3075)
> >
> > at java.lang.Class.getDeclaredConstructor(Class.java:2178)
> >
> > at
> > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:104)
> >
> > at
> >
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:628)
> >
> > at
> >
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:682)
> >
> > at
> >
> org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:553)
> >
> > at
> >
> org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:494)
> >
> > at
> >
> org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
> >
> > at javax.servlet.GenericServlet.init(GenericServlet.java:244)
> >
> > at
> >
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:626)
> >
> > at
> >
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:405)
> >
> > at
> >
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:875)
> >
> > at
> >
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:346)
> >
> > at
> >
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1379)
> >
> > at
> >
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1341)
> >
> > at
> >
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
> >
> > at
> >
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:259)
> >
> > at
> > org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:517)
> >
> > at
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> >
> > at
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> >
> > at
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
> >
> > at
> >
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> >
> > at
> >
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> >
> > at
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
> >
> > at org.eclipse.jetty.server.Server.start(Server.java:405)
> >
> > at
> >
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
> >
> > at
> >
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
> >
> > at org.eclipse.jetty.server.Server.doStart(Server.java:372)
> >
> > ... 12 more
> >
> > Caused by: java.lang.ClassNotFoundException:
> > org.springframework.core.ResolvableTypeProvider
> >
> > at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> >
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> >
> > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> >
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> >
> > at
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:487)
> >
> > at
> >
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
> >
> > ... 54 more
> >
> > On Fri, Apr 8, 2016 at 6:35 AM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> >> For comparison, here’s the classpath from the M1 release:
> >>
> >> Manifest-Version: 1.0
> >> Created-By: abaker
> >> Title: gemfire
> >> Version: 1.0.0-incubating.M1
> >> Organization: Apache Software Foundation (ASF)
> >> Class-Path: gemfire-common-1.0.0-incubating.M1.jar gemfire-json-1.0.0-
> >> incubating.M1.jar gemfire-joptsimple-1.0.0-incubating.M1.jar gemfire-
> >> core-1.0.0-incubating.M1.jar gemfire-lucene-1.0.0-incubating.M1.jar s
> >> pring-core-3.2.12.RELEASE.jar jgroups-3.6.6.Final.jar antlr-2.7.7.jar
> >> jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar jackson-databin
> >> d-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar commons-logging-1
> >> .1.1.jar netty-all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-
> >> api-1.7.jar javax.servlet-api-3.1.0.jar javax.transaction-api-1.2.jar
> >> jna-4.0.0.jar jline-2.12.jar hbase-0.94.27.jar log4j-api-2.5.jar log
> >> 4j-core-2.5.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6.v201511
> >> 06.jar jetty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v2015110
> >> 6.jar jetty-servlet-9.3.6.v20151106.jar jetty-util-9.3.6.v20151106.ja
> >> r jetty-webapp-9.3.6.v20151106.jar jetty-xml-9.3.6.v20151106.jar jans
> >> i-1.8.jar slf4j-api-1.7.7.jar spring-shell-1.1.0.RELEASE.jar snappy-j
> >> ava-1.1.1.6.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-
> >> 2.5.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.jar lucen
> >> e-queries-5.3.0.jar lucene-queryparser-5.3.0.jar
> >>
> >> The spring-core jar is not present on the classpath at all, despite
> >> having a bunch of spring jars in the lib dir !!
> >>
> >> Anthony-Baker-MacBook-Pro:lib abaker$ ls -1 spring*
> >> spring-aop-3.2.12.RELEASE.jar
> >> spring-beans-3.2.12.RELEASE.jar
> >> spring-context-3.2.12.RELEASE.jar
> >> spring-context-support-3.2.12.RELEASE.jar
> >> spring-core-3.2.12.RELEASE.jar
> >> spring-data-commons-1.9.1.RELEASE.jar
> >> spring-data-gemfire-1.5.1.RELEASE.jar
> >> spring-expression-3.2.12.RELEASE.jar
> >> spring-shell-1.1.0.RELEASE.jar
> >> spring-tx-3.2.12.RELEASE.jar
> >> spring-web-3.2.12.RELEASE.jar
> >> spring-webmvc-3.2.12.RELEASE.jar
> >>
> >> Back to the original question: spring-shell-1.1.0 depends on
> >> spring-core-4.0.3.RELEASE while other usages in geode rely on
> >> spring-core-4.2.4.RELEASE. Is this ok?
> >>
> >> Anthony
> >>
> >>
> >> > On Apr 8, 2016, at 6:12 AM, Anthony Baker <ab...@pivotal.io> wrote:
> >> >
> >> > After an update I’m seeing a conflict on spring-core. Here’s the
> >> geode-dependencies classpath with both versions of spring-core:
> >> >
> >> > Class-Path: geode-common-1.0.0-incubating.M2-SNAPSHOT.jar geode-json-1
> >> > .0.0-incubating.M2-SNAPSHOT.jar geode-joptsimple-1.0.0-incubating.M2-
> >> > SNAPSHOT.jar geode-core-1.0.0-incubating.M2-SNAPSHOT.jar geode-lucene
> >> > -1.0.0-incubating.M2-SNAPSHOT.jar geode-pulse-1.0.0-incubating.M2-SNA
> >> > PSHOT.jar geode-wan-1.0.0-incubating.M2-SNAPSHOT.jar geode-cq-1.0.0-i
> >> > ncubating.M2-SNAPSHOT.jar jgroups-3.6.7.Final.jar antlr-2.7.7.jar jac
> >> > kson-databind-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar netty
> >> > -all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-api-1.7.jar jn
> >> > a-4.0.0.jar log4j-api-2.5.jar log4j-core-2.5.jar jetty-webapp-9.3.6.v
> >> > 20151106.jar spring-shell-1.1.0.RELEASE.jar snappy-java-1.1.1.6.jar j
> >> > ansi-1.8.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-2.5
> >> > .jar jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar javax.trans
> >> > action-api-1.2.jar jetty-xml-9.3.6.v20151106.jar jetty-servlet-9.3.6.
> >> > v20151106.jar jline-2.12.jar spring-core-4.0.3.RELEASE.jar slf4j-api-
> >> > 1.7.12.jar commons-logging-1.2.jar jetty-util-9.3.6.v20151106.jar jet
> >> > ty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v20151106.jar java
> >> > x.servlet-api-3.1.0.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6
> >> > .v20151106.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.ja
> >> > r lucene-queries-5.3.0.jar lucene-queryparser-5.3.0.jar spring-core-4
> >> > .2.4.RELEASE.jar
> >> >
> >> > The older version is pulled in transitively:
> >> >
> >> > Anthony-Baker-MacBook-Pro:geode-core abaker$ gradle dependencyInsight
> >> --dependency spring-core
> >> > :geode-core:dependencyInsight
> >> > org.springframework:spring-core:4.0.3.RELEASE
> >> > \--- org.springframework.shell:spring-shell:1.1.0.RELEASE
> >> > \— compile
> >> >
> >> > Here’s at least subproject that uses the version from
> >> dependency-versions.properties:
> >> >
> >> > Anthony-Baker-MacBook-Pro:geode-rebalancer abaker$ gradle
> >> dependencyInsight --dependency spring-core
> >> > :geode-rebalancer:dependencyInsight
> >> > org.springframework:spring-core:4.2.4.RELEASE
> >> > +--- org.springframework:spring-aop:4.2.4.RELEASE
> >> > | \--- org.springframework:spring-context:4.2.4.RELEASE
> >> > | \--- compile
> >> > +--- org.springframework:spring-beans:4.2.4.RELEASE
> >> > | +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> >> > | \--- org.springframework:spring-aop:4.2.4.RELEASE (*)
> >> > +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> >> > \--- org.springframework:spring-expression:4.2.4.RELEASE
> >> > \--- org.springframework:spring-context:4.2.4.RELEASE (*)
> >> >
> >> > Anthony
> >> >
> >> >
> >> >> On Apr 7, 2016, at 4:13 PM, Dan Smith <ds...@pivotal.io> wrote:
> >> >>
> >> >> 3 of these dependencies should now be gone with the changes for
> >> GEODE-1025.
> >> >> spring-context-support
> >> >> spring-data-gemfire
> >> >> spring-data-commons
> >> >>
> >> >> BTW, if you want to see the list of jars we ship, there's a handy
> >> gradle
> >> >> task I added. It will show you what is in each war file as well as
> the
> >> lib
> >> >> directory:
> >> >>
> >> >> ./gradlew dumpInstalledJars
> >> >>
> >> >> On Thu, Apr 7, 2016 at 10:50 AM, Anthony Baker <ab...@pivotal.io>
> >> wrote:
> >> >>
> >> >>> Added JIRA:
> >> >>> https://issues.apache.org/jira/browse/GEODE-1193
> >> >>>
> >> >>> Anthony
> >> >>>
> >> >>>> On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io> wrote:
> >> >>>>
> >> >>>> The reason that the servlet API jar is included is because it gets
> >> used
> >> >>> on
> >> >>>> the server classpath (where the sessions are stored). I'm going
> >> through
> >> >>> the
> >> >>>> Modules docs now, so we should be able to direct users to use the
> >> servlet
> >> >>>> jar provided by the container. We should be OK not to ship it.
> >> >>>>
> >> >>>> --Jens
> >> >>>>
> >> >>>> On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io>
> wrote:
> >> >>>>
> >> >>>>> I would not include the (javax.)servlet-api JAR with Geode. It
> will
> >> be a
> >> >>>>> significant pain point for web applications (and frameworks, e.g.
> >> >>> *Spring
> >> >>>>> Session*) that expect a specific version of the Servlet API and
> then
> >> >>>>> suddenly encounter conflicting versions.
> >> >>>>>
> >> >>>>> Also, FYI, the latest release of the core *Spring Framework
> >> >>>>> <http://projects.spring.io/spring-framework/>* [1] is now
> >> >>> 4.2.5.RELEASE.
> >> >>>>> The latest *Spring Security <
> >> http://projects.spring.io/spring-security/
> >> >>>> *
> >> >>>>> [2]
> >> >>>>> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9;
> the
> >> >>> *Spring
> >> >>>>> Security* version used by Geode (3.1.x) is not even supported any
> >> more.
> >> >>>>>
> >> >>>>>
> >> >>>>> [1] http://projects.spring.io/spring-framework/
> >> >>>>> [2] http://projects.spring.io/spring-security/
> >> >>>>>
> >> >>>>>
> >> >>>>> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io>
> >> >>> wrote:
> >> >>>>>
> >> >>>>>> You can’t tell from the diff below but it turns out we’re
> >> including two
> >> >>>>>> versions of servlet-api:
> >> >>>>>>
> >> >>>>>> servlet-api-2.5.jar
> >> >>>>>> javax.servlet-api-3.1.0.jar
> >> >>>>>>
> >> >>>>>> Version 3.1.0 is from the geode/lib while the older jar is from
> >> the app
> >> >>>>>> server module. Do we need to ship these at all since they are
> only
> >> >>>>> needed
> >> >>>>>> for compiling?
> >> >>>>>>
> >> >>>>>> Anthony
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io>
> >> wrote:
> >> >>>>>>>
> >> >>>>>>> Here’s a comparison of the bundled jar dependencies present in
> the
> >> >>>>>> binary distribution from the M1 release versus the current
> develop
> >> >>>>> branch.
> >> >>>>>> The good news is there aren’t that many changes despite lots of
> >> build
> >> >>>>>> refactoring and new source code in pulse / modules / wan / cq.
> >> >>>>>>>
> >> >>>>>>> If you see something that looks wrong, please speak up. I see a
> >> >>>>>> possible version conflict on sl4j.
> >> >>>>>>>
> >> >>>>>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y
> >> --suppress-common-lines
> >> >>>>>> license.M1/M1-jars license.M2/M2-jars
> >> >>>>>>> activation-1.1.1.jar |
> >> >>>>>> activation-1.1.jar
> >> >>>>>>>>
> >> >>>>>> commons-beanutils-1.8.3.jar
> >> >>>>>>>>
> >> >>>>>> commons-collections-3.2.2.jar
> >> >>>>>>>>
> >> >>>>>> commons-digester-2.1.jar
> >> >>>>>>> commons-logging-1.1.1.jar |
> >> >>>>>> commons-logging-1.2.jar
> >> >>>>>>> hbase-0.94.27.jar <
> >> >>>>>>> jgroups-3.6.6.Final.jar
> >> |
> >> >>>>>> jgroups-3.6.7.Final.jar
> >> >>>>>>>>
> >> >>>>>> servlet-api-2.5.jar
> >> >>>>>>>>
> >> >>>>>> slf4j-api-1.7.12.jar
> >> >>>>>>>>
> >> >>>>>> slf4j-jdk14-1.7.7.jar
> >> >>>>>>> spring-aop-3.2.12.RELEASE.jar |
> >> >>>>>> spring-aop-4.2.4.RELEASE.jar
> >> >>>>>>> spring-aspects-3.2.12.RELEASE.jar |
> >> >>>>>> spring-aspects-4.2.4.RELEASE.jar
> >> >>>>>>> spring-beans-3.2.12.RELEASE.jar
> >> |
> >> >>>>>> spring-beans-4.2.4.RELEASE.jar
> >> >>>>>>> spring-context-3.2.12.RELEASE.jar |
> >> >>>>>> spring-context-4.2.4.RELEASE.jar
> >> >>>>>>> spring-context-support-3.2.12.RELEASE.jar |
> >> >>>>>> spring-context-support-4.2.4.RELEASE.jar
> >> >>>>>>> spring-core-3.2.12.RELEASE.jar
> >> |
> >> >>>>>> spring-core-4.2.4.RELEASE.jar
> >> >>>>>>> spring-data-gemfire-1.5.1.RELEASE.jar |
> >> >>>>>> spring-data-gemfire-1.7.2.RELEASE.jar
> >> >>>>>>> spring-expression-3.2.12.RELEASE.jar |
> >> >>>>>> spring-expression-4.2.4.RELEASE.jar
> >> >>>>>>> spring-oxm-3.2.12.RELEASE.jar |
> >> >>>>>> spring-ldap-core-1.3.2.RELEASE.jar
> >> >>>>>>>>
> >> >>>>>> spring-oxm-4.2.4.RELEASE.jar
> >> >>>>>>>>
> >> >>>>>> spring-security-config-3.1.7.RELEASE.jar
> >> >>>>>>>>
> >> >>>>>> spring-security-core-3.1.7.RELEASE.jar
> >> >>>>>>>>
> >> >>>>>> spring-security-ldap-3.1.7.RELEASE.jar
> >> >>>>>>>>
> >> >>>>>> spring-security-web-3.1.7.RELEASE.jar
> >> >>>>>>> spring-tx-3.2.12.RELEASE.jar |
> >> >>>>>> spring-tx-4.2.4.RELEASE.jar
> >> >>>>>>> spring-web-3.2.12.RELEASE.jar |
> >> >>>>>> spring-web-4.2.4.RELEASE.jar
> >> >>>>>>> spring-webmvc-3.2.12.RELEASE.jar |
> >> >>>>>> spring-webmvc-4.2.4.RELEASE.jar
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> Anthony
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> -John
> >> >>>>> 503-504-8657
> >> >>>>> john.blum10101 (skype)
> >> >>>>>
> >> >>>
> >> >>>
> >> >
> >>
> >>
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
>
> --
> Cheers
>
> Jinmei
>
Re: Bundled jar dependencies
Posted by Jinmei Liao <ji...@pivotal.io>.
Looks like the error is due to the fact that geode-dependencies.jar and
gfsh-dependencies.jar includes both spring-core versions in it's classpath,
and it fails to find ResolvableTypeProvider.java which only exists in the
later version. I tried turning off the transitive dependency of
spring-shell, and only include the spring-core-4.2.4.RELEASE in the
classpath, then the locator started with no errors.
On Fri, Apr 8, 2016 at 10:00 AM, Jinmei Liao <ji...@pivotal.io> wrote:
> On a similar note, I just did a pull from develop and ran a clean
> installDist. When I tried to start a locator in GFSH, I got the following
> error in the log file:
>
> [error 2016/04/08 09:53:12.979 PDT locator1 <locator request thread[1]>
> tid=0x27] Jmx manager could not be started because HTTP service failed to
> start
>
> com.gemstone.gemfire.management.ManagementException: HTTP service failed
> to start
>
> at
> com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:279)
>
> at
> com.gemstone.gemfire.management.internal.ManagementAgent.startAgent(ManagementAgent.java:125)
>
> at
> com.gemstone.gemfire.management.internal.SystemManagementService.startManager(SystemManagementService.java:475)
>
> at
> com.gemstone.gemfire.management.internal.JmxManagerLocator.findJmxManager(JmxManagerLocator.java:104)
>
> at
> com.gemstone.gemfire.management.internal.JmxManagerLocator.processRequest(JmxManagerLocator.java:57)
>
> at
> com.gemstone.gemfire.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1328)
>
> at
> com.gemstone.gemfire.distributed.internal.tcpserver.TcpServer$3.run(TcpServer.java:386)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> at java.lang.Thread.run(Thread.java:745)
>
> Caused by: MultiException[java.lang.NoClassDefFoundError:
> org/springframework/core/ResolvableTypeProvider, java.net.BindException:
> Address already in use]
>
> at org.eclipse.jetty.server.Server.doStart(Server.java:347)
>
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
>
> at
> com.gemstone.gemfire.management.internal.JettyHelper.startJetty(JettyHelper.java:147)
>
> at
> com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:251)
>
> ... 9 more
>
> Suppressed: java.net.BindException: Address already in use
>
> at sun.nio.ch.Net.bind0(Native Method)
>
> at sun.nio.ch.Net.bind(Net.java:433)
>
> at sun.nio.ch.Net.bind(Net.java:425)
>
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
>
> at
> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>
> at
> org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326)
>
> at
> org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
>
> at
> org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244)
>
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
>
> at org.eclipse.jetty.server.Server.doStart(Server.java:384)
>
> ... 12 more
>
> Caused by: java.lang.NoClassDefFoundError:
> org/springframework/core/ResolvableTypeProvider
>
> at java.lang.ClassLoader.defineClass1(Native Method)
>
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
>
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
>
> at java.security.AccessController.doPrivileged(Native Method)
>
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
>
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.findClass(WebAppClassLoader.java:549)
>
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:475)
>
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
>
> at java.lang.Class.getDeclaredConstructors0(Native Method)
>
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
>
> at java.lang.Class.getConstructor0(Class.java:3075)
>
> at java.lang.Class.getDeclaredConstructor(Class.java:2178)
>
> at
> org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:104)
>
> at
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:628)
>
> at
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:682)
>
> at
> org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:553)
>
> at
> org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:494)
>
> at
> org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
>
> at javax.servlet.GenericServlet.init(GenericServlet.java:244)
>
> at
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:626)
>
> at
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:405)
>
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:875)
>
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:346)
>
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1379)
>
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1341)
>
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
>
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:259)
>
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:517)
>
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
>
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
>
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
>
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
>
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
>
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
>
> at org.eclipse.jetty.server.Server.start(Server.java:405)
>
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
>
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
>
> at org.eclipse.jetty.server.Server.doStart(Server.java:372)
>
> ... 12 more
>
> Caused by: java.lang.ClassNotFoundException:
> org.springframework.core.ResolvableTypeProvider
>
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:487)
>
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
>
> ... 54 more
>
> On Fri, Apr 8, 2016 at 6:35 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
>> For comparison, here’s the classpath from the M1 release:
>>
>> Manifest-Version: 1.0
>> Created-By: abaker
>> Title: gemfire
>> Version: 1.0.0-incubating.M1
>> Organization: Apache Software Foundation (ASF)
>> Class-Path: gemfire-common-1.0.0-incubating.M1.jar gemfire-json-1.0.0-
>> incubating.M1.jar gemfire-joptsimple-1.0.0-incubating.M1.jar gemfire-
>> core-1.0.0-incubating.M1.jar gemfire-lucene-1.0.0-incubating.M1.jar s
>> pring-core-3.2.12.RELEASE.jar jgroups-3.6.6.Final.jar antlr-2.7.7.jar
>> jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar jackson-databin
>> d-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar commons-logging-1
>> .1.1.jar netty-all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-
>> api-1.7.jar javax.servlet-api-3.1.0.jar javax.transaction-api-1.2.jar
>> jna-4.0.0.jar jline-2.12.jar hbase-0.94.27.jar log4j-api-2.5.jar log
>> 4j-core-2.5.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6.v201511
>> 06.jar jetty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v2015110
>> 6.jar jetty-servlet-9.3.6.v20151106.jar jetty-util-9.3.6.v20151106.ja
>> r jetty-webapp-9.3.6.v20151106.jar jetty-xml-9.3.6.v20151106.jar jans
>> i-1.8.jar slf4j-api-1.7.7.jar spring-shell-1.1.0.RELEASE.jar snappy-j
>> ava-1.1.1.6.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-
>> 2.5.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.jar lucen
>> e-queries-5.3.0.jar lucene-queryparser-5.3.0.jar
>>
>> The spring-core jar is not present on the classpath at all, despite
>> having a bunch of spring jars in the lib dir !!
>>
>> Anthony-Baker-MacBook-Pro:lib abaker$ ls -1 spring*
>> spring-aop-3.2.12.RELEASE.jar
>> spring-beans-3.2.12.RELEASE.jar
>> spring-context-3.2.12.RELEASE.jar
>> spring-context-support-3.2.12.RELEASE.jar
>> spring-core-3.2.12.RELEASE.jar
>> spring-data-commons-1.9.1.RELEASE.jar
>> spring-data-gemfire-1.5.1.RELEASE.jar
>> spring-expression-3.2.12.RELEASE.jar
>> spring-shell-1.1.0.RELEASE.jar
>> spring-tx-3.2.12.RELEASE.jar
>> spring-web-3.2.12.RELEASE.jar
>> spring-webmvc-3.2.12.RELEASE.jar
>>
>> Back to the original question: spring-shell-1.1.0 depends on
>> spring-core-4.0.3.RELEASE while other usages in geode rely on
>> spring-core-4.2.4.RELEASE. Is this ok?
>>
>> Anthony
>>
>>
>> > On Apr 8, 2016, at 6:12 AM, Anthony Baker <ab...@pivotal.io> wrote:
>> >
>> > After an update I’m seeing a conflict on spring-core. Here’s the
>> geode-dependencies classpath with both versions of spring-core:
>> >
>> > Class-Path: geode-common-1.0.0-incubating.M2-SNAPSHOT.jar geode-json-1
>> > .0.0-incubating.M2-SNAPSHOT.jar geode-joptsimple-1.0.0-incubating.M2-
>> > SNAPSHOT.jar geode-core-1.0.0-incubating.M2-SNAPSHOT.jar geode-lucene
>> > -1.0.0-incubating.M2-SNAPSHOT.jar geode-pulse-1.0.0-incubating.M2-SNA
>> > PSHOT.jar geode-wan-1.0.0-incubating.M2-SNAPSHOT.jar geode-cq-1.0.0-i
>> > ncubating.M2-SNAPSHOT.jar jgroups-3.6.7.Final.jar antlr-2.7.7.jar jac
>> > kson-databind-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar netty
>> > -all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-api-1.7.jar jn
>> > a-4.0.0.jar log4j-api-2.5.jar log4j-core-2.5.jar jetty-webapp-9.3.6.v
>> > 20151106.jar spring-shell-1.1.0.RELEASE.jar snappy-java-1.1.1.6.jar j
>> > ansi-1.8.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-2.5
>> > .jar jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar javax.trans
>> > action-api-1.2.jar jetty-xml-9.3.6.v20151106.jar jetty-servlet-9.3.6.
>> > v20151106.jar jline-2.12.jar spring-core-4.0.3.RELEASE.jar slf4j-api-
>> > 1.7.12.jar commons-logging-1.2.jar jetty-util-9.3.6.v20151106.jar jet
>> > ty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v20151106.jar java
>> > x.servlet-api-3.1.0.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6
>> > .v20151106.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.ja
>> > r lucene-queries-5.3.0.jar lucene-queryparser-5.3.0.jar spring-core-4
>> > .2.4.RELEASE.jar
>> >
>> > The older version is pulled in transitively:
>> >
>> > Anthony-Baker-MacBook-Pro:geode-core abaker$ gradle dependencyInsight
>> --dependency spring-core
>> > :geode-core:dependencyInsight
>> > org.springframework:spring-core:4.0.3.RELEASE
>> > \--- org.springframework.shell:spring-shell:1.1.0.RELEASE
>> > \— compile
>> >
>> > Here’s at least subproject that uses the version from
>> dependency-versions.properties:
>> >
>> > Anthony-Baker-MacBook-Pro:geode-rebalancer abaker$ gradle
>> dependencyInsight --dependency spring-core
>> > :geode-rebalancer:dependencyInsight
>> > org.springframework:spring-core:4.2.4.RELEASE
>> > +--- org.springframework:spring-aop:4.2.4.RELEASE
>> > | \--- org.springframework:spring-context:4.2.4.RELEASE
>> > | \--- compile
>> > +--- org.springframework:spring-beans:4.2.4.RELEASE
>> > | +--- org.springframework:spring-context:4.2.4.RELEASE (*)
>> > | \--- org.springframework:spring-aop:4.2.4.RELEASE (*)
>> > +--- org.springframework:spring-context:4.2.4.RELEASE (*)
>> > \--- org.springframework:spring-expression:4.2.4.RELEASE
>> > \--- org.springframework:spring-context:4.2.4.RELEASE (*)
>> >
>> > Anthony
>> >
>> >
>> >> On Apr 7, 2016, at 4:13 PM, Dan Smith <ds...@pivotal.io> wrote:
>> >>
>> >> 3 of these dependencies should now be gone with the changes for
>> GEODE-1025.
>> >> spring-context-support
>> >> spring-data-gemfire
>> >> spring-data-commons
>> >>
>> >> BTW, if you want to see the list of jars we ship, there's a handy
>> gradle
>> >> task I added. It will show you what is in each war file as well as the
>> lib
>> >> directory:
>> >>
>> >> ./gradlew dumpInstalledJars
>> >>
>> >> On Thu, Apr 7, 2016 at 10:50 AM, Anthony Baker <ab...@pivotal.io>
>> wrote:
>> >>
>> >>> Added JIRA:
>> >>> https://issues.apache.org/jira/browse/GEODE-1193
>> >>>
>> >>> Anthony
>> >>>
>> >>>> On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io> wrote:
>> >>>>
>> >>>> The reason that the servlet API jar is included is because it gets
>> used
>> >>> on
>> >>>> the server classpath (where the sessions are stored). I'm going
>> through
>> >>> the
>> >>>> Modules docs now, so we should be able to direct users to use the
>> servlet
>> >>>> jar provided by the container. We should be OK not to ship it.
>> >>>>
>> >>>> --Jens
>> >>>>
>> >>>> On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io> wrote:
>> >>>>
>> >>>>> I would not include the (javax.)servlet-api JAR with Geode. It will
>> be a
>> >>>>> significant pain point for web applications (and frameworks, e.g.
>> >>> *Spring
>> >>>>> Session*) that expect a specific version of the Servlet API and then
>> >>>>> suddenly encounter conflicting versions.
>> >>>>>
>> >>>>> Also, FYI, the latest release of the core *Spring Framework
>> >>>>> <http://projects.spring.io/spring-framework/>* [1] is now
>> >>> 4.2.5.RELEASE.
>> >>>>> The latest *Spring Security <
>> http://projects.spring.io/spring-security/
>> >>>> *
>> >>>>> [2]
>> >>>>> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the
>> >>> *Spring
>> >>>>> Security* version used by Geode (3.1.x) is not even supported any
>> more.
>> >>>>>
>> >>>>>
>> >>>>> [1] http://projects.spring.io/spring-framework/
>> >>>>> [2] http://projects.spring.io/spring-security/
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io>
>> >>> wrote:
>> >>>>>
>> >>>>>> You can’t tell from the diff below but it turns out we’re
>> including two
>> >>>>>> versions of servlet-api:
>> >>>>>>
>> >>>>>> servlet-api-2.5.jar
>> >>>>>> javax.servlet-api-3.1.0.jar
>> >>>>>>
>> >>>>>> Version 3.1.0 is from the geode/lib while the older jar is from
>> the app
>> >>>>>> server module. Do we need to ship these at all since they are only
>> >>>>> needed
>> >>>>>> for compiling?
>> >>>>>>
>> >>>>>> Anthony
>> >>>>>>
>> >>>>>>
>> >>>>>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io>
>> wrote:
>> >>>>>>>
>> >>>>>>> Here’s a comparison of the bundled jar dependencies present in the
>> >>>>>> binary distribution from the M1 release versus the current develop
>> >>>>> branch.
>> >>>>>> The good news is there aren’t that many changes despite lots of
>> build
>> >>>>>> refactoring and new source code in pulse / modules / wan / cq.
>> >>>>>>>
>> >>>>>>> If you see something that looks wrong, please speak up. I see a
>> >>>>>> possible version conflict on sl4j.
>> >>>>>>>
>> >>>>>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y
>> --suppress-common-lines
>> >>>>>> license.M1/M1-jars license.M2/M2-jars
>> >>>>>>> activation-1.1.1.jar |
>> >>>>>> activation-1.1.jar
>> >>>>>>>>
>> >>>>>> commons-beanutils-1.8.3.jar
>> >>>>>>>>
>> >>>>>> commons-collections-3.2.2.jar
>> >>>>>>>>
>> >>>>>> commons-digester-2.1.jar
>> >>>>>>> commons-logging-1.1.1.jar |
>> >>>>>> commons-logging-1.2.jar
>> >>>>>>> hbase-0.94.27.jar <
>> >>>>>>> jgroups-3.6.6.Final.jar
>> |
>> >>>>>> jgroups-3.6.7.Final.jar
>> >>>>>>>>
>> >>>>>> servlet-api-2.5.jar
>> >>>>>>>>
>> >>>>>> slf4j-api-1.7.12.jar
>> >>>>>>>>
>> >>>>>> slf4j-jdk14-1.7.7.jar
>> >>>>>>> spring-aop-3.2.12.RELEASE.jar |
>> >>>>>> spring-aop-4.2.4.RELEASE.jar
>> >>>>>>> spring-aspects-3.2.12.RELEASE.jar |
>> >>>>>> spring-aspects-4.2.4.RELEASE.jar
>> >>>>>>> spring-beans-3.2.12.RELEASE.jar
>> |
>> >>>>>> spring-beans-4.2.4.RELEASE.jar
>> >>>>>>> spring-context-3.2.12.RELEASE.jar |
>> >>>>>> spring-context-4.2.4.RELEASE.jar
>> >>>>>>> spring-context-support-3.2.12.RELEASE.jar |
>> >>>>>> spring-context-support-4.2.4.RELEASE.jar
>> >>>>>>> spring-core-3.2.12.RELEASE.jar
>> |
>> >>>>>> spring-core-4.2.4.RELEASE.jar
>> >>>>>>> spring-data-gemfire-1.5.1.RELEASE.jar |
>> >>>>>> spring-data-gemfire-1.7.2.RELEASE.jar
>> >>>>>>> spring-expression-3.2.12.RELEASE.jar |
>> >>>>>> spring-expression-4.2.4.RELEASE.jar
>> >>>>>>> spring-oxm-3.2.12.RELEASE.jar |
>> >>>>>> spring-ldap-core-1.3.2.RELEASE.jar
>> >>>>>>>>
>> >>>>>> spring-oxm-4.2.4.RELEASE.jar
>> >>>>>>>>
>> >>>>>> spring-security-config-3.1.7.RELEASE.jar
>> >>>>>>>>
>> >>>>>> spring-security-core-3.1.7.RELEASE.jar
>> >>>>>>>>
>> >>>>>> spring-security-ldap-3.1.7.RELEASE.jar
>> >>>>>>>>
>> >>>>>> spring-security-web-3.1.7.RELEASE.jar
>> >>>>>>> spring-tx-3.2.12.RELEASE.jar |
>> >>>>>> spring-tx-4.2.4.RELEASE.jar
>> >>>>>>> spring-web-3.2.12.RELEASE.jar |
>> >>>>>> spring-web-4.2.4.RELEASE.jar
>> >>>>>>> spring-webmvc-3.2.12.RELEASE.jar |
>> >>>>>> spring-webmvc-4.2.4.RELEASE.jar
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Anthony
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> -John
>> >>>>> 503-504-8657
>> >>>>> john.blum10101 (skype)
>> >>>>>
>> >>>
>> >>>
>> >
>>
>>
>
>
> --
> Cheers
>
> Jinmei
>
--
Cheers
Jinmei
Re: Bundled jar dependencies
Posted by Jinmei Liao <ji...@pivotal.io>.
On a similar note, I just did a pull from develop and ran a clean
installDist. When I tried to start a locator in GFSH, I got the following
error in the log file:
[error 2016/04/08 09:53:12.979 PDT locator1 <locator request thread[1]>
tid=0x27] Jmx manager could not be started because HTTP service failed to
start
com.gemstone.gemfire.management.ManagementException: HTTP service failed to
start
at
com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:279)
at
com.gemstone.gemfire.management.internal.ManagementAgent.startAgent(ManagementAgent.java:125)
at
com.gemstone.gemfire.management.internal.SystemManagementService.startManager(SystemManagementService.java:475)
at
com.gemstone.gemfire.management.internal.JmxManagerLocator.findJmxManager(JmxManagerLocator.java:104)
at
com.gemstone.gemfire.management.internal.JmxManagerLocator.processRequest(JmxManagerLocator.java:57)
at
com.gemstone.gemfire.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1328)
at
com.gemstone.gemfire.distributed.internal.tcpserver.TcpServer$3.run(TcpServer.java:386)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: MultiException[java.lang.NoClassDefFoundError:
org/springframework/core/ResolvableTypeProvider, java.net.BindException:
Address already in use]
at org.eclipse.jetty.server.Server.doStart(Server.java:347)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at
com.gemstone.gemfire.management.internal.JettyHelper.startJetty(JettyHelper.java:147)
at
com.gemstone.gemfire.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:251)
... 9 more
Suppressed: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at
sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326)
at
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:384)
... 12 more
Caused by: java.lang.NoClassDefFoundError:
org/springframework/core/ResolvableTypeProvider
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at
org.eclipse.jetty.webapp.WebAppClassLoader.findClass(WebAppClassLoader.java:549)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:475)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getConstructor0(Class.java:3075)
at java.lang.Class.getDeclaredConstructor(Class.java:2178)
at
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:104)
at
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:628)
at
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:682)
at
org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:553)
at
org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:494)
at
org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at
org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:626)
at
org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:405)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:875)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:346)
at
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1379)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1341)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
at
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:259)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:517)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.server.Server.start(Server.java:405)
at
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at org.eclipse.jetty.server.Server.doStart(Server.java:372)
... 12 more
Caused by: java.lang.ClassNotFoundException:
org.springframework.core.ResolvableTypeProvider
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:487)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:428)
... 54 more
On Fri, Apr 8, 2016 at 6:35 AM, Anthony Baker <ab...@pivotal.io> wrote:
> For comparison, here’s the classpath from the M1 release:
>
> Manifest-Version: 1.0
> Created-By: abaker
> Title: gemfire
> Version: 1.0.0-incubating.M1
> Organization: Apache Software Foundation (ASF)
> Class-Path: gemfire-common-1.0.0-incubating.M1.jar gemfire-json-1.0.0-
> incubating.M1.jar gemfire-joptsimple-1.0.0-incubating.M1.jar gemfire-
> core-1.0.0-incubating.M1.jar gemfire-lucene-1.0.0-incubating.M1.jar s
> pring-core-3.2.12.RELEASE.jar jgroups-3.6.6.Final.jar antlr-2.7.7.jar
> jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar jackson-databin
> d-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar commons-logging-1
> .1.1.jar netty-all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-
> api-1.7.jar javax.servlet-api-3.1.0.jar javax.transaction-api-1.2.jar
> jna-4.0.0.jar jline-2.12.jar hbase-0.94.27.jar log4j-api-2.5.jar log
> 4j-core-2.5.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6.v201511
> 06.jar jetty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v2015110
> 6.jar jetty-servlet-9.3.6.v20151106.jar jetty-util-9.3.6.v20151106.ja
> r jetty-webapp-9.3.6.v20151106.jar jetty-xml-9.3.6.v20151106.jar jans
> i-1.8.jar slf4j-api-1.7.7.jar spring-shell-1.1.0.RELEASE.jar snappy-j
> ava-1.1.1.6.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-
> 2.5.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.jar lucen
> e-queries-5.3.0.jar lucene-queryparser-5.3.0.jar
>
> The spring-core jar is not present on the classpath at all, despite having
> a bunch of spring jars in the lib dir !!
>
> Anthony-Baker-MacBook-Pro:lib abaker$ ls -1 spring*
> spring-aop-3.2.12.RELEASE.jar
> spring-beans-3.2.12.RELEASE.jar
> spring-context-3.2.12.RELEASE.jar
> spring-context-support-3.2.12.RELEASE.jar
> spring-core-3.2.12.RELEASE.jar
> spring-data-commons-1.9.1.RELEASE.jar
> spring-data-gemfire-1.5.1.RELEASE.jar
> spring-expression-3.2.12.RELEASE.jar
> spring-shell-1.1.0.RELEASE.jar
> spring-tx-3.2.12.RELEASE.jar
> spring-web-3.2.12.RELEASE.jar
> spring-webmvc-3.2.12.RELEASE.jar
>
> Back to the original question: spring-shell-1.1.0 depends on
> spring-core-4.0.3.RELEASE while other usages in geode rely on
> spring-core-4.2.4.RELEASE. Is this ok?
>
> Anthony
>
>
> > On Apr 8, 2016, at 6:12 AM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> > After an update I’m seeing a conflict on spring-core. Here’s the
> geode-dependencies classpath with both versions of spring-core:
> >
> > Class-Path: geode-common-1.0.0-incubating.M2-SNAPSHOT.jar geode-json-1
> > .0.0-incubating.M2-SNAPSHOT.jar geode-joptsimple-1.0.0-incubating.M2-
> > SNAPSHOT.jar geode-core-1.0.0-incubating.M2-SNAPSHOT.jar geode-lucene
> > -1.0.0-incubating.M2-SNAPSHOT.jar geode-pulse-1.0.0-incubating.M2-SNA
> > PSHOT.jar geode-wan-1.0.0-incubating.M2-SNAPSHOT.jar geode-cq-1.0.0-i
> > ncubating.M2-SNAPSHOT.jar jgroups-3.6.7.Final.jar antlr-2.7.7.jar jac
> > kson-databind-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar netty
> > -all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-api-1.7.jar jn
> > a-4.0.0.jar log4j-api-2.5.jar log4j-core-2.5.jar jetty-webapp-9.3.6.v
> > 20151106.jar spring-shell-1.1.0.RELEASE.jar snappy-java-1.1.1.6.jar j
> > ansi-1.8.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-2.5
> > .jar jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar javax.trans
> > action-api-1.2.jar jetty-xml-9.3.6.v20151106.jar jetty-servlet-9.3.6.
> > v20151106.jar jline-2.12.jar spring-core-4.0.3.RELEASE.jar slf4j-api-
> > 1.7.12.jar commons-logging-1.2.jar jetty-util-9.3.6.v20151106.jar jet
> > ty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v20151106.jar java
> > x.servlet-api-3.1.0.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6
> > .v20151106.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.ja
> > r lucene-queries-5.3.0.jar lucene-queryparser-5.3.0.jar spring-core-4
> > .2.4.RELEASE.jar
> >
> > The older version is pulled in transitively:
> >
> > Anthony-Baker-MacBook-Pro:geode-core abaker$ gradle dependencyInsight
> --dependency spring-core
> > :geode-core:dependencyInsight
> > org.springframework:spring-core:4.0.3.RELEASE
> > \--- org.springframework.shell:spring-shell:1.1.0.RELEASE
> > \— compile
> >
> > Here’s at least subproject that uses the version from
> dependency-versions.properties:
> >
> > Anthony-Baker-MacBook-Pro:geode-rebalancer abaker$ gradle
> dependencyInsight --dependency spring-core
> > :geode-rebalancer:dependencyInsight
> > org.springframework:spring-core:4.2.4.RELEASE
> > +--- org.springframework:spring-aop:4.2.4.RELEASE
> > | \--- org.springframework:spring-context:4.2.4.RELEASE
> > | \--- compile
> > +--- org.springframework:spring-beans:4.2.4.RELEASE
> > | +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> > | \--- org.springframework:spring-aop:4.2.4.RELEASE (*)
> > +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> > \--- org.springframework:spring-expression:4.2.4.RELEASE
> > \--- org.springframework:spring-context:4.2.4.RELEASE (*)
> >
> > Anthony
> >
> >
> >> On Apr 7, 2016, at 4:13 PM, Dan Smith <ds...@pivotal.io> wrote:
> >>
> >> 3 of these dependencies should now be gone with the changes for
> GEODE-1025.
> >> spring-context-support
> >> spring-data-gemfire
> >> spring-data-commons
> >>
> >> BTW, if you want to see the list of jars we ship, there's a handy gradle
> >> task I added. It will show you what is in each war file as well as the
> lib
> >> directory:
> >>
> >> ./gradlew dumpInstalledJars
> >>
> >> On Thu, Apr 7, 2016 at 10:50 AM, Anthony Baker <ab...@pivotal.io>
> wrote:
> >>
> >>> Added JIRA:
> >>> https://issues.apache.org/jira/browse/GEODE-1193
> >>>
> >>> Anthony
> >>>
> >>>> On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io> wrote:
> >>>>
> >>>> The reason that the servlet API jar is included is because it gets
> used
> >>> on
> >>>> the server classpath (where the sessions are stored). I'm going
> through
> >>> the
> >>>> Modules docs now, so we should be able to direct users to use the
> servlet
> >>>> jar provided by the container. We should be OK not to ship it.
> >>>>
> >>>> --Jens
> >>>>
> >>>> On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io> wrote:
> >>>>
> >>>>> I would not include the (javax.)servlet-api JAR with Geode. It will
> be a
> >>>>> significant pain point for web applications (and frameworks, e.g.
> >>> *Spring
> >>>>> Session*) that expect a specific version of the Servlet API and then
> >>>>> suddenly encounter conflicting versions.
> >>>>>
> >>>>> Also, FYI, the latest release of the core *Spring Framework
> >>>>> <http://projects.spring.io/spring-framework/>* [1] is now
> >>> 4.2.5.RELEASE.
> >>>>> The latest *Spring Security <
> http://projects.spring.io/spring-security/
> >>>> *
> >>>>> [2]
> >>>>> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the
> >>> *Spring
> >>>>> Security* version used by Geode (3.1.x) is not even supported any
> more.
> >>>>>
> >>>>>
> >>>>> [1] http://projects.spring.io/spring-framework/
> >>>>> [2] http://projects.spring.io/spring-security/
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io>
> >>> wrote:
> >>>>>
> >>>>>> You can’t tell from the diff below but it turns out we’re including
> two
> >>>>>> versions of servlet-api:
> >>>>>>
> >>>>>> servlet-api-2.5.jar
> >>>>>> javax.servlet-api-3.1.0.jar
> >>>>>>
> >>>>>> Version 3.1.0 is from the geode/lib while the older jar is from the
> app
> >>>>>> server module. Do we need to ship these at all since they are only
> >>>>> needed
> >>>>>> for compiling?
> >>>>>>
> >>>>>> Anthony
> >>>>>>
> >>>>>>
> >>>>>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io>
> wrote:
> >>>>>>>
> >>>>>>> Here’s a comparison of the bundled jar dependencies present in the
> >>>>>> binary distribution from the M1 release versus the current develop
> >>>>> branch.
> >>>>>> The good news is there aren’t that many changes despite lots of
> build
> >>>>>> refactoring and new source code in pulse / modules / wan / cq.
> >>>>>>>
> >>>>>>> If you see something that looks wrong, please speak up. I see a
> >>>>>> possible version conflict on sl4j.
> >>>>>>>
> >>>>>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y
> --suppress-common-lines
> >>>>>> license.M1/M1-jars license.M2/M2-jars
> >>>>>>> activation-1.1.1.jar |
> >>>>>> activation-1.1.jar
> >>>>>>>>
> >>>>>> commons-beanutils-1.8.3.jar
> >>>>>>>>
> >>>>>> commons-collections-3.2.2.jar
> >>>>>>>>
> >>>>>> commons-digester-2.1.jar
> >>>>>>> commons-logging-1.1.1.jar |
> >>>>>> commons-logging-1.2.jar
> >>>>>>> hbase-0.94.27.jar <
> >>>>>>> jgroups-3.6.6.Final.jar
> |
> >>>>>> jgroups-3.6.7.Final.jar
> >>>>>>>>
> >>>>>> servlet-api-2.5.jar
> >>>>>>>>
> >>>>>> slf4j-api-1.7.12.jar
> >>>>>>>>
> >>>>>> slf4j-jdk14-1.7.7.jar
> >>>>>>> spring-aop-3.2.12.RELEASE.jar |
> >>>>>> spring-aop-4.2.4.RELEASE.jar
> >>>>>>> spring-aspects-3.2.12.RELEASE.jar |
> >>>>>> spring-aspects-4.2.4.RELEASE.jar
> >>>>>>> spring-beans-3.2.12.RELEASE.jar
> |
> >>>>>> spring-beans-4.2.4.RELEASE.jar
> >>>>>>> spring-context-3.2.12.RELEASE.jar |
> >>>>>> spring-context-4.2.4.RELEASE.jar
> >>>>>>> spring-context-support-3.2.12.RELEASE.jar |
> >>>>>> spring-context-support-4.2.4.RELEASE.jar
> >>>>>>> spring-core-3.2.12.RELEASE.jar
> |
> >>>>>> spring-core-4.2.4.RELEASE.jar
> >>>>>>> spring-data-gemfire-1.5.1.RELEASE.jar |
> >>>>>> spring-data-gemfire-1.7.2.RELEASE.jar
> >>>>>>> spring-expression-3.2.12.RELEASE.jar |
> >>>>>> spring-expression-4.2.4.RELEASE.jar
> >>>>>>> spring-oxm-3.2.12.RELEASE.jar |
> >>>>>> spring-ldap-core-1.3.2.RELEASE.jar
> >>>>>>>>
> >>>>>> spring-oxm-4.2.4.RELEASE.jar
> >>>>>>>>
> >>>>>> spring-security-config-3.1.7.RELEASE.jar
> >>>>>>>>
> >>>>>> spring-security-core-3.1.7.RELEASE.jar
> >>>>>>>>
> >>>>>> spring-security-ldap-3.1.7.RELEASE.jar
> >>>>>>>>
> >>>>>> spring-security-web-3.1.7.RELEASE.jar
> >>>>>>> spring-tx-3.2.12.RELEASE.jar |
> >>>>>> spring-tx-4.2.4.RELEASE.jar
> >>>>>>> spring-web-3.2.12.RELEASE.jar |
> >>>>>> spring-web-4.2.4.RELEASE.jar
> >>>>>>> spring-webmvc-3.2.12.RELEASE.jar |
> >>>>>> spring-webmvc-4.2.4.RELEASE.jar
> >>>>>>>
> >>>>>>>
> >>>>>>> Anthony
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> -John
> >>>>> 503-504-8657
> >>>>> john.blum10101 (skype)
> >>>>>
> >>>
> >>>
> >
>
>
--
Cheers
Jinmei
Re: Bundled jar dependencies
Posted by Anthony Baker <ab...@pivotal.io>.
For comparison, here’s the classpath from the M1 release:
Manifest-Version: 1.0
Created-By: abaker
Title: gemfire
Version: 1.0.0-incubating.M1
Organization: Apache Software Foundation (ASF)
Class-Path: gemfire-common-1.0.0-incubating.M1.jar gemfire-json-1.0.0-
incubating.M1.jar gemfire-joptsimple-1.0.0-incubating.M1.jar gemfire-
core-1.0.0-incubating.M1.jar gemfire-lucene-1.0.0-incubating.M1.jar s
pring-core-3.2.12.RELEASE.jar jgroups-3.6.6.Final.jar antlr-2.7.7.jar
jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar jackson-databin
d-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar commons-logging-1
.1.1.jar netty-all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-
api-1.7.jar javax.servlet-api-3.1.0.jar javax.transaction-api-1.2.jar
jna-4.0.0.jar jline-2.12.jar hbase-0.94.27.jar log4j-api-2.5.jar log
4j-core-2.5.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6.v201511
06.jar jetty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v2015110
6.jar jetty-servlet-9.3.6.v20151106.jar jetty-util-9.3.6.v20151106.ja
r jetty-webapp-9.3.6.v20151106.jar jetty-xml-9.3.6.v20151106.jar jans
i-1.8.jar slf4j-api-1.7.7.jar spring-shell-1.1.0.RELEASE.jar snappy-j
ava-1.1.1.6.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-
2.5.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.jar lucen
e-queries-5.3.0.jar lucene-queryparser-5.3.0.jar
The spring-core jar is not present on the classpath at all, despite having a bunch of spring jars in the lib dir !!
Anthony-Baker-MacBook-Pro:lib abaker$ ls -1 spring*
spring-aop-3.2.12.RELEASE.jar
spring-beans-3.2.12.RELEASE.jar
spring-context-3.2.12.RELEASE.jar
spring-context-support-3.2.12.RELEASE.jar
spring-core-3.2.12.RELEASE.jar
spring-data-commons-1.9.1.RELEASE.jar
spring-data-gemfire-1.5.1.RELEASE.jar
spring-expression-3.2.12.RELEASE.jar
spring-shell-1.1.0.RELEASE.jar
spring-tx-3.2.12.RELEASE.jar
spring-web-3.2.12.RELEASE.jar
spring-webmvc-3.2.12.RELEASE.jar
Back to the original question: spring-shell-1.1.0 depends on spring-core-4.0.3.RELEASE while other usages in geode rely on spring-core-4.2.4.RELEASE. Is this ok?
Anthony
> On Apr 8, 2016, at 6:12 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> After an update I’m seeing a conflict on spring-core. Here’s the geode-dependencies classpath with both versions of spring-core:
>
> Class-Path: geode-common-1.0.0-incubating.M2-SNAPSHOT.jar geode-json-1
> .0.0-incubating.M2-SNAPSHOT.jar geode-joptsimple-1.0.0-incubating.M2-
> SNAPSHOT.jar geode-core-1.0.0-incubating.M2-SNAPSHOT.jar geode-lucene
> -1.0.0-incubating.M2-SNAPSHOT.jar geode-pulse-1.0.0-incubating.M2-SNA
> PSHOT.jar geode-wan-1.0.0-incubating.M2-SNAPSHOT.jar geode-cq-1.0.0-i
> ncubating.M2-SNAPSHOT.jar jgroups-3.6.7.Final.jar antlr-2.7.7.jar jac
> kson-databind-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar netty
> -all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-api-1.7.jar jn
> a-4.0.0.jar log4j-api-2.5.jar log4j-core-2.5.jar jetty-webapp-9.3.6.v
> 20151106.jar spring-shell-1.1.0.RELEASE.jar snappy-java-1.1.1.6.jar j
> ansi-1.8.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-2.5
> .jar jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar javax.trans
> action-api-1.2.jar jetty-xml-9.3.6.v20151106.jar jetty-servlet-9.3.6.
> v20151106.jar jline-2.12.jar spring-core-4.0.3.RELEASE.jar slf4j-api-
> 1.7.12.jar commons-logging-1.2.jar jetty-util-9.3.6.v20151106.jar jet
> ty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v20151106.jar java
> x.servlet-api-3.1.0.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6
> .v20151106.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.ja
> r lucene-queries-5.3.0.jar lucene-queryparser-5.3.0.jar spring-core-4
> .2.4.RELEASE.jar
>
> The older version is pulled in transitively:
>
> Anthony-Baker-MacBook-Pro:geode-core abaker$ gradle dependencyInsight --dependency spring-core
> :geode-core:dependencyInsight
> org.springframework:spring-core:4.0.3.RELEASE
> \--- org.springframework.shell:spring-shell:1.1.0.RELEASE
> \— compile
>
> Here’s at least subproject that uses the version from dependency-versions.properties:
>
> Anthony-Baker-MacBook-Pro:geode-rebalancer abaker$ gradle dependencyInsight --dependency spring-core
> :geode-rebalancer:dependencyInsight
> org.springframework:spring-core:4.2.4.RELEASE
> +--- org.springframework:spring-aop:4.2.4.RELEASE
> | \--- org.springframework:spring-context:4.2.4.RELEASE
> | \--- compile
> +--- org.springframework:spring-beans:4.2.4.RELEASE
> | +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> | \--- org.springframework:spring-aop:4.2.4.RELEASE (*)
> +--- org.springframework:spring-context:4.2.4.RELEASE (*)
> \--- org.springframework:spring-expression:4.2.4.RELEASE
> \--- org.springframework:spring-context:4.2.4.RELEASE (*)
>
> Anthony
>
>
>> On Apr 7, 2016, at 4:13 PM, Dan Smith <ds...@pivotal.io> wrote:
>>
>> 3 of these dependencies should now be gone with the changes for GEODE-1025.
>> spring-context-support
>> spring-data-gemfire
>> spring-data-commons
>>
>> BTW, if you want to see the list of jars we ship, there's a handy gradle
>> task I added. It will show you what is in each war file as well as the lib
>> directory:
>>
>> ./gradlew dumpInstalledJars
>>
>> On Thu, Apr 7, 2016 at 10:50 AM, Anthony Baker <ab...@pivotal.io> wrote:
>>
>>> Added JIRA:
>>> https://issues.apache.org/jira/browse/GEODE-1193
>>>
>>> Anthony
>>>
>>>> On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io> wrote:
>>>>
>>>> The reason that the servlet API jar is included is because it gets used
>>> on
>>>> the server classpath (where the sessions are stored). I'm going through
>>> the
>>>> Modules docs now, so we should be able to direct users to use the servlet
>>>> jar provided by the container. We should be OK not to ship it.
>>>>
>>>> --Jens
>>>>
>>>> On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io> wrote:
>>>>
>>>>> I would not include the (javax.)servlet-api JAR with Geode. It will be a
>>>>> significant pain point for web applications (and frameworks, e.g.
>>> *Spring
>>>>> Session*) that expect a specific version of the Servlet API and then
>>>>> suddenly encounter conflicting versions.
>>>>>
>>>>> Also, FYI, the latest release of the core *Spring Framework
>>>>> <http://projects.spring.io/spring-framework/>* [1] is now
>>> 4.2.5.RELEASE.
>>>>> The latest *Spring Security <http://projects.spring.io/spring-security/
>>>> *
>>>>> [2]
>>>>> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the
>>> *Spring
>>>>> Security* version used by Geode (3.1.x) is not even supported any more.
>>>>>
>>>>>
>>>>> [1] http://projects.spring.io/spring-framework/
>>>>> [2] http://projects.spring.io/spring-security/
>>>>>
>>>>>
>>>>> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io>
>>> wrote:
>>>>>
>>>>>> You can’t tell from the diff below but it turns out we’re including two
>>>>>> versions of servlet-api:
>>>>>>
>>>>>> servlet-api-2.5.jar
>>>>>> javax.servlet-api-3.1.0.jar
>>>>>>
>>>>>> Version 3.1.0 is from the geode/lib while the older jar is from the app
>>>>>> server module. Do we need to ship these at all since they are only
>>>>> needed
>>>>>> for compiling?
>>>>>>
>>>>>> Anthony
>>>>>>
>>>>>>
>>>>>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io> wrote:
>>>>>>>
>>>>>>> Here’s a comparison of the bundled jar dependencies present in the
>>>>>> binary distribution from the M1 release versus the current develop
>>>>> branch.
>>>>>> The good news is there aren’t that many changes despite lots of build
>>>>>> refactoring and new source code in pulse / modules / wan / cq.
>>>>>>>
>>>>>>> If you see something that looks wrong, please speak up. I see a
>>>>>> possible version conflict on sl4j.
>>>>>>>
>>>>>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines
>>>>>> license.M1/M1-jars license.M2/M2-jars
>>>>>>> activation-1.1.1.jar |
>>>>>> activation-1.1.jar
>>>>>>>>
>>>>>> commons-beanutils-1.8.3.jar
>>>>>>>>
>>>>>> commons-collections-3.2.2.jar
>>>>>>>>
>>>>>> commons-digester-2.1.jar
>>>>>>> commons-logging-1.1.1.jar |
>>>>>> commons-logging-1.2.jar
>>>>>>> hbase-0.94.27.jar <
>>>>>>> jgroups-3.6.6.Final.jar |
>>>>>> jgroups-3.6.7.Final.jar
>>>>>>>>
>>>>>> servlet-api-2.5.jar
>>>>>>>>
>>>>>> slf4j-api-1.7.12.jar
>>>>>>>>
>>>>>> slf4j-jdk14-1.7.7.jar
>>>>>>> spring-aop-3.2.12.RELEASE.jar |
>>>>>> spring-aop-4.2.4.RELEASE.jar
>>>>>>> spring-aspects-3.2.12.RELEASE.jar |
>>>>>> spring-aspects-4.2.4.RELEASE.jar
>>>>>>> spring-beans-3.2.12.RELEASE.jar |
>>>>>> spring-beans-4.2.4.RELEASE.jar
>>>>>>> spring-context-3.2.12.RELEASE.jar |
>>>>>> spring-context-4.2.4.RELEASE.jar
>>>>>>> spring-context-support-3.2.12.RELEASE.jar |
>>>>>> spring-context-support-4.2.4.RELEASE.jar
>>>>>>> spring-core-3.2.12.RELEASE.jar |
>>>>>> spring-core-4.2.4.RELEASE.jar
>>>>>>> spring-data-gemfire-1.5.1.RELEASE.jar |
>>>>>> spring-data-gemfire-1.7.2.RELEASE.jar
>>>>>>> spring-expression-3.2.12.RELEASE.jar |
>>>>>> spring-expression-4.2.4.RELEASE.jar
>>>>>>> spring-oxm-3.2.12.RELEASE.jar |
>>>>>> spring-ldap-core-1.3.2.RELEASE.jar
>>>>>>>>
>>>>>> spring-oxm-4.2.4.RELEASE.jar
>>>>>>>>
>>>>>> spring-security-config-3.1.7.RELEASE.jar
>>>>>>>>
>>>>>> spring-security-core-3.1.7.RELEASE.jar
>>>>>>>>
>>>>>> spring-security-ldap-3.1.7.RELEASE.jar
>>>>>>>>
>>>>>> spring-security-web-3.1.7.RELEASE.jar
>>>>>>> spring-tx-3.2.12.RELEASE.jar |
>>>>>> spring-tx-4.2.4.RELEASE.jar
>>>>>>> spring-web-3.2.12.RELEASE.jar |
>>>>>> spring-web-4.2.4.RELEASE.jar
>>>>>>> spring-webmvc-3.2.12.RELEASE.jar |
>>>>>> spring-webmvc-4.2.4.RELEASE.jar
>>>>>>>
>>>>>>>
>>>>>>> Anthony
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -John
>>>>> 503-504-8657
>>>>> john.blum10101 (skype)
>>>>>
>>>
>>>
>
Re: Bundled jar dependencies
Posted by Anthony Baker <ab...@pivotal.io>.
After an update I’m seeing a conflict on spring-core. Here’s the geode-dependencies classpath with both versions of spring-core:
Class-Path: geode-common-1.0.0-incubating.M2-SNAPSHOT.jar geode-json-1
.0.0-incubating.M2-SNAPSHOT.jar geode-joptsimple-1.0.0-incubating.M2-
SNAPSHOT.jar geode-core-1.0.0-incubating.M2-SNAPSHOT.jar geode-lucene
-1.0.0-incubating.M2-SNAPSHOT.jar geode-pulse-1.0.0-incubating.M2-SNA
PSHOT.jar geode-wan-1.0.0-incubating.M2-SNAPSHOT.jar geode-cq-1.0.0-i
ncubating.M2-SNAPSHOT.jar jgroups-3.6.7.Final.jar antlr-2.7.7.jar jac
kson-databind-2.2.0.jar commons-io-2.3.jar commons-lang-2.5.jar netty
-all-4.0.4.Final.jar fastutil-7.0.2.jar javax.resource-api-1.7.jar jn
a-4.0.0.jar log4j-api-2.5.jar log4j-core-2.5.jar jetty-webapp-9.3.6.v
20151106.jar spring-shell-1.1.0.RELEASE.jar snappy-java-1.1.1.6.jar j
ansi-1.8.jar log4j-slf4j-impl-2.5.jar log4j-jcl-2.5.jar log4j-jul-2.5
.jar jackson-annotations-2.2.0.jar jackson-core-2.2.0.jar javax.trans
action-api-1.2.jar jetty-xml-9.3.6.v20151106.jar jetty-servlet-9.3.6.
v20151106.jar jline-2.12.jar spring-core-4.0.3.RELEASE.jar slf4j-api-
1.7.12.jar commons-logging-1.2.jar jetty-util-9.3.6.v20151106.jar jet
ty-security-9.3.6.v20151106.jar jetty-server-9.3.6.v20151106.jar java
x.servlet-api-3.1.0.jar jetty-http-9.3.6.v20151106.jar jetty-io-9.3.6
.v20151106.jar lucene-analyzers-common-5.3.0.jar lucene-core-5.3.0.ja
r lucene-queries-5.3.0.jar lucene-queryparser-5.3.0.jar spring-core-4
.2.4.RELEASE.jar
The older version is pulled in transitively:
Anthony-Baker-MacBook-Pro:geode-core abaker$ gradle dependencyInsight --dependency spring-core
:geode-core:dependencyInsight
org.springframework:spring-core:4.0.3.RELEASE
\--- org.springframework.shell:spring-shell:1.1.0.RELEASE
\— compile
Here’s at least subproject that uses the version from dependency-versions.properties:
Anthony-Baker-MacBook-Pro:geode-rebalancer abaker$ gradle dependencyInsight --dependency spring-core
:geode-rebalancer:dependencyInsight
org.springframework:spring-core:4.2.4.RELEASE
+--- org.springframework:spring-aop:4.2.4.RELEASE
| \--- org.springframework:spring-context:4.2.4.RELEASE
| \--- compile
+--- org.springframework:spring-beans:4.2.4.RELEASE
| +--- org.springframework:spring-context:4.2.4.RELEASE (*)
| \--- org.springframework:spring-aop:4.2.4.RELEASE (*)
+--- org.springframework:spring-context:4.2.4.RELEASE (*)
\--- org.springframework:spring-expression:4.2.4.RELEASE
\--- org.springframework:spring-context:4.2.4.RELEASE (*)
Anthony
> On Apr 7, 2016, at 4:13 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> 3 of these dependencies should now be gone with the changes for GEODE-1025.
> spring-context-support
> spring-data-gemfire
> spring-data-commons
>
> BTW, if you want to see the list of jars we ship, there's a handy gradle
> task I added. It will show you what is in each war file as well as the lib
> directory:
>
> ./gradlew dumpInstalledJars
>
> On Thu, Apr 7, 2016 at 10:50 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
>> Added JIRA:
>> https://issues.apache.org/jira/browse/GEODE-1193
>>
>> Anthony
>>
>>> On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io> wrote:
>>>
>>> The reason that the servlet API jar is included is because it gets used
>> on
>>> the server classpath (where the sessions are stored). I'm going through
>> the
>>> Modules docs now, so we should be able to direct users to use the servlet
>>> jar provided by the container. We should be OK not to ship it.
>>>
>>> --Jens
>>>
>>> On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io> wrote:
>>>
>>>> I would not include the (javax.)servlet-api JAR with Geode. It will be a
>>>> significant pain point for web applications (and frameworks, e.g.
>> *Spring
>>>> Session*) that expect a specific version of the Servlet API and then
>>>> suddenly encounter conflicting versions.
>>>>
>>>> Also, FYI, the latest release of the core *Spring Framework
>>>> <http://projects.spring.io/spring-framework/>* [1] is now
>> 4.2.5.RELEASE.
>>>> The latest *Spring Security <http://projects.spring.io/spring-security/
>>> *
>>>> [2]
>>>> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the
>> *Spring
>>>> Security* version used by Geode (3.1.x) is not even supported any more.
>>>>
>>>>
>>>> [1] http://projects.spring.io/spring-framework/
>>>> [2] http://projects.spring.io/spring-security/
>>>>
>>>>
>>>> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io>
>> wrote:
>>>>
>>>>> You can’t tell from the diff below but it turns out we’re including two
>>>>> versions of servlet-api:
>>>>>
>>>>> servlet-api-2.5.jar
>>>>> javax.servlet-api-3.1.0.jar
>>>>>
>>>>> Version 3.1.0 is from the geode/lib while the older jar is from the app
>>>>> server module. Do we need to ship these at all since they are only
>>>> needed
>>>>> for compiling?
>>>>>
>>>>> Anthony
>>>>>
>>>>>
>>>>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io> wrote:
>>>>>>
>>>>>> Here’s a comparison of the bundled jar dependencies present in the
>>>>> binary distribution from the M1 release versus the current develop
>>>> branch.
>>>>> The good news is there aren’t that many changes despite lots of build
>>>>> refactoring and new source code in pulse / modules / wan / cq.
>>>>>>
>>>>>> If you see something that looks wrong, please speak up. I see a
>>>>> possible version conflict on sl4j.
>>>>>>
>>>>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines
>>>>> license.M1/M1-jars license.M2/M2-jars
>>>>>> activation-1.1.1.jar |
>>>>> activation-1.1.jar
>>>>>>>
>>>>> commons-beanutils-1.8.3.jar
>>>>>>>
>>>>> commons-collections-3.2.2.jar
>>>>>>>
>>>>> commons-digester-2.1.jar
>>>>>> commons-logging-1.1.1.jar |
>>>>> commons-logging-1.2.jar
>>>>>> hbase-0.94.27.jar <
>>>>>> jgroups-3.6.6.Final.jar |
>>>>> jgroups-3.6.7.Final.jar
>>>>>>>
>>>>> servlet-api-2.5.jar
>>>>>>>
>>>>> slf4j-api-1.7.12.jar
>>>>>>>
>>>>> slf4j-jdk14-1.7.7.jar
>>>>>> spring-aop-3.2.12.RELEASE.jar |
>>>>> spring-aop-4.2.4.RELEASE.jar
>>>>>> spring-aspects-3.2.12.RELEASE.jar |
>>>>> spring-aspects-4.2.4.RELEASE.jar
>>>>>> spring-beans-3.2.12.RELEASE.jar |
>>>>> spring-beans-4.2.4.RELEASE.jar
>>>>>> spring-context-3.2.12.RELEASE.jar |
>>>>> spring-context-4.2.4.RELEASE.jar
>>>>>> spring-context-support-3.2.12.RELEASE.jar |
>>>>> spring-context-support-4.2.4.RELEASE.jar
>>>>>> spring-core-3.2.12.RELEASE.jar |
>>>>> spring-core-4.2.4.RELEASE.jar
>>>>>> spring-data-gemfire-1.5.1.RELEASE.jar |
>>>>> spring-data-gemfire-1.7.2.RELEASE.jar
>>>>>> spring-expression-3.2.12.RELEASE.jar |
>>>>> spring-expression-4.2.4.RELEASE.jar
>>>>>> spring-oxm-3.2.12.RELEASE.jar |
>>>>> spring-ldap-core-1.3.2.RELEASE.jar
>>>>>>>
>>>>> spring-oxm-4.2.4.RELEASE.jar
>>>>>>>
>>>>> spring-security-config-3.1.7.RELEASE.jar
>>>>>>>
>>>>> spring-security-core-3.1.7.RELEASE.jar
>>>>>>>
>>>>> spring-security-ldap-3.1.7.RELEASE.jar
>>>>>>>
>>>>> spring-security-web-3.1.7.RELEASE.jar
>>>>>> spring-tx-3.2.12.RELEASE.jar |
>>>>> spring-tx-4.2.4.RELEASE.jar
>>>>>> spring-web-3.2.12.RELEASE.jar |
>>>>> spring-web-4.2.4.RELEASE.jar
>>>>>> spring-webmvc-3.2.12.RELEASE.jar |
>>>>> spring-webmvc-4.2.4.RELEASE.jar
>>>>>>
>>>>>>
>>>>>> Anthony
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> -John
>>>> 503-504-8657
>>>> john.blum10101 (skype)
>>>>
>>
>>
Re: Bundled jar dependencies
Posted by Dan Smith <ds...@pivotal.io>.
3 of these dependencies should now be gone with the changes for GEODE-1025.
spring-context-support
spring-data-gemfire
spring-data-commons
BTW, if you want to see the list of jars we ship, there's a handy gradle
task I added. It will show you what is in each war file as well as the lib
directory:
./gradlew dumpInstalledJars
On Thu, Apr 7, 2016 at 10:50 AM, Anthony Baker <ab...@pivotal.io> wrote:
> Added JIRA:
> https://issues.apache.org/jira/browse/GEODE-1193
>
> Anthony
>
> > On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io> wrote:
> >
> > The reason that the servlet API jar is included is because it gets used
> on
> > the server classpath (where the sessions are stored). I'm going through
> the
> > Modules docs now, so we should be able to direct users to use the servlet
> > jar provided by the container. We should be OK not to ship it.
> >
> > --Jens
> >
> > On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io> wrote:
> >
> >> I would not include the (javax.)servlet-api JAR with Geode. It will be a
> >> significant pain point for web applications (and frameworks, e.g.
> *Spring
> >> Session*) that expect a specific version of the Servlet API and then
> >> suddenly encounter conflicting versions.
> >>
> >> Also, FYI, the latest release of the core *Spring Framework
> >> <http://projects.spring.io/spring-framework/>* [1] is now
> 4.2.5.RELEASE.
> >> The latest *Spring Security <http://projects.spring.io/spring-security/
> >*
> >> [2]
> >> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the
> *Spring
> >> Security* version used by Geode (3.1.x) is not even supported any more.
> >>
> >>
> >> [1] http://projects.spring.io/spring-framework/
> >> [2] http://projects.spring.io/spring-security/
> >>
> >>
> >> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io>
> wrote:
> >>
> >>> You can’t tell from the diff below but it turns out we’re including two
> >>> versions of servlet-api:
> >>>
> >>> servlet-api-2.5.jar
> >>> javax.servlet-api-3.1.0.jar
> >>>
> >>> Version 3.1.0 is from the geode/lib while the older jar is from the app
> >>> server module. Do we need to ship these at all since they are only
> >> needed
> >>> for compiling?
> >>>
> >>> Anthony
> >>>
> >>>
> >>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io> wrote:
> >>>>
> >>>> Here’s a comparison of the bundled jar dependencies present in the
> >>> binary distribution from the M1 release versus the current develop
> >> branch.
> >>> The good news is there aren’t that many changes despite lots of build
> >>> refactoring and new source code in pulse / modules / wan / cq.
> >>>>
> >>>> If you see something that looks wrong, please speak up. I see a
> >>> possible version conflict on sl4j.
> >>>>
> >>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines
> >>> license.M1/M1-jars license.M2/M2-jars
> >>>> activation-1.1.1.jar |
> >>> activation-1.1.jar
> >>>>>
> >>> commons-beanutils-1.8.3.jar
> >>>>>
> >>> commons-collections-3.2.2.jar
> >>>>>
> >>> commons-digester-2.1.jar
> >>>> commons-logging-1.1.1.jar |
> >>> commons-logging-1.2.jar
> >>>> hbase-0.94.27.jar <
> >>>> jgroups-3.6.6.Final.jar |
> >>> jgroups-3.6.7.Final.jar
> >>>>>
> >>> servlet-api-2.5.jar
> >>>>>
> >>> slf4j-api-1.7.12.jar
> >>>>>
> >>> slf4j-jdk14-1.7.7.jar
> >>>> spring-aop-3.2.12.RELEASE.jar |
> >>> spring-aop-4.2.4.RELEASE.jar
> >>>> spring-aspects-3.2.12.RELEASE.jar |
> >>> spring-aspects-4.2.4.RELEASE.jar
> >>>> spring-beans-3.2.12.RELEASE.jar |
> >>> spring-beans-4.2.4.RELEASE.jar
> >>>> spring-context-3.2.12.RELEASE.jar |
> >>> spring-context-4.2.4.RELEASE.jar
> >>>> spring-context-support-3.2.12.RELEASE.jar |
> >>> spring-context-support-4.2.4.RELEASE.jar
> >>>> spring-core-3.2.12.RELEASE.jar |
> >>> spring-core-4.2.4.RELEASE.jar
> >>>> spring-data-gemfire-1.5.1.RELEASE.jar |
> >>> spring-data-gemfire-1.7.2.RELEASE.jar
> >>>> spring-expression-3.2.12.RELEASE.jar |
> >>> spring-expression-4.2.4.RELEASE.jar
> >>>> spring-oxm-3.2.12.RELEASE.jar |
> >>> spring-ldap-core-1.3.2.RELEASE.jar
> >>>>>
> >>> spring-oxm-4.2.4.RELEASE.jar
> >>>>>
> >>> spring-security-config-3.1.7.RELEASE.jar
> >>>>>
> >>> spring-security-core-3.1.7.RELEASE.jar
> >>>>>
> >>> spring-security-ldap-3.1.7.RELEASE.jar
> >>>>>
> >>> spring-security-web-3.1.7.RELEASE.jar
> >>>> spring-tx-3.2.12.RELEASE.jar |
> >>> spring-tx-4.2.4.RELEASE.jar
> >>>> spring-web-3.2.12.RELEASE.jar |
> >>> spring-web-4.2.4.RELEASE.jar
> >>>> spring-webmvc-3.2.12.RELEASE.jar |
> >>> spring-webmvc-4.2.4.RELEASE.jar
> >>>>
> >>>>
> >>>> Anthony
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> -John
> >> 503-504-8657
> >> john.blum10101 (skype)
> >>
>
>
Re: Bundled jar dependencies
Posted by Anthony Baker <ab...@pivotal.io>.
Added JIRA:
https://issues.apache.org/jira/browse/GEODE-1193
Anthony
> On Apr 7, 2016, at 9:44 AM, Jens Deppe <jd...@pivotal.io> wrote:
>
> The reason that the servlet API jar is included is because it gets used on
> the server classpath (where the sessions are stored). I'm going through the
> Modules docs now, so we should be able to direct users to use the servlet
> jar provided by the container. We should be OK not to ship it.
>
> --Jens
>
> On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io> wrote:
>
>> I would not include the (javax.)servlet-api JAR with Geode. It will be a
>> significant pain point for web applications (and frameworks, e.g. *Spring
>> Session*) that expect a specific version of the Servlet API and then
>> suddenly encounter conflicting versions.
>>
>> Also, FYI, the latest release of the core *Spring Framework
>> <http://projects.spring.io/spring-framework/>* [1] is now 4.2.5.RELEASE.
>> The latest *Spring Security <http://projects.spring.io/spring-security/>*
>> [2]
>> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the *Spring
>> Security* version used by Geode (3.1.x) is not even supported any more.
>>
>>
>> [1] http://projects.spring.io/spring-framework/
>> [2] http://projects.spring.io/spring-security/
>>
>>
>> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
>>
>>> You can’t tell from the diff below but it turns out we’re including two
>>> versions of servlet-api:
>>>
>>> servlet-api-2.5.jar
>>> javax.servlet-api-3.1.0.jar
>>>
>>> Version 3.1.0 is from the geode/lib while the older jar is from the app
>>> server module. Do we need to ship these at all since they are only
>> needed
>>> for compiling?
>>>
>>> Anthony
>>>
>>>
>>>> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io> wrote:
>>>>
>>>> Here’s a comparison of the bundled jar dependencies present in the
>>> binary distribution from the M1 release versus the current develop
>> branch.
>>> The good news is there aren’t that many changes despite lots of build
>>> refactoring and new source code in pulse / modules / wan / cq.
>>>>
>>>> If you see something that looks wrong, please speak up. I see a
>>> possible version conflict on sl4j.
>>>>
>>>> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines
>>> license.M1/M1-jars license.M2/M2-jars
>>>> activation-1.1.1.jar |
>>> activation-1.1.jar
>>>>>
>>> commons-beanutils-1.8.3.jar
>>>>>
>>> commons-collections-3.2.2.jar
>>>>>
>>> commons-digester-2.1.jar
>>>> commons-logging-1.1.1.jar |
>>> commons-logging-1.2.jar
>>>> hbase-0.94.27.jar <
>>>> jgroups-3.6.6.Final.jar |
>>> jgroups-3.6.7.Final.jar
>>>>>
>>> servlet-api-2.5.jar
>>>>>
>>> slf4j-api-1.7.12.jar
>>>>>
>>> slf4j-jdk14-1.7.7.jar
>>>> spring-aop-3.2.12.RELEASE.jar |
>>> spring-aop-4.2.4.RELEASE.jar
>>>> spring-aspects-3.2.12.RELEASE.jar |
>>> spring-aspects-4.2.4.RELEASE.jar
>>>> spring-beans-3.2.12.RELEASE.jar |
>>> spring-beans-4.2.4.RELEASE.jar
>>>> spring-context-3.2.12.RELEASE.jar |
>>> spring-context-4.2.4.RELEASE.jar
>>>> spring-context-support-3.2.12.RELEASE.jar |
>>> spring-context-support-4.2.4.RELEASE.jar
>>>> spring-core-3.2.12.RELEASE.jar |
>>> spring-core-4.2.4.RELEASE.jar
>>>> spring-data-gemfire-1.5.1.RELEASE.jar |
>>> spring-data-gemfire-1.7.2.RELEASE.jar
>>>> spring-expression-3.2.12.RELEASE.jar |
>>> spring-expression-4.2.4.RELEASE.jar
>>>> spring-oxm-3.2.12.RELEASE.jar |
>>> spring-ldap-core-1.3.2.RELEASE.jar
>>>>>
>>> spring-oxm-4.2.4.RELEASE.jar
>>>>>
>>> spring-security-config-3.1.7.RELEASE.jar
>>>>>
>>> spring-security-core-3.1.7.RELEASE.jar
>>>>>
>>> spring-security-ldap-3.1.7.RELEASE.jar
>>>>>
>>> spring-security-web-3.1.7.RELEASE.jar
>>>> spring-tx-3.2.12.RELEASE.jar |
>>> spring-tx-4.2.4.RELEASE.jar
>>>> spring-web-3.2.12.RELEASE.jar |
>>> spring-web-4.2.4.RELEASE.jar
>>>> spring-webmvc-3.2.12.RELEASE.jar |
>>> spring-webmvc-4.2.4.RELEASE.jar
>>>>
>>>>
>>>> Anthony
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> -John
>> 503-504-8657
>> john.blum10101 (skype)
>>
Re: Bundled jar dependencies
Posted by Jens Deppe <jd...@pivotal.io>.
The reason that the servlet API jar is included is because it gets used on
the server classpath (where the sessions are stored). I'm going through the
Modules docs now, so we should be able to direct users to use the servlet
jar provided by the container. We should be OK not to ship it.
--Jens
On Thu, Apr 7, 2016 at 8:33 AM, John Blum <jb...@pivotal.io> wrote:
> I would not include the (javax.)servlet-api JAR with Geode. It will be a
> significant pain point for web applications (and frameworks, e.g. *Spring
> Session*) that expect a specific version of the Servlet API and then
> suddenly encounter conflicting versions.
>
> Also, FYI, the latest release of the core *Spring Framework
> <http://projects.spring.io/spring-framework/>* [1] is now 4.2.5.RELEASE.
> The latest *Spring Security <http://projects.spring.io/spring-security/>*
> [2]
> release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the *Spring
> Security* version used by Geode (3.1.x) is not even supported any more.
>
>
> [1] http://projects.spring.io/spring-framework/
> [2] http://projects.spring.io/spring-security/
>
>
> On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
>
> > You can’t tell from the diff below but it turns out we’re including two
> > versions of servlet-api:
> >
> > servlet-api-2.5.jar
> > javax.servlet-api-3.1.0.jar
> >
> > Version 3.1.0 is from the geode/lib while the older jar is from the app
> > server module. Do we need to ship these at all since they are only
> needed
> > for compiling?
> >
> > Anthony
> >
> >
> > > On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io> wrote:
> > >
> > > Here’s a comparison of the bundled jar dependencies present in the
> > binary distribution from the M1 release versus the current develop
> branch.
> > The good news is there aren’t that many changes despite lots of build
> > refactoring and new source code in pulse / modules / wan / cq.
> > >
> > > If you see something that looks wrong, please speak up. I see a
> > possible version conflict on sl4j.
> > >
> > > Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines
> > license.M1/M1-jars license.M2/M2-jars
> > > activation-1.1.1.jar |
> > activation-1.1.jar
> > > >
> > commons-beanutils-1.8.3.jar
> > > >
> > commons-collections-3.2.2.jar
> > > >
> > commons-digester-2.1.jar
> > > commons-logging-1.1.1.jar |
> > commons-logging-1.2.jar
> > > hbase-0.94.27.jar <
> > > jgroups-3.6.6.Final.jar |
> > jgroups-3.6.7.Final.jar
> > > >
> > servlet-api-2.5.jar
> > > >
> > slf4j-api-1.7.12.jar
> > > >
> > slf4j-jdk14-1.7.7.jar
> > > spring-aop-3.2.12.RELEASE.jar |
> > spring-aop-4.2.4.RELEASE.jar
> > > spring-aspects-3.2.12.RELEASE.jar |
> > spring-aspects-4.2.4.RELEASE.jar
> > > spring-beans-3.2.12.RELEASE.jar |
> > spring-beans-4.2.4.RELEASE.jar
> > > spring-context-3.2.12.RELEASE.jar |
> > spring-context-4.2.4.RELEASE.jar
> > > spring-context-support-3.2.12.RELEASE.jar |
> > spring-context-support-4.2.4.RELEASE.jar
> > > spring-core-3.2.12.RELEASE.jar |
> > spring-core-4.2.4.RELEASE.jar
> > > spring-data-gemfire-1.5.1.RELEASE.jar |
> > spring-data-gemfire-1.7.2.RELEASE.jar
> > > spring-expression-3.2.12.RELEASE.jar |
> > spring-expression-4.2.4.RELEASE.jar
> > > spring-oxm-3.2.12.RELEASE.jar |
> > spring-ldap-core-1.3.2.RELEASE.jar
> > > >
> > spring-oxm-4.2.4.RELEASE.jar
> > > >
> > spring-security-config-3.1.7.RELEASE.jar
> > > >
> > spring-security-core-3.1.7.RELEASE.jar
> > > >
> > spring-security-ldap-3.1.7.RELEASE.jar
> > > >
> > spring-security-web-3.1.7.RELEASE.jar
> > > spring-tx-3.2.12.RELEASE.jar |
> > spring-tx-4.2.4.RELEASE.jar
> > > spring-web-3.2.12.RELEASE.jar |
> > spring-web-4.2.4.RELEASE.jar
> > > spring-webmvc-3.2.12.RELEASE.jar |
> > spring-webmvc-4.2.4.RELEASE.jar
> > >
> > >
> > > Anthony
> > >
> > >
> >
> >
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>
Re: Bundled jar dependencies
Posted by John Blum <jb...@pivotal.io>.
I would not include the (javax.)servlet-api JAR with Geode. It will be a
significant pain point for web applications (and frameworks, e.g. *Spring
Session*) that expect a specific version of the Servlet API and then
suddenly encounter conflicting versions.
Also, FYI, the latest release of the core *Spring Framework
<http://projects.spring.io/spring-framework/>* [1] is now 4.2.5.RELEASE.
The latest *Spring Security <http://projects.spring.io/spring-security/>* [2]
release is 4.0.4.RELEASE. The latest in the 3.x line is 3.2.9; the *Spring
Security* version used by Geode (3.1.x) is not even supported any more.
[1] http://projects.spring.io/spring-framework/
[2] http://projects.spring.io/spring-security/
On Thu, Apr 7, 2016 at 8:21 AM, Anthony Baker <ab...@pivotal.io> wrote:
> You can’t tell from the diff below but it turns out we’re including two
> versions of servlet-api:
>
> servlet-api-2.5.jar
> javax.servlet-api-3.1.0.jar
>
> Version 3.1.0 is from the geode/lib while the older jar is from the app
> server module. Do we need to ship these at all since they are only needed
> for compiling?
>
> Anthony
>
>
> > On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> > Here’s a comparison of the bundled jar dependencies present in the
> binary distribution from the M1 release versus the current develop branch.
> The good news is there aren’t that many changes despite lots of build
> refactoring and new source code in pulse / modules / wan / cq.
> >
> > If you see something that looks wrong, please speak up. I see a
> possible version conflict on sl4j.
> >
> > Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines
> license.M1/M1-jars license.M2/M2-jars
> > activation-1.1.1.jar |
> activation-1.1.jar
> > >
> commons-beanutils-1.8.3.jar
> > >
> commons-collections-3.2.2.jar
> > >
> commons-digester-2.1.jar
> > commons-logging-1.1.1.jar |
> commons-logging-1.2.jar
> > hbase-0.94.27.jar <
> > jgroups-3.6.6.Final.jar |
> jgroups-3.6.7.Final.jar
> > >
> servlet-api-2.5.jar
> > >
> slf4j-api-1.7.12.jar
> > >
> slf4j-jdk14-1.7.7.jar
> > spring-aop-3.2.12.RELEASE.jar |
> spring-aop-4.2.4.RELEASE.jar
> > spring-aspects-3.2.12.RELEASE.jar |
> spring-aspects-4.2.4.RELEASE.jar
> > spring-beans-3.2.12.RELEASE.jar |
> spring-beans-4.2.4.RELEASE.jar
> > spring-context-3.2.12.RELEASE.jar |
> spring-context-4.2.4.RELEASE.jar
> > spring-context-support-3.2.12.RELEASE.jar |
> spring-context-support-4.2.4.RELEASE.jar
> > spring-core-3.2.12.RELEASE.jar |
> spring-core-4.2.4.RELEASE.jar
> > spring-data-gemfire-1.5.1.RELEASE.jar |
> spring-data-gemfire-1.7.2.RELEASE.jar
> > spring-expression-3.2.12.RELEASE.jar |
> spring-expression-4.2.4.RELEASE.jar
> > spring-oxm-3.2.12.RELEASE.jar |
> spring-ldap-core-1.3.2.RELEASE.jar
> > >
> spring-oxm-4.2.4.RELEASE.jar
> > >
> spring-security-config-3.1.7.RELEASE.jar
> > >
> spring-security-core-3.1.7.RELEASE.jar
> > >
> spring-security-ldap-3.1.7.RELEASE.jar
> > >
> spring-security-web-3.1.7.RELEASE.jar
> > spring-tx-3.2.12.RELEASE.jar |
> spring-tx-4.2.4.RELEASE.jar
> > spring-web-3.2.12.RELEASE.jar |
> spring-web-4.2.4.RELEASE.jar
> > spring-webmvc-3.2.12.RELEASE.jar |
> spring-webmvc-4.2.4.RELEASE.jar
> >
> >
> > Anthony
> >
> >
>
>
--
-John
503-504-8657
john.blum10101 (skype)
Re: Bundled jar dependencies
Posted by Anthony Baker <ab...@pivotal.io>.
You can’t tell from the diff below but it turns out we’re including two versions of servlet-api:
servlet-api-2.5.jar
javax.servlet-api-3.1.0.jar
Version 3.1.0 is from the geode/lib while the older jar is from the app server module. Do we need to ship these at all since they are only needed for compiling?
Anthony
> On Apr 6, 2016, at 10:51 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> Here’s a comparison of the bundled jar dependencies present in the binary distribution from the M1 release versus the current develop branch. The good news is there aren’t that many changes despite lots of build refactoring and new source code in pulse / modules / wan / cq.
>
> If you see something that looks wrong, please speak up. I see a possible version conflict on sl4j.
>
> Anthony-Baker-MacBook-Pro:tmp abaker$ diff -y --suppress-common-lines license.M1/M1-jars license.M2/M2-jars
> activation-1.1.1.jar | activation-1.1.jar
> > commons-beanutils-1.8.3.jar
> > commons-collections-3.2.2.jar
> > commons-digester-2.1.jar
> commons-logging-1.1.1.jar | commons-logging-1.2.jar
> hbase-0.94.27.jar <
> jgroups-3.6.6.Final.jar | jgroups-3.6.7.Final.jar
> > servlet-api-2.5.jar
> > slf4j-api-1.7.12.jar
> > slf4j-jdk14-1.7.7.jar
> spring-aop-3.2.12.RELEASE.jar | spring-aop-4.2.4.RELEASE.jar
> spring-aspects-3.2.12.RELEASE.jar | spring-aspects-4.2.4.RELEASE.jar
> spring-beans-3.2.12.RELEASE.jar | spring-beans-4.2.4.RELEASE.jar
> spring-context-3.2.12.RELEASE.jar | spring-context-4.2.4.RELEASE.jar
> spring-context-support-3.2.12.RELEASE.jar | spring-context-support-4.2.4.RELEASE.jar
> spring-core-3.2.12.RELEASE.jar | spring-core-4.2.4.RELEASE.jar
> spring-data-gemfire-1.5.1.RELEASE.jar | spring-data-gemfire-1.7.2.RELEASE.jar
> spring-expression-3.2.12.RELEASE.jar | spring-expression-4.2.4.RELEASE.jar
> spring-oxm-3.2.12.RELEASE.jar | spring-ldap-core-1.3.2.RELEASE.jar
> > spring-oxm-4.2.4.RELEASE.jar
> > spring-security-config-3.1.7.RELEASE.jar
> > spring-security-core-3.1.7.RELEASE.jar
> > spring-security-ldap-3.1.7.RELEASE.jar
> > spring-security-web-3.1.7.RELEASE.jar
> spring-tx-3.2.12.RELEASE.jar | spring-tx-4.2.4.RELEASE.jar
> spring-web-3.2.12.RELEASE.jar | spring-web-4.2.4.RELEASE.jar
> spring-webmvc-3.2.12.RELEASE.jar | spring-webmvc-4.2.4.RELEASE.jar
>
>
> Anthony
>
>