paymill / paymill-java

Java wrapper for Paymill API
http://paymill.github.io
MIT License
26 stars 22 forks source link

[RuntimeException: java.lang.NoClassDefFoundError: com/sun/jersey/spi/MessageBodyWorkers] #38

Closed pichsenmeister closed 10 years ago

pichsenmeister commented 10 years ago

I'm using the paybutton to generate the token. when processing the token on server with the java api, I get this error (I'm using scala, playframework on server).

already inlcuded: "com.sun.jersey" % "jersey-server" % "1.18", "com.sun.jersey" % "jersey-client" % "1.18", "com.sun.jersey" % "jersey-json" % "1.18"

my code is:

val paymill: PaymillContext = new PaymillContext(privateKey); val transactionService: TransactionService = paymill.getTransactionService() val transaction: Transaction = transactionService.createWithToken(token, 25, "EUR", "test transaction") println(transaction)

nikoloff commented 10 years ago

This can happen only if you use this lib directly without a dependency management tool like maven. Add to your classpath all dependencies, on which the project itself depends.

pichsenmeister commented 10 years ago

no. that's not the case. I'm using sbt which fetches the paymill java sdk from the given maven repository in the readme.

nikoloff commented 10 years ago

This sounds like dependency issue. Check please if you have jersey-client 1.17.1 and jersey-core 1.17.1 in your class path.

pichsenmeister commented 10 years ago

jersey-client 1.17.1 is in classpath, i had to add jersey-core 1.17.1 manually. now it works. thanks.

PatrickHuetter commented 10 years ago

+1 Same problem here with grails framework wich uses maven for dependency management. Adding jersey-core to dependencies worked for me.

d0mme-zz commented 10 years ago

@stoilkov, can you please have a look at this issue? Sorry for this late response guys!

stoilkov commented 10 years ago

@nikoloff looking at the jersey-client pom, the dependency to jersey-core might depend on the maven profile in use. we should include a dependency to jersey-core directly in our pom.

nikoloff commented 10 years ago

41 adds explicit dependency to jersey-core

joantune commented 9 years ago

FYI, I had a similar error using Paymill's client version 5.0.0.

While trying to use SBT with that dependency, I got the following error:

[ERROR] [01/26/2015 10:02:07.111] [application-akka.actor.default-dispatcher-2] [akka://application/user/$b] java.lang.RuntimeException: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
    at miner.ProviderIniterMiner.onReceive(ProviderIniterMiner.java:47)
    at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:167)
    at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
    at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)
    at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
    at akka.actor.ActorCell.invoke(ActorCell.scala:487)
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
    at akka.dispatch.Mailbox.run(Mailbox.scala:220)
    at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393)
    at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
    at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
    at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
    at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl

After some digging around, I found out that I had a previous dependency that was depending on Jersey's 1.X API. So that might be your problem as well if you run into this issue again.

I 'solved' it by actually updating the offending library to a version that uses JAX-RS v2 API

I 'solved' it by removing the offending library (I was lucky that I wasn't using it yet.. and I think I can use something else) but still I had to add the following dependencies by hand:

libraryDependencies += "org.glassfish.jersey.core" % "jersey-client" % "2.13"

libraryDependencies += "org.glassfish.jersey" % "jersey-bom" % "2.13"

libraryDependencies += "javax.ws.rs" % "javax.ws.rs-api" % "2.0.1"

libraryDependencies += "org.glassfish.jersey.core" % "jersey-common" % "2.13"

libraryDependencies += "org.glassfish.hk2" % "osgi-resource-locator" % "1.0.1"

Maybe you won't need all of the above, try playing around with it in case you have the same problema and what a smaller footprint for your configuration files

When will Java solve these kinds of dependency problems.. sigh

stoilkov commented 9 years ago

@joantune thanks for the feedback. glad that you solved the dependency problem. unfortunately we cannot do a lot on our side :)

joantune commented 9 years ago

Yes @stoilkov , I only posted this here in case anyone has the same problem and finds this thread like I did, by googling the exception, to give them some guidance. That's it :)

Although I wonder why I had to put the explicit dependencies

libraryDependencies += "org.glassfish.jersey.core" % "jersey-client" % "2.13"

libraryDependencies += "org.glassfish.jersey" % "jersey-bom" % "2.13"

libraryDependencies += "javax.ws.rs" % "javax.ws.rs-api" % "2.0.1"

libraryDependencies += "org.glassfish.jersey.core" % "jersey-common" % "2.13"

libraryDependencies += "org.glassfish.hk2" % "osgi-resource-locator" % "1.0.1"

by hand in SBT and on Maven everything worked fine. But anyway, I'm not an expert on SBT, I only deal with it because I have to when using Play. And again, if anyone has that problem without a conflict issue with JAX-RS 1.X API like I did, they can just also copy and paste the librarydependencies on SBT