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 <[email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 <[email protected]>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 >>>> <[email protected]> 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 >>>> >>> >>> >>
