I am using Glassfish 3.1.2.2 to host several web applications, some of which use JodaTime. Recently, I've updated the version of JodaTime from 1.6.2 to 2.0. After doing this, I get problems with errors like this:
java.lang.NoSuchMethodError: org.joda.time.DateTime.compareTo(Lorg/joda/time/ReadableInstant;)I
Usually this indicates a dependency-crash on the classpath, but I couldn't find that my project had multiple versions of JodaTime, 2.0 was the only one. After some more digging, and debugging to find where the DateTime-class is loaded from, I found that it is loaded from [glassfish]\modules\joda-time-1.6.2.jar, which is of course not what I want.
Why does glassfish include a specific version of a library like JodaTime on the classpath of every application, and is it safe to remove it/replace it with version 2.0?
GlassFish doesn't include any version of JodaTime.
I guess you placed the jar file in [glassfish]\modules by yourself and forget that you did that. You can have a look at a fresh GlassFish installation to validate that.
It is safe to delete the old version from the modules folder.
Related
I am currently working on a project that uses JDK 1.4. So its just turned out to be that we have to use ESAPI 1.4.4 which is the only version compatible with JDK 1.4 . I downloaded it from the following path https://github.com/esapi/esapi-java-legacy but it doesnt seem to be a jar file . I couldnt figure out how to include this in my eclipse project or how to bring it into my classpath. Is it possible to get the JAR ??? Someone please guide me how to use it or any sample project for reference is sufficient .Thanks in advance
Ditching JDK 1.4 is my top recommendation as well. But if that is not an option for some reason, then I would try pulling down the ESAPI code base from GitHub (https://github.com/ESAPI/esapi-java-legacy), changing the tag under the maven-compiler-plugin plugin from 1.7 to 1.4 and see if it compiles. Much of it probably will be fine, but you likely will have some huge 3rd party FOSS dependency issues so you will have to adjust those. So, before you go down that route, figure out what exactly it is that you need. If you only need ESAPI's output encoding, use the OWASP Java Encoder Project instead. Various other substitutes are described here: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Should_I_use_ESAPI_3F
Good luck.
-kevin
We are using in our library axis2 library. Axis2 latest version comes with mail.jar version 1.4. We need newer version of mail.jar in the classpath, so can I just replace latest version of mail.jar to Axis2 default download libs?
I have checked out the Axis2 src and recompiled by changing to version 1.5.0 of JavaMail and it compiles and tests run successfully.
Note also reading through the changelog as far as I can tell the changes described are additive.
https://javamail.java.net/docs/JavaMail-1.5-changes.txt
It looks like you can replace the jar but you should test it to be sure. It should really only matter if you are using the MailTransportSender in Axis2.
Btw you might want to consider switching away from Axis and use CXF as in my experience and in various benchmarks like http://www.ibm.com/developerworks/library/j-jws14/ CXF is a lot faster.
I am migrating an application that used Jetty 7.4.5.v20110725 to Jetty 9.3.0.M2, using Maven. I already had upgraded the javax.servlet-api to 3.1.0.
But I am using the FakeHttpServer version 0.3.0 for tests, and at this time there is no newer version. It uses the org.eclipse.jetty.server.nio.SelectChannelConnector class that used to exist up to Jetty 8.x, but does not exists anymore in Jetty 9.
Currently my projects breaks at runtime with a NoClassDefFoundError due to the removed class in Jetty that FakeHttpServer tries to use, holding me back from upgrading Jetty. What can I do to fix that?
Note, this was also cross-posted in the Portuguese StackOverflow version: https://pt.stackoverflow.com/q/64548/132
Upgrade the code that uses Jetty on FakeHttpServer for Jetty 9.
That is your only choice if you want to use Jetty 9 with FakeHttpServer.
Looking at the project page for FakeHttpServer, it seems that there have been no updates (commits) to the project tree since Dec 2012.
You'll either have to convince the project leads to update it, or do it yourself.
Note that Jetty contains several ways of testing webapps. Look at the unit tests in the jetty source code and I'm sure you will find the equivalent of FakeHttpServer.
ServletTester comes to mind as one example. Or just create a Server using the LocalConnector is another way.
When running my Java EE app on TomEE I get the following error:
java.lang.NoClassDefFoundError: javax/persistence/NamedStoredProcedureQuery
There are no compile time errors when I build the app.I am developing in Eclipse and have Apache TomEE selected under targeted runtimes in the project properties, so that the project has access to Java EE.
As the project uses Hibernate I have the following jars in the WEB-INF\lib directory (it's my understanding that these jars in turn use javax.persistence):
hibernate-commons-annotations-4.0.4
hibernate-core-4.3.5
hibernate-jpa-2.1
I've seen a bunch of questions like this one detailing that the solution is to add the required JPA jar into the lib directory of the app and all will be well. But although that solution may work it sounds hacky to me, I want TomEE to manage the JPA libraries itself. It's a Java EE server so why doesn't it do this. Whats a clean solution?
#JB Nizet's answer is the accepted solution:
This class exists since JPA 2.1. I guess your TomEE version only
supports JPA 2.0. And indeed, thehome page of TomEE says: "Java EE 6
Web Profile". Java EE 6 includes JPA 2.0, not 2.1. – JB Nizet
I used to saw a tutorial about this topic. But when I try to make my example application by following the example. I can't find com.sun.xml.ws.transport.http.servlet.WSServletContextListener on my classpath.
but I found com.sun.xml.internal.ws.transport.http.servlet.WSServletContextListener
It confused me, why Oracle move those classes in com.sun.xml.xxx to com.sun.xml.internal? I am using JDK1.6.0_45. I saw some people said, form JDK6U4, jax-ws reference implementation is bundled in JDK, so we should be able to publish a web service by running a light weight http server just with JDK and no other dependencies needed, is that ture? You should notice that in the tutorial I mentioned above, additional dependencies is still needed, see step 5 "JAX-WS Dependencies".
And I also found that in IBM JDK, even com.sun.xml.internal.ws.transport.http.servlet.WSServletContextListener can't be found.
Yes, JAX-WS RI (same as JAX-B RI) is shipped with JDK since Jdk6. All the packages except for javax.xml.* are changed to .internal. in order to avoid conflicts between JDK's and standalone JAX-WS versions.
Using JDK's version, you can deploy web service using just JDK; if you want deploy WS in tomcat or in some AS, you still need JAX-WS standalone version.
If you check grepcode for (non-internal) WSServletContextListener, it shows you, the class is shipped with jaxws-rt/webservice-rt jar.
By looking for the internal WSServletContextListener, you can't find a jar shipping it. (but grepcode also contains the sources of openJDK)
Also, I tried to find WSServletContextListener in my local jdk7, but can't find it. But maybe some third-party jdk ship with the class.
Anyway, if you look into the tutorial again, you will find that jaxws-rt.jar is necessery for the application. Probably you should add it?