Looks like safe change to revert back. Maybe it's better to manually construct class path than using wildcards. Could you submit the changes as a patch? Thanks
regard, Eric On Wed, Dec 7, 2011 at 9:11 PM, Schlachter, Matthias <[email protected]> wrote: > I replaced the following in chukwa-config.sh (which gets deployed to > libexec) > > CHUKWA_CLASSPATH="${CHUKWA_HOME}/share/chukwa/*: > ${CHUKWA_HOME}/share/chukwa/lib/*" > > with > > CHUKWA_CLASSPATH="" > for jarFile in ${CHUKWA_HOME}/share/chukwa/*.jar; do > CHUKWA_CLASSPATH=$CHUKWA_CLASSPATH:$jarFile; > done > for jarFile in ${CHUKWA_HOME}/share/chukwa/lib/*.jar; do > CHUKWA_CLASSPATH=$CHUKWA_CLASSPATH:$jarFile; > done > > I am using ubuntu 10.04 LTS 64bit, and sun jdk: > java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) > Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) > > > Regards, > Matthias > > On Wed, 2011-12-07 at 20:59 -0800, Eric Yang wrote: >> In the default shell script, it is loading jar files using wildcard. >> In theory, jersey-core should load before jsr311-api by alphabetic >> order. Is there customization to the deployment to make the class >> path loading different? What OS are you running to observe those >> issues? >> >> regards, >> Eric >> >> On Wed, Dec 7, 2011 at 8:20 PM, Schlachter, Matthias >> <[email protected]> wrote: >> > OK, that fixed it for me: >> > >> > I added exclusions to the hadoop dependency in the pox.xml: >> > ... >> > <dependency> >> > <groupId>org.apache.hadoop</groupId> >> > <artifactId>hadoop-core</artifactId> >> > <version>0.20.205.0</version> >> > <exclusions> >> > <exclusion> >> > <artifactId>jasper-compiler</artifactId> >> > <groupId>tomcat</groupId> >> > </exclusion> >> > <exclusion> >> > <artifactId>jasper-runtime</artifactId> >> > <groupId>tomcat</groupId> >> > </exclusion> >> > </exclusions> >> > </dependency> >> > ... >> > >> > This introduced then a new problem: >> > IncompatibleClassChangeError javax.ws.rs.core.Response$Status does not >> > implement the requested interface >> > >> > I got rid of that by making sure that the jersey-core JAR appears before >> > the jsr311-api JAR in the classpath >> > >> > Regards, >> > >> > Matthias >> > >> > >> > On Thu, 2011-12-08 at 11:33 +1100, Schlachter, Matthias wrote: >> >> Thanks Eric. >> >> >> >> jasper is a dependency of hadoop-core:jar in maven >> >> >> >> [INFO] +- com.google.guava:guava:jar:10.0.1:compile >> >> [INFO] | \- com.google.code.findbugs:jsr305:jar:1.3.9:compile >> >> [INFO] +- com.googlecode.json-simple:json-simple:jar:1.1:compile >> >> [INFO] +- org.apache.hadoop:hadoop-core:jar:0.20.205.0:compile >> >> [INFO] | +- org.apache.commons:commons-math:jar:2.1:compile >> >> [INFO] | +- tomcat:jasper-runtime:jar:5.5.12:compile >> >> [INFO] | +- tomcat:jasper-compiler:jar:5.5.12:compile >> >> >> >> I tried to remove all the dependencies and added the hadoop/hbase >> >> dependencies (by hand) in a system scope. The result is a jasper free >> >> build, that doesn't load the Root resource classes and Provider classes >> >> anymore. It's stuck here: >> >> 08/12/2011 11:22:21 AM com.sun.jersey.api.core.PackagesResourceConfig >> >> init >> >> INFO: Scanning for root resource and provider classes in the packages: >> >> org.apache.hadoop.chukwa.rest.resource >> >> org.apache.hadoop.chukwa.hicc.rest >> >> >> >> Regards, >> >> Matthias >> >> >> >> >> >> On Tue, 2011-12-06 at 22:31 -0800, Eric Yang wrote: >> >> > This looks like a conflict between jetty and jasper. In the pom.xml, >> >> > jasper has been commented out. It looks like your environment put >> >> > jasper back into the system, which causes the problem. Do you need >> >> > jasper? I would recommend to disable it if possible. >> >> > In addition, there is a rebase of using Jersey 1.10 over the weekend >> >> > to solve a stacktrace thrown while starting HICC. It maybe useful to >> >> > sync up to current trunk to be sure. >> >> > >> >> > regards, >> >> > Eric >> >> > >> >> > On Tue, Dec 6, 2011 at 10:00 PM, Schlachter, Matthias >> >> > <[email protected]> wrote: >> >> > > I can't get hicc running anymore. Tried changing the dependencies for >> >> > > the build (different versions of jetty/jersey), but no success so far. >> >> > > Any ideas? Has anybody else the same problem? >> >> > > >> >> > > >> >> > > HTTP ERROR 500 >> >> > > Problem accessing /hicc/. Reason: >> >> > > >> >> > > STANDARD_IMPORTS >> >> > > >> >> > > Caused by: >> >> > > java.lang.NoSuchFieldError: STANDARD_IMPORTS >> >> > > at >> >> > > org.apache.jasper.compiler.PageInfo.<init>(PageInfo.java:100) >> >> > > at >> >> > > org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:98) >> >> > > at >> >> > > org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) >> >> > > at >> >> > > org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) >> >> > > at >> >> > > org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) >> >> > > at >> >> > > org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563) >> >> > > at >> >> > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293) >> >> > > at >> >> > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) >> >> > > at >> >> > > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) >> >> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> >> > > at >> >> > > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) >> >> > > at >> >> > > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) >> >> > > at >> >> > > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> >> > > at >> >> > > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) >> >> > > at >> >> > > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) >> >> > > at >> >> > > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) >> >> > > at >> >> > > org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:327) >> >> > > at >> >> > > org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) >> >> > > at >> >> > > org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:503) >> >> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) >> >> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >> >> > > at >> >> > > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) >> >> > > at >> >> > > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) >> >> > > at >> >> > > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> >> > > at >> >> > > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) >> >> > > at >> >> > > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) >> >> > > at >> >> > > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) >> >> > > at >> >> > > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) >> >> > > at >> >> > > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) >> >> > > at >> >> > > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) >> >> > > at org.mortbay.jetty.Server.handle(Server.java:326) >> >> > > at >> >> > > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) >> >> > > at >> >> > > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) >> >> > > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) >> >> > > at >> >> > > org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) >> >> > > at >> >> > > org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) >> >> > > at >> >> > > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) >> >> > > at >> >> > > org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) >> >> > > >> >> >> > >
