Hi Martin,
The problem I mentioned earlier is due to duplicate (and different)
versions of servlet api available on the classpath. It is actually a
security exception thrown by Java (see attached stacktrace), the web
container does not even start.
This is seen when running the test in Eclipse IDE, having imported all
Rampart modules as Eclipse Java projects and the cause is due to a (mis)
behavior in Eclpse JUnit launcher which adds all referenced project's
classpath libraries on the test classpath (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306220). Since behavior can
be switched off, I would proceed with preserving the original dependency to
servlet api 2.3 in Rampart core module and explicitly excluding that in
Rampart integration module, so that it uses servlet api 2.5 from Jetty.
This will avoid changing Rampart core module dependencies, which seems to
be preferable. I will update the patch in the Jira.
Thanks,
Detelin
On Thu, Jul 17, 2014 at 1:33 AM, Martin Gainty <[email protected]> wrote:
>
>
> ------------------------------
> Date: Wed, 16 Jul 2014 23:32:01 +0300
> Subject: Re: Rampart transport binding integration tests?
> From: [email protected]
> To: [email protected]
>
>
> I'm using Maven Eclipse plugin. Basically running "mvn eclipse:clean
> eclipse:eclipse" from the root project then importing everything under
> /modules. Afterwards I switch the projects to use Java 1.6 since I saw this
> is being used for the nightly build, while by default Maven generates
> "J2SE-1.5" JRE container for them, at least on my side.
>
> Actually, I just figured out a way to execute RampartTest integration test
> while keeping Rampart core module using servlet api 2.3. What needs to be
> done is to exclude servlet api dependency from all dependencies to other
> Rampart modules in Rampart integration module, then configure the JUnit
> test runner in Eclipse to "only include exported entries", which means that
> it would not include the classpath libraries of other projects, which are
> not explicitly marked as exported.
> This is a somehow hidden option in Eclipse that I did not know about,
> though I use Eclipse extensively. I found out about it in the following
> blog post:
>
> http://robertmarkbramprogrammer.blogspot.com/2011/11/eclipse-make-sure-your-unit-test-uses.html
>
> Also, I found a bug report in Eclipse for the same, apparently other
> developers already complained that Eclipse JUnit runner is including all
> referenced projects' libraries in the run classpath:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=306220
>
> All this means that I can change the patch and revert Rampart core module
> to use servlet api 2.3 and configure Rampart integration module to use 2.5.
> Still, I think that many people might not know how to reconfigure their
> Eclipse and they will struggle with the duplicate servlet jars and the
> exception that I mentioned before. I can do that if you think this the
> preferred solution.
>
> Detelin
> MG>(Tomcat specific) servlet-api is not supposed to be seen by webapp
> classloader ..here is the error I get
> servlet-api-2.5.jar) - jar not loaded. See Servlet Spec 3.0, section
> 10.7.2. Offending class: javax/servlet/Servlet.class
> MG>(Tomcat specific) doc:
> Last, any JAR file that contains Servlet API classes will be explicitly
> ignored by the classloader — Do not include such JARs in your web
> application. All other class loaders in Tomcat follow the usual delegation
> pattern.
> MG>(Tomcat specific) 7.0.50 install deploys 2.5 servlet-api-2.5.jar to
> $CATALINA_HOME\lib\servlet-api-2.5.jar
> MG>http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html
>
>
> On Wed, Jul 16, 2014 at 9:54 PM, Andreas Veithen <
> [email protected]> wrote:
>
> Do you use maven-eclipse-plugin or m2e to import Rampart into Eclipse?
>
> Andreas
>
> On Wed, Jul 16, 2014 at 12:39 AM, <[email protected]> wrote:
> > Sure, we could leave rampart core compile against servlet api 2.3 from
> axis2
> > kernel and exclude it from rampart integration so that Jetty would run
> with
> > 2.5, but still if all rampart modules are imported in Eclipse IDE as
> > projects, then both servlet api versions are available on the classpath
> and
> > when running Rampart Jetty-based tests in Eclipse, one gets:
> >
> > java.lang.SecurityException: class
> "javax.servlet.ServletRequestListener"'s
> > signer information does not match signer information of other classes in
> the
> > same package
> >
> > If nobody is using Eclipse to run tests but sticking to command-line then
> > this approach would work. I also tried to find a Jetty version that uses
> > servlet api 2.3 but even the oldest 6.0 is using 2.5.
> >
> > Regards,
> > Detelin
> >
> >
> >
> > On Tue, Jul 15, 2014 at 10:28 PM, Andreas Veithen
> > <[email protected]> wrote:
> >>
> >> Yes, that is a very good idea.
> >>
> >> I had a quick look at the patch. I think that we need to refine a bit
> >> the part about the Servlet API versioning. More on this later.
> >>
> >> Andreas
> >>
> >> On Tue, Jul 15, 2014 at 12:36 PM, <[email protected]> wrote:
> >> > Hi again,
> >> > I opened an enhancement request for Rampart to re-enable the
> >> > transport
> >> > binding integration tests:
> >> >
> >> > https://issues.apache.org/jira/browse/RAMPART-416
> >> >
> >> > I provided a patch that introduces usage of embedded Jetty 7 web
> >> > container
> >> > with SSL support, modifies RampartTest to use that instead of the
> >> > UtilServer
> >> > and re-enables transport binding integration tests.
> >> > Please let me know if you have any concerns with it, I will be glad to
> >> > improve it.
> >> >
> >> > Regards,
> >> > Detelin
> >> >
> >> >
> >> > On Mon, Jul 14, 2014 at 12:18 PM, <[email protected]> wrote:
> >> >>
> >> >> Hi Rampart devs,
> >> >> While working on a Rampart extension for Kerberos authentication
> >> >> over
> >> >> transport binding, I was looking into implementing an integration
> test
> >> >> in
> >> >> Rampart, but noticed that transport binding (https) tests are not
> >> >> supported
> >> >> at the moment, since it uses Axis2 SimpleHttpServer which does not
> >> >> support
> >> >> https. Are there any plans to use a regular web container (e.g.
> Jetty)
> >> >> to
> >> >> enable transport binding tests? I can verify if Jetty Maven plugin
> can
> >> >> be
> >> >> used for this purpose, but wanted to check whether this has not
> already
> >> >> been
> >> >> attempted in the past. Any comments on this are welcome.
> >> >>
> >> >> Thanks,
> >> >> Detelin
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
java.lang.SecurityException: class "javax.servlet.ServletRequestListener"'s
signer information does not match signer information of other classes in the
same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:806)
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:625)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.eclipse.jetty.server.handler.ContextHandler.setEventListeners(ContextHandler.java:567)
at
org.eclipse.jetty.webapp.WebAppContext.setEventListeners(WebAppContext.java:964)
at
org.eclipse.jetty.webapp.WebAppContext.addEventListener(WebAppContext.java:990)
at
org.eclipse.jetty.webapp.TagLibConfiguration.preConfigure(TagLibConfiguration.java:505)
at
org.eclipse.jetty.webapp.WebAppContext.preConfigure(WebAppContext.java:445)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:481)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:281)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.apache.axis2.integration.JettyServer.start(JettyServer.java:141)
at org.apache.axis2.integration.JettyServer.start(JettyServer.java:92)
at org.apache.rampart.RampartTest.setUp(RampartTest.java:76)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
