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)

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)

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)

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)

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

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

This is for pom.xml and bin/chukwa-config.sh in trunk 1211721

Regards,
Matthias

On Wed, 2011-12-07 at 22:06 -0800, Eric Yang wrote:
> 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:

Matthias,

Please create a JIRA ticket for this on

https://issues.apache.org/jira/browse/CHUKWA

and submit the patch there
On Thu, Dec 8, 2011 at 8:57 AM, Schlachter, Matthias <
[EMAIL PROTECTED]> wrote:

> This is for pom.xml and bin/chukwa-config.sh in trunk 1211721
>
> Regards,
> Matthias
>
> On Wed, 2011-12-07 at 22:06 -0800, Eric Yang wrote:
> > 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
Ahmed Fathalla

OK, will do...
Regards,
Matthias

On Thu, 2011-12-08 at 10:03 +0200, Ahmed Fathalla wrote:
> Matthias,
>
> Please create a JIRA ticket for this on
>
> https://issues.apache.org/jira/browse/CHUKWA
>
> and submit the patch there
>
>
> On Thu, Dec 8, 2011 at 8:57 AM, Schlachter, Matthias
> <[EMAIL PROTECTED]> wrote:
>         This is for pom.xml and bin/chukwa-config.sh in trunk 1211721
>        
>         Regards,
>         Matthias
>        
>         On Wed, 2011-12-07 at 22:06 -0800, Eric Yang wrote:
>         > 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