I am trying to get Shibboleth's Identity Provider working on Windows 2008R2. I have Jetty 7 installed and have been able to get to the Jetty Site aka http://localhost:8080.
After following instructions on https://wiki.shibboleth.net/confluence/display/SHIB2/IdPJetty7Prepare and then trying to start Jetty I am getting a IllegalArgumentException.
The output of the shell is below. (its a lot, I've had to cut off some of the stack trace because of StackOverflow's character limit)
I am not a java/jetty/shibboleth guru, so can someone tell me what is going on here?
Thanks
PS C:\Jetty> java -jar start.jar
WARNING: System properties and/or JVM args set. Consider using --dry-run or --exec
2012-12-18 14:48:16.714:INFO:oejs.Server:jetty-7.6.8.v20121106
2012-12-18 14:48:16.730:INFO:oejdp.ScanningAppProvider:Deployment monitor C:\Jetty\webapps at interval 1
2012-12-18 14:48:16.730:INFO:oejdp.ScanningAppProvider:Deployment monitor C:\Jetty\contexts at interval 1
2012-12-18 14:48:16.730:INFO:oejd.DeploymentManager:Deployable added: C:\Jetty\contexts\test.xml
2012-12-18 14:48:16.808:INFO:oejw.WebInfConfiguration:Extract jar:file:/C:/Jetty/webapps/test.war!/ to C:\Users\Administ
rator\AppData\Local\Temp\jetty-0.0.0.0-8080-test.war-_-any-\webapp
2012-12-18 14:48:17.214:INFO:oejsh.ContextHandler:started o.e.j.w.WebAppContext{/,file:/C:/Users/Administrator/AppData/L
ocal/Temp/jetty-0.0.0.0-8080-test.war-_-any-/webapp/},C:\Jetty/webapps/test.war
2012-12-18 14:48:17.339:INFO:oejs.TransparentProxy:TransparentProxy # /javadoc-proxy to http://download.eclipse.org/jett
y/stable-7/apidocs
2012-12-18 14:48:17.339:INFO:oejd.DeploymentManager:Deployable added: C:\Jetty\contexts\idp.xml
2012-12-18 14:48:18.246:WARN:oejw.WebAppClassLoader:EXCEPTION
java.lang.IllegalArgumentException: !file: jar:file:/C:/Shibboleth/2.3.8/war/idp.war!/WEB-INF/lib/activation-1.1.jar
at org.eclipse.jetty.webapp.WebAppClassLoader.addClassPath(WebAppClassLoader.java:245)
at org.eclipse.jetty.webapp.WebAppClassLoader.addJars(WebAppClassLoader.java:282)
at org.eclipse.jetty.webapp.WebInfConfiguration.configure(WebInfConfiguration.java:165)
at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:454)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1233)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:683)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:480)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
at org.eclipse.jetty.server.Server.doStart(Server.java:275)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1266)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:472)
at org.eclipse.jetty.start.Main.start(Main.java:620)
at org.eclipse.jetty.start.Main.main(Main.java:95)
2012-12-18 14:48:18.246:WARN:oejw.WebAppClassLoader:EXCEPTION
java.lang.IllegalArgumentException: !file: jar:file:/C:/Shibboleth/2.3.8/war/idp.war!/WEB-INF/lib/antlr-2.7.7.jar
at org.eclipse.jetty.webapp.WebAppClassLoader.addClassPath(WebAppClassLoader.java:245)
at org.eclipse.jetty.webapp.WebAppClassLoader.addJars(WebAppClassLoader.java:282)
at org.eclipse.jetty.webapp.WebInfConfiguration.configure(WebInfConfiguration.java:165)
at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:454)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1233)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:683)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:480)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
at org.eclipse.jetty.server.Server.doStart(Server.java:275)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1266)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:472)
at org.eclipse.jetty.start.Main.start(Main.java:620)
at org.eclipse.jetty.start.Main.main(Main.java:95)
2012-12-18 14:48:18.261:WARN:oejw.WebAppClassLoader:EXCEPTION
java.lang.IllegalArgumentException: !file: jar:file:/C:/Shibboleth/2.3.8/war/idp.war!/WEB-INF/lib/antlr-runtime-3.1.3.ja
r
[******** Cut Off to get under StackOverFlow's Character Limit **************************]
I started the Shibboleth IDP with Jetty using maven. For your reference I give you here the code of the POM and the installation instructions. Worked fine for me:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache</groupId>
<artifactId>shibboleth-idp</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>Shibboleth IDP</name>
<build>
<finalName>idp</finalName>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<configuration>
<webApp>${basedir}/war/idp.war</webApp>
<contextPath>/idp</contextPath>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>7777</port>
<maxIdleTime>60000</maxIdleTime>
</connector>
<connector implementation="org.mortbay.jetty.security.SslSocketConnector">
<port>7443</port>
<maxIdleTime>60000</maxIdleTime>
<keystore>${basedir}/credentials/idp.jks</keystore>
<password>KEYSTORE_PASSWORD_HERE</password>
<keyPassword>PRIVATE_KEY_PASSWORD_HERE</keyPassword>
</connector>
</connectors>
</configuration>
<dependencies>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>
Installation instructions
download the latest version of the IDP from
http://shibboleth.net/downloads/identity-provider/latest/
Unpack the zip file
cd into the directory and run the install.sh or install.bat command. This script will create a Shibboleth IDP home dir.
Save the POM file as pom.xml in the Shibboleth IDP home dir.
Make sure to adapt the params for SSL in the POM file, so that they match your system setup and
start the Shibboleth IDP from the Shibboleth IDP home dir by entering the command:
mvn jetty:run-war
Now you may start configuring. Further instructions for configuration can to be found on the Shibboleth wiki.
Related
I try to deploy a sample Jersey code (osgi-http-service) to my local glassfish server. But I got this version complaints. I've used the solution mentioned in this post, but it did not work out.
I download the Jersey code and only build a sub-project which is osgi-http-service in example. (from https://github.com/jersey/jersey)
I used Maven to build it and it was successful.
When I tried to deploy it on my local glassfish server, it shows an error in the prompt, as below:
> asadmin deploy --type=osgi hello1-1.0.0.jar
remote failure: Error occurred during deployment: Exception while loading the app : org.osgi.framework.BundleException:
Unresolved constraint in bundle hello1 [349]: Unable to resolve 349.0: missing requirement [349.0] osgi.wiring.package;
(&(osgi.wiring.package=org.glassfish.jersey.servlet)(version>=2.22.0)(!(version>=3.0.0))).
Please see server.log for more details. Command deploy failed.
I am sure that the glassfish server is up and running.
I find out that the highest version of jersey-container-servlet is 2.22 or 2.23, based on this link.
I tried both 2.22 and 2.23 in my POM file, but none of them works.
I just wonder, is there anything wrong with the version here?
could you give me some hints what should be the right version of the dependencies?
My POM file dependency section is shown below.
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet-core</artifactId>
<version>2.22</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.22</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.22</version>
<scope>provided</scope>
</dependency>
My POM file build plugin section is shown below.
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.0.1</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>org.glassfish.jersey.examples.osgihttpservice</Export-Package>
<Import-Package>*</Import-Package>
<DynamicImport-Package>*</DynamicImport-Package>
<Bundle-Activator>org.glassfish.jersey.examples.osgihttpservice.Activator</Bundle-Activator>
<Bundle-SymbolicName>hello1</Bundle-SymbolicName>
<Implementation-Title>jersey-osgi-http-service-bundle</Implementation-Title>
<Implementation-Version>${project.version}</Implementation-Version>
</instructions>
<unpackBundle>true</unpackBundle>
</configuration>
</plugin>
</plugins>
</build>
The glassfish log is also attached, for your reference. The glassfish log is essentially the same as the error message in the prompt.
[2016-06-17T21:55:07.982-0700] [glassfish 4.1] [SEVERE] [][javax.enterprise.system.core] [tid: _ThreadID=43 _ThreadName=admin-listener(2)] [timeMillis: 1466225707982] [levelValue: 1000] [[Exception while loading the app :
org.osgi.framework.BundleException: Unresolved constraint in bundle hello1 [377]: Unable to resolve 377.0: missing requirement [377.0] osgi.wiring.package;
(&(osgi.wiring.package=org.glassfish.jersey.servlet)(version>=2.22.0)(!(version>=3.0.0)))
org.osgi.framework.BundleException: Unresolved constraint in bundle hello1 [377]:
Unable to resolve 377.0: missing requirement [377.0] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.jersey.servlet)(version>=2.22.0)(!(version>=3.0.0)))
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.startBundle(OSGiDeployedBundle.java:107)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.resume(OSGiDeployedBundle.java:83)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.start(OSGiDeployedBundle.java:67)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor229.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:309)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:292)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:375)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)]]
Just FYI.
I also downloaded the following jars and installed in my glassfish server:
- jersey-client.jar
- jersey-common.jar
- jersey-container-servlet.jar
- jersey-container-servlet-core.jar
- jersey-media-jaxb.jar
- jersey-server.jar
I met the same error as I deployed the Jersey sample code. For example,
> asadmin deploy --force --type=osgi jersey-container-servlet-core-2.22.jar
remote failure: Error occurred during deployment: Exception while loading the app : org.osgi.framework.BundleException:
Unresolved constraint in bundle org.glassfish.jersey.containers.jersey-container-servlet-core [401]: Unable to resolve 401.0:
missing requirement [401.0] osgi.wiring.package;
(&(osgi.wiring.package=jersey.repackaged.com.google.common.base)(version>=2.22.0)(!(version>=3.0.0))).
Please see server.log for more details.
Command deploy failed.
Thank you very much for your insights and comments.
I'm using the Cloudera-VM. Hadoop version: Hadoop 2.0.0-cdh4.0.0.
I have written an inputFileFormat, when the client calls the getSplits method I get an exception:
IncompatibleClassChangeError found interface org.apache.hadoop.mapreduce.JobContext expecting
I'm using the classes from the mapreduce package not mapred.
However when I look at the stacktrace I see that somewhere along the line the library changes to mapred:
Exception in thread "main" java.lang.IncompatibleClassChangeError: Found interface org.apache.hadoop.mapreduce.JobContext, but class was expected
at com.hadoopApp.DataGeneratorFileInput.getSplits(DataGeneratorFileInput.java:27)
at org.apache.hadoop.mapred.JobClient.writeNewSplits(JobClient.java:1063)
at org.apache.hadoop.mapred.JobClient.writeSplits(JobClient.java:1080)
at org.apache.hadoop.mapred.JobClient.access$600(JobClient.java:174)
at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:992)
at org.apache.hadoop.mapred.JobClient$2.run(JobClient.java:945)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408)
at org.apache.hadoop.mapred.JobClient.submitJobInternal(JobClient.java:945)
at org.apache.hadoop.mapreduce.Job.submit(Job.java:566)
at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:596)
at com.hadoopApp.HBaseApp.generateData(HBaseApp.java:54)
at com.hadoopApp.HBaseApp.run(HBaseApp.java:24)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:84)
at com.hadoopApp.HBaseApp.main(HBaseApp.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.hadoop.util.RunJar.main(RunJar.java:208)
Not sure if this helps, but i'm using this in my maven pom:
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-core</artifactId>
<version>1.2.1</version>
</dependency>
solved it not sure why
changed my pom to this and started working - not sure why it solved it though - your input is appreciated it:
<repositories>
<repository>
<id>cloudera</id>
<url>https://repository.cloudera.com/artifactory/cloudera-repos/</url>
</repository>
</repositories>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-common</artifactId>
<version>2.0.0-cdh4.2.0</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
<version>2.0.0-cdh4.2.0</version>
</dependency>
How can get around this?
I've bumped into the same problem when using Hipi on cdh4.2.0.
The problem is caused by incompatibilities between Hadoop versions (jobs build with Hadoop 1 may not work on Hadoop 2). Initially you were building the job with Hadoop v1 and running it on Hadoop 2.0.0 environment (cloudera uses Hadoop 2.0.0).
Fortunately, hadoop 1.x API is fully supported in Hadoop 2.x, so rebuilding the job with newer version of hadoop helps.
I have a maven war project, that I'm trying to run with tomcat7-maven-plugin. The problem I'm having is that the configuration for each of the environments is in custom folder (it's not inside /resources), as we have a different set of configuration files for each environments (local, test, uat or production).
I'm trying to figure out how can I run the plugin, while specifying a custom classpath that includes the local configuration directory. I've read on this improvement ticket that the way to do it, is to provide a context.xml with a Loader element, but if I do this, the webapp fails to start.
The configuration I have in the pom is
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.0</version>
<configuration>
<path>/${project.build.finalName}</path>
<contextFile>${basedir}/src/env/local/context.xml</contextFile>
<contextReloadable>true</contextReloadable>
</configuration>
</plugin>
the context.xml file (the tomcat plugin does the filtering on this file automatically)
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="${basedir}/src/env/local/" />
<JarScanner scanAllDirectories="true" />
</Context>
And the error I get is
[INFO] create webapp with contextPath: /webapp
Handler error
java.lang.ClassNotFoundException: org.apache.juli.FileHandler
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
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.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:521)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:464)
at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:377)
at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:373)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:373)
at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:452)
at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:377)
at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:373)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:373)
at org.apache.juli.ClassLoaderLogManager.getLogger(ClassLoaderLogManager.java:223)
at java.util.logging.LogManager.demandLogger(LogManager.java:389)
at java.util.logging.Logger.getLogger(Logger.java:288)
at org.apache.juli.logging.DirectJDKLog.<init>(DirectJDKLog.java:71)
at org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:196)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:170)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:311)
at org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:452)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5162)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Does anyone have any suggestion about how to fix this or achieve the same in a different way?
I've been able to do this with the cargo plugin, but the tomcat plugin has some features that I like :).
I am trying to setup xmlbeans-maven-plugin 2.3.3 in my Eclipse and while everything seems to go OK, It fails with an java.io.IOException due to inability to find the file C:\Users\Daniel\Workspace\MyProject\javac.
This is strange because javac is on the system's %PATH% so why would it try to find it in %PROJECT_LOC%?
I found this problem description which sounds very similar to mine, but I placed the JDK path in front of all other paths and that didn't help.
Any idea how to tell the xmlbeans-maven-plugin where to look for javac?
UPDATE 1: I tried working around this problem by simply copying javac.exe to the project's directory and at least it now finds it but the problem moved forward to:
java.lang.NoClassDefFoundError: com/sun/tools/javac/Main
Caused by: java.lang.ClassNotFoundException: com.sun.tools.javac.Main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Exception in thread "main" Could not find the main class: com.sun.tools.javac.Main. Program will exit.
Any insight that could help come up with the correct solution to this (e.g. something in .m2/settings.xml?) would be appreciated.
UPDATE 2: I also tried this little solution I found in my searches:
<settings xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository>c:\maven\repository</localRepository>
<configuration>
<compiler>C:\Program Files (x86)\Java\jdk1.6.0_37\bin\javac.exe</compiler>
</configuration>
</settings>
But that didn't help the plugin find javac. It still complains about "The system cannot find the file specified" for javac.exe.
Found the solution! In the project's pom.xml, simply add the following inside <configuration>:
<compiler>C:\Program Files (x86)\Java\jdk1.6.0_37\bin\javac.exe</compiler>
i.e.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>xmlbeans-maven-plugin</artifactId>
<version>2.3.3</version>
<executions>
<execution>
<goals>
<goal>xmlbeans</goal>
</goals>
</execution>
</executions>
<inherited>true</inherited>
<configuration>
<schemaDirectory>${basedir}/src/main/xsd</schemaDirectory>
<compiler>C:\Program Files (x86)\Java\jdk1.6.0_37\bin\javac.exe</compiler>
</configuration>
</plugin>
Also, be sure to point the Window -> Preferences -> Java -> installed JREs to the JDK's, not JRE's: C:\Program Files (x86)\Java\jdk1.6.0_37. As described in this thread.
I have a modular project in which, for every single module, I use jaxb2-maven-plugin to compile XSD files with xjc. Now, suppose the modules are compiled in the order A-->B. For A everything works fine (i.e. I get the *XsdImpl.java), but for B I get the following:
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:jaxb2-maven-plugin:1.2:xjc (model) on project B: DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:jaxb2-maven-plugin:1.2:xjc (model) on project B: DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
at org.codehaus.mojo.jaxb2.XjcMojo.execute(XjcMojo.java:352)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.xerces.impl.dv.DVFactoryException: DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source)
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
at org.apache.xerces.impl.xs.opti.SchemaParsingConfig.<init>(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.<init>(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.<init>(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.<init>(Unknown Source)
at org.apache.xerces.jaxp.validation.XMLSchemaValidatorComponentManager.<init>(Unknown Source)
at org.apache.xerces.jaxp.validation.ValidatorHandlerImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.validation.AbstractXMLSchema.newValidatorHandler(Unknown Source)
at com.sun.tools.xjc.SchemaCache.newValidator(SchemaCache.java:47)
at com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryImpl$1$1.startElement(AnnotationParserFactoryImpl.java:136)
at com.sun.xml.xsom.impl.parser.state.NGCCRuntime.startElement(NGCCRuntime.java:214)
at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at com.sun.tools.xjc.reader.ExtensionBindingChecker.startElement(ExtensionBindingChecker.java:271)
at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at com.sun.tools.xjc.reader.xmlschema.parser.IncorrectNamespaceURIChecker.startElement(IncorrectNamespaceURIChecker.java:97)
at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at com.sun.tools.xjc.reader.xmlschema.parser.CustomizationContextChecker.startElement(CustomizationContextChecker.java:172)
at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at com.sun.tools.xjc.ModelLoader$SpeculationChecker.startElement(ModelLoader.java:427)
at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at com.sun.tools.xjc.reader.internalizer.VersionChecker.startElement(VersionChecker.java:78)
at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at com.sun.xml.xsom.parser.JAXPParser.parse(JAXPParser.java:79)
at com.sun.tools.xjc.ModelLoader$2.parse(ModelLoader.java:451)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:237)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:298)
at com.sun.xml.xsom.impl.parser.ParserContext.parse(ParserContext.java:87)
at com.sun.xml.xsom.parser.XSOMParser.parse(XSOMParser.java:147)
at com.sun.tools.xjc.ModelLoader.createXSOMSpeculative(ModelLoader.java:468)
at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:338)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:145)
at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:91)
at com.sun.tools.xjc.Driver.run(Driver.java:287)
at org.codehaus.mojo.jaxb2.XjcMojo.execute(XjcMojo.java:301)
... 21 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
Both the modules use the same configuration for the plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<executions>
<execution>
<id>model</id>
<goals>
<goal>xjc</goal>
</goals>
<configuration>
<extension>true</extension>
<clearOutputDir>false</clearOutputDir>
<bindingDirectory>${basedir}/src/main/resources/xsd</bindingDirectory>
<outputDirectory>${basedir}/src/main/generated</outputDirectory>
<schemaDirectory>${basedir}/src/main/generated/xsd</schemaDirectory>
<schemaFiles>base.xsd</schemaFiles>
<staleFile>${project.build.directory}/generated-sources/jaxb/.staleFlag-model</staleFile>
</configuration>
</execution>
</executions>
</plugin>
The error comes always for the second module (it doesn't matter whether A or B).
I've spent a lot of time trying to figure out what happens behind the scenes but unfortunately without success...
For example, I would like to understand what happens upon the first execution here:
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
--->>> at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
I would guess another class is used instead of org.apache.xerces.jaxp.SAXParserImpl, but somehow org.apache.xerces.jaxp.SAXParserImpl is selected the 2nd time.. Do you know how could I proof this? Or did anybody experience the same issue already?
Thanks in advance a lot for any hint/help!
Bye
The issue is that you have inadvertently provided a JAXP implementation without the JAXP API, that is incompatible with the JAXP API that is bundled with the JRE.
To solve this issue, I added JAXP API + implementation dependencies to all jaxb2 plugins in my project:
</executions>
<dependencies>
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.3.04</version>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.9.1</version>
</dependency>
</dependencies>
</plugin>
Remember to update all jaxb2 plugins, not just the failing one. This is because plugin dependencies are resolved only once when the plugin is executed for the first time. This may or may not be the module where the failure occurs.
== EDIT ==
Keep in mind that since Java 1.6, all the necessary JAXP, JAXB, xerces, xalan, JAX-WS RI, SAAJ and related classes are bundled in the JRE library.
You do not need to include any of these deps in your project, unless you're building with an archaic JDK (1.5 or older).
So, if you remove JAXB dependencies from your POM (and maybe upgrade to the latest jaxb2-maven-plugin), your build will probably work fine.
I had the similar issue and by changing version number for below Maven compiler from 1.9 to 3.1 worked for me. In my POM i had made this change at 2 places under plugins...
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
Had a similar problem when including an old jar in my application. In my pom file I used exclusions to clear up the problem.
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>