You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by Srihari Srinivasan <ss...@thoughtworks.com> on 2013/07/08 19:45:37 UTC

Jersey and Jetty not playing well...

Hi Folks,

Have got a basic setup of Jetty integrated with the Drillbit. Next I am
working on integrating Jersey in order to create the REST resources. I've
introduced this dependency -
<dependency>
            <groupId>com.sun.jersey</groupId>
            <artifactId>jersey-server</artifactId>
            <version>1.8</version>
</dependency>

After which some of the tests started to fail with the following error -

*java.lang.SecurityException: class
"javax.servlet.ServletRegistration$Dynamic"'s signer information does not
match signer information of other classes in the same package*

Googling led me to believe that this is possibly happening because servlet
API classes are getting loaded from two different jars (one of Jetty and
another Jersey) each signed differently. Confirmed this by removing the
above dependency (and the jersey code I introduced) and the tests were
green once again.

Does anyone know how to deal with this issue? Kind of stuck at this point
because of this..

Thanks,
Hari

Re: Jersey and Jetty not playing well...

Posted by Srihari Srinivasan <ss...@thoughtworks.com>.
Strangely its not re-occurring...i am able to hit a simple Welcome resource
URL and see the output on the browser when the server is started along with
the drill bit.
I am at a point where the basic bootstrapping is done. Next I'll be working
on the actual APIs to submit and execute queries.

Would you or someone else like to review the code from my repo before I
move along?

-- Hari

On Tue, Jul 9, 2013 at 10:56 PM, Jacques Nadeau <ja...@apache.org> wrote:

> No need to recreate ExecConstants.  Create an HttpConstants.
>
> Adding the dependency will probably re-introduce the problem.  But at
> this point you can at least know that is the problem.  Then you can
> work through which particular dependency is causing the problem.
>
> J
>
> On Tue, Jul 9, 2013 at 10:18 AM, Srihari Srinivasan
> <ss...@thoughtworks.com> wrote:
> > Jacques,
> >
> > The idea of getting treating it as a separate sub module worked. I now
> have
> > a mvn sub module called http-engine which is dependent on  jetty and
> jersey
> > libraries and the common module. The only thing is I had to create
> another
> > ExecConstants to hold the config keys in this namespace. Hope thats
> > ok..I'll now try introducing this dependency to java-exec and see if all
> > things come together!
> >
> > Thanks,
> > Hari
> >
> >
> > On Tue, Jul 9, 2013 at 1:34 AM, Srihari Srinivasan <
> > ssriniva@thoughtworks.com> wrote:
> >
> >> Doesn't really look like a Jersey issue. Its got no dependency on the
> >> Servlet api..I was able to reproduce the issue by just introducing these
> >> lines in the engine class -
> >>
> >> org.eclipse.jetty.servlet.ServletContextHandler context = new
> >> ServletContextHandler(ServletContextHandler.SESSIONS);
> >>     context.setContextPath("/");
> >>     httpServer.setHandler(context);
> >>
> >> I get the same error for javax.servlet.FilterRegistration this time.
> >>
> >> From the mvn tree I notice -
> >> [INFO] +- org.eclipse.jetty:jetty-server:jar:9.0.4.v20130625:compile
> >> [INFO] |  +-
> >> org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
> >>
> >> jetty-server to be dependent on servlet 3.0
> >>
> >>
> >> On Tue, Jul 9, 2013 at 12:59 AM, Srihari Srinivasan <
> >> ssriniva@thoughtworks.com> wrote:
> >>
> >>> I've attached the results of mvn dependency:tree for the java-exec
> module.
> >>> Pushed the code to my repo...
> >>>
> >>>
> https://github.com/srihari/incubator-drill/blob/master/sandbox/prototype/exec/java-exec/src/main/java/org/apache/drill/exec/http/engine/HttpEngine.java
> >>>
> >>>
> >>> On Mon, Jul 8, 2013 at 11:40 PM, Jacques Nadeau <jacques@apache.org
> >wrote:
> >>>
> >>>> I suggest taking a look at the maven dependency tree and figuring out
> >>>> whether you have two different servlet transitive dependencies.  You
> >>>> probably need to manually exclude one of these.  Are you structuring
> >>>> this as a separate drill/maven module?  We should probably do that and
> >>>> make java-exec a dependency, then use a hocon extension to manage
> >>>> loading and running as part of drillbit.
> >>>>
> >>>> If you can't figure out the dependency issue, please post the code on
> >>>> GitHub so we can help you through it.
> >>>>
> >>>> thanks,
> >>>> Jacques
> >>>>
> >>>>
> >>>> On Mon, Jul 8, 2013 at 10:45 AM, Srihari Srinivasan
> >>>> <ss...@thoughtworks.com> wrote:
> >>>> > Hi Folks,
> >>>> >
> >>>> > Have got a basic setup of Jetty integrated with the Drillbit. Next
> I am
> >>>> > working on integrating Jersey in order to create the REST resources.
> >>>> I've
> >>>> > introduced this dependency -
> >>>> > <dependency>
> >>>> >             <groupId>com.sun.jersey</groupId>
> >>>> >             <artifactId>jersey-server</artifactId>
> >>>> >             <version>1.8</version>
> >>>> > </dependency>
> >>>> >
> >>>> > After which some of the tests started to fail with the following
> error
> >>>> -
> >>>> >
> >>>> > *java.lang.SecurityException: class
> >>>> > "javax.servlet.ServletRegistration$Dynamic"'s signer information
> does
> >>>> not
> >>>> > match signer information of other classes in the same package*
> >>>> >
> >>>> > Googling led me to believe that this is possibly happening because
> >>>> servlet
> >>>> > API classes are getting loaded from two different jars (one of Jetty
> >>>> and
> >>>> > another Jersey) each signed differently. Confirmed this by removing
> the
> >>>> > above dependency (and the jersey code I introduced) and the tests
> were
> >>>> > green once again.
> >>>> >
> >>>> > Does anyone know how to deal with this issue? Kind of stuck at this
> >>>> point
> >>>> > because of this..
> >>>> >
> >>>> > Thanks,
> >>>> > Hari
> >>>>
> >>>
> >>>
> >>
>

Re: Jersey and Jetty not playing well...

Posted by Jacques Nadeau <ja...@apache.org>.
No need to recreate ExecConstants.  Create an HttpConstants.

Adding the dependency will probably re-introduce the problem.  But at
this point you can at least know that is the problem.  Then you can
work through which particular dependency is causing the problem.

J

On Tue, Jul 9, 2013 at 10:18 AM, Srihari Srinivasan
<ss...@thoughtworks.com> wrote:
> Jacques,
>
> The idea of getting treating it as a separate sub module worked. I now have
> a mvn sub module called http-engine which is dependent on  jetty and jersey
> libraries and the common module. The only thing is I had to create another
> ExecConstants to hold the config keys in this namespace. Hope thats
> ok..I'll now try introducing this dependency to java-exec and see if all
> things come together!
>
> Thanks,
> Hari
>
>
> On Tue, Jul 9, 2013 at 1:34 AM, Srihari Srinivasan <
> ssriniva@thoughtworks.com> wrote:
>
>> Doesn't really look like a Jersey issue. Its got no dependency on the
>> Servlet api..I was able to reproduce the issue by just introducing these
>> lines in the engine class -
>>
>> org.eclipse.jetty.servlet.ServletContextHandler context = new
>> ServletContextHandler(ServletContextHandler.SESSIONS);
>>     context.setContextPath("/");
>>     httpServer.setHandler(context);
>>
>> I get the same error for javax.servlet.FilterRegistration this time.
>>
>> From the mvn tree I notice -
>> [INFO] +- org.eclipse.jetty:jetty-server:jar:9.0.4.v20130625:compile
>> [INFO] |  +-
>> org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
>>
>> jetty-server to be dependent on servlet 3.0
>>
>>
>> On Tue, Jul 9, 2013 at 12:59 AM, Srihari Srinivasan <
>> ssriniva@thoughtworks.com> wrote:
>>
>>> I've attached the results of mvn dependency:tree for the java-exec module.
>>> Pushed the code to my repo...
>>>
>>> https://github.com/srihari/incubator-drill/blob/master/sandbox/prototype/exec/java-exec/src/main/java/org/apache/drill/exec/http/engine/HttpEngine.java
>>>
>>>
>>> On Mon, Jul 8, 2013 at 11:40 PM, Jacques Nadeau <ja...@apache.org>wrote:
>>>
>>>> I suggest taking a look at the maven dependency tree and figuring out
>>>> whether you have two different servlet transitive dependencies.  You
>>>> probably need to manually exclude one of these.  Are you structuring
>>>> this as a separate drill/maven module?  We should probably do that and
>>>> make java-exec a dependency, then use a hocon extension to manage
>>>> loading and running as part of drillbit.
>>>>
>>>> If you can't figure out the dependency issue, please post the code on
>>>> GitHub so we can help you through it.
>>>>
>>>> thanks,
>>>> Jacques
>>>>
>>>>
>>>> On Mon, Jul 8, 2013 at 10:45 AM, Srihari Srinivasan
>>>> <ss...@thoughtworks.com> wrote:
>>>> > Hi Folks,
>>>> >
>>>> > Have got a basic setup of Jetty integrated with the Drillbit. Next I am
>>>> > working on integrating Jersey in order to create the REST resources.
>>>> I've
>>>> > introduced this dependency -
>>>> > <dependency>
>>>> >             <groupId>com.sun.jersey</groupId>
>>>> >             <artifactId>jersey-server</artifactId>
>>>> >             <version>1.8</version>
>>>> > </dependency>
>>>> >
>>>> > After which some of the tests started to fail with the following error
>>>> -
>>>> >
>>>> > *java.lang.SecurityException: class
>>>> > "javax.servlet.ServletRegistration$Dynamic"'s signer information does
>>>> not
>>>> > match signer information of other classes in the same package*
>>>> >
>>>> > Googling led me to believe that this is possibly happening because
>>>> servlet
>>>> > API classes are getting loaded from two different jars (one of Jetty
>>>> and
>>>> > another Jersey) each signed differently. Confirmed this by removing the
>>>> > above dependency (and the jersey code I introduced) and the tests were
>>>> > green once again.
>>>> >
>>>> > Does anyone know how to deal with this issue? Kind of stuck at this
>>>> point
>>>> > because of this..
>>>> >
>>>> > Thanks,
>>>> > Hari
>>>>
>>>
>>>
>>

Re: Jersey and Jetty not playing well...

Posted by Srihari Srinivasan <ss...@thoughtworks.com>.
Jacques,

The idea of getting treating it as a separate sub module worked. I now have
a mvn sub module called http-engine which is dependent on  jetty and jersey
libraries and the common module. The only thing is I had to create another
ExecConstants to hold the config keys in this namespace. Hope thats
ok..I'll now try introducing this dependency to java-exec and see if all
things come together!

Thanks,
Hari


On Tue, Jul 9, 2013 at 1:34 AM, Srihari Srinivasan <
ssriniva@thoughtworks.com> wrote:

> Doesn't really look like a Jersey issue. Its got no dependency on the
> Servlet api..I was able to reproduce the issue by just introducing these
> lines in the engine class -
>
> org.eclipse.jetty.servlet.ServletContextHandler context = new
> ServletContextHandler(ServletContextHandler.SESSIONS);
>     context.setContextPath("/");
>     httpServer.setHandler(context);
>
> I get the same error for javax.servlet.FilterRegistration this time.
>
> From the mvn tree I notice -
> [INFO] +- org.eclipse.jetty:jetty-server:jar:9.0.4.v20130625:compile
> [INFO] |  +-
> org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
>
> jetty-server to be dependent on servlet 3.0
>
>
> On Tue, Jul 9, 2013 at 12:59 AM, Srihari Srinivasan <
> ssriniva@thoughtworks.com> wrote:
>
>> I've attached the results of mvn dependency:tree for the java-exec module.
>> Pushed the code to my repo...
>>
>> https://github.com/srihari/incubator-drill/blob/master/sandbox/prototype/exec/java-exec/src/main/java/org/apache/drill/exec/http/engine/HttpEngine.java
>>
>>
>> On Mon, Jul 8, 2013 at 11:40 PM, Jacques Nadeau <ja...@apache.org>wrote:
>>
>>> I suggest taking a look at the maven dependency tree and figuring out
>>> whether you have two different servlet transitive dependencies.  You
>>> probably need to manually exclude one of these.  Are you structuring
>>> this as a separate drill/maven module?  We should probably do that and
>>> make java-exec a dependency, then use a hocon extension to manage
>>> loading and running as part of drillbit.
>>>
>>> If you can't figure out the dependency issue, please post the code on
>>> GitHub so we can help you through it.
>>>
>>> thanks,
>>> Jacques
>>>
>>>
>>> On Mon, Jul 8, 2013 at 10:45 AM, Srihari Srinivasan
>>> <ss...@thoughtworks.com> wrote:
>>> > Hi Folks,
>>> >
>>> > Have got a basic setup of Jetty integrated with the Drillbit. Next I am
>>> > working on integrating Jersey in order to create the REST resources.
>>> I've
>>> > introduced this dependency -
>>> > <dependency>
>>> >             <groupId>com.sun.jersey</groupId>
>>> >             <artifactId>jersey-server</artifactId>
>>> >             <version>1.8</version>
>>> > </dependency>
>>> >
>>> > After which some of the tests started to fail with the following error
>>> -
>>> >
>>> > *java.lang.SecurityException: class
>>> > "javax.servlet.ServletRegistration$Dynamic"'s signer information does
>>> not
>>> > match signer information of other classes in the same package*
>>> >
>>> > Googling led me to believe that this is possibly happening because
>>> servlet
>>> > API classes are getting loaded from two different jars (one of Jetty
>>> and
>>> > another Jersey) each signed differently. Confirmed this by removing the
>>> > above dependency (and the jersey code I introduced) and the tests were
>>> > green once again.
>>> >
>>> > Does anyone know how to deal with this issue? Kind of stuck at this
>>> point
>>> > because of this..
>>> >
>>> > Thanks,
>>> > Hari
>>>
>>
>>
>

Re: Jersey and Jetty not playing well...

Posted by Srihari Srinivasan <ss...@thoughtworks.com>.
Doesn't really look like a Jersey issue. Its got no dependency on the
Servlet api..I was able to reproduce the issue by just introducing these
lines in the engine class -

org.eclipse.jetty.servlet.ServletContextHandler context = new
ServletContextHandler(ServletContextHandler.SESSIONS);
    context.setContextPath("/");
    httpServer.setHandler(context);

I get the same error for javax.servlet.FilterRegistration this time.

>From the mvn tree I notice -
[INFO] +- org.eclipse.jetty:jetty-server:jar:9.0.4.v20130625:compile
[INFO] |  +-
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile

jetty-server to be dependent on servlet 3.0


On Tue, Jul 9, 2013 at 12:59 AM, Srihari Srinivasan <
ssriniva@thoughtworks.com> wrote:

> I've attached the results of mvn dependency:tree for the java-exec module.
> Pushed the code to my repo...
>
> https://github.com/srihari/incubator-drill/blob/master/sandbox/prototype/exec/java-exec/src/main/java/org/apache/drill/exec/http/engine/HttpEngine.java
>
>
> On Mon, Jul 8, 2013 at 11:40 PM, Jacques Nadeau <ja...@apache.org>wrote:
>
>> I suggest taking a look at the maven dependency tree and figuring out
>> whether you have two different servlet transitive dependencies.  You
>> probably need to manually exclude one of these.  Are you structuring
>> this as a separate drill/maven module?  We should probably do that and
>> make java-exec a dependency, then use a hocon extension to manage
>> loading and running as part of drillbit.
>>
>> If you can't figure out the dependency issue, please post the code on
>> GitHub so we can help you through it.
>>
>> thanks,
>> Jacques
>>
>>
>> On Mon, Jul 8, 2013 at 10:45 AM, Srihari Srinivasan
>> <ss...@thoughtworks.com> wrote:
>> > Hi Folks,
>> >
>> > Have got a basic setup of Jetty integrated with the Drillbit. Next I am
>> > working on integrating Jersey in order to create the REST resources.
>> I've
>> > introduced this dependency -
>> > <dependency>
>> >             <groupId>com.sun.jersey</groupId>
>> >             <artifactId>jersey-server</artifactId>
>> >             <version>1.8</version>
>> > </dependency>
>> >
>> > After which some of the tests started to fail with the following error -
>> >
>> > *java.lang.SecurityException: class
>> > "javax.servlet.ServletRegistration$Dynamic"'s signer information does
>> not
>> > match signer information of other classes in the same package*
>> >
>> > Googling led me to believe that this is possibly happening because
>> servlet
>> > API classes are getting loaded from two different jars (one of Jetty and
>> > another Jersey) each signed differently. Confirmed this by removing the
>> > above dependency (and the jersey code I introduced) and the tests were
>> > green once again.
>> >
>> > Does anyone know how to deal with this issue? Kind of stuck at this
>> point
>> > because of this..
>> >
>> > Thanks,
>> > Hari
>>
>
>

Re: Jersey and Jetty not playing well...

Posted by Srihari Srinivasan <ss...@thoughtworks.com>.
I've attached the results of mvn dependency:tree for the java-exec module.
Pushed the code to my repo...
https://github.com/srihari/incubator-drill/blob/master/sandbox/prototype/exec/java-exec/src/main/java/org/apache/drill/exec/http/engine/HttpEngine.java


On Mon, Jul 8, 2013 at 11:40 PM, Jacques Nadeau <ja...@apache.org> wrote:

> I suggest taking a look at the maven dependency tree and figuring out
> whether you have two different servlet transitive dependencies.  You
> probably need to manually exclude one of these.  Are you structuring
> this as a separate drill/maven module?  We should probably do that and
> make java-exec a dependency, then use a hocon extension to manage
> loading and running as part of drillbit.
>
> If you can't figure out the dependency issue, please post the code on
> GitHub so we can help you through it.
>
> thanks,
> Jacques
>
>
> On Mon, Jul 8, 2013 at 10:45 AM, Srihari Srinivasan
> <ss...@thoughtworks.com> wrote:
> > Hi Folks,
> >
> > Have got a basic setup of Jetty integrated with the Drillbit. Next I am
> > working on integrating Jersey in order to create the REST resources. I've
> > introduced this dependency -
> > <dependency>
> >             <groupId>com.sun.jersey</groupId>
> >             <artifactId>jersey-server</artifactId>
> >             <version>1.8</version>
> > </dependency>
> >
> > After which some of the tests started to fail with the following error -
> >
> > *java.lang.SecurityException: class
> > "javax.servlet.ServletRegistration$Dynamic"'s signer information does not
> > match signer information of other classes in the same package*
> >
> > Googling led me to believe that this is possibly happening because
> servlet
> > API classes are getting loaded from two different jars (one of Jetty and
> > another Jersey) each signed differently. Confirmed this by removing the
> > above dependency (and the jersey code I introduced) and the tests were
> > green once again.
> >
> > Does anyone know how to deal with this issue? Kind of stuck at this point
> > because of this..
> >
> > Thanks,
> > Hari
>

Re: Jersey and Jetty not playing well...

Posted by Jacques Nadeau <ja...@apache.org>.
I suggest taking a look at the maven dependency tree and figuring out
whether you have two different servlet transitive dependencies.  You
probably need to manually exclude one of these.  Are you structuring
this as a separate drill/maven module?  We should probably do that and
make java-exec a dependency, then use a hocon extension to manage
loading and running as part of drillbit.

If you can't figure out the dependency issue, please post the code on
GitHub so we can help you through it.

thanks,
Jacques


On Mon, Jul 8, 2013 at 10:45 AM, Srihari Srinivasan
<ss...@thoughtworks.com> wrote:
> Hi Folks,
>
> Have got a basic setup of Jetty integrated with the Drillbit. Next I am
> working on integrating Jersey in order to create the REST resources. I've
> introduced this dependency -
> <dependency>
>             <groupId>com.sun.jersey</groupId>
>             <artifactId>jersey-server</artifactId>
>             <version>1.8</version>
> </dependency>
>
> After which some of the tests started to fail with the following error -
>
> *java.lang.SecurityException: class
> "javax.servlet.ServletRegistration$Dynamic"'s signer information does not
> match signer information of other classes in the same package*
>
> Googling led me to believe that this is possibly happening because servlet
> API classes are getting loaded from two different jars (one of Jetty and
> another Jersey) each signed differently. Confirmed this by removing the
> above dependency (and the jersey code I introduced) and the tests were
> green once again.
>
> Does anyone know how to deal with this issue? Kind of stuck at this point
> because of this..
>
> Thanks,
> Hari