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.
Related
I am using legacy Axis2 web services. So, far it was running fine and now we are planning to upgrade Axis2 version from 1.6.1 to 1.7.6 and rampart lib version from 1.6.1 to 1.7.1. Any suggestion as what is best approach to do it, since this is legacy system so we dont have lot of information. I have been trying to copy all the jar and mar but doesnt seem to be working.
Is there any steps that needs to be followed to do it the right way.
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?
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.
From this link looks like minimal Java version supported by Tomcat 7.x is 1.6 but maybe somebody try to check this requirement and use inside webapp jars compiled on JDK 1.5?
Is it works? Or not works at all? Maybe works with limitations?
Thanks in advance.
I'm not quite sure I understand what you mean with "use inside webapp jars compiled on JDK 1.5". But it seems you mix up two things:
To run Tomcat 7.x, you'll need at least JRE or JDK 1.6.
However, you can use any JAR file, which was originally compiled for an earlier Java version as they are upwards compatible.
So if you're interested in using some older jar file, there's no problem.
I am working on a big project that requires massive financial calculations, I am using
Netbeans IDE 7.3 with a default web application of Java EE 5 (not a maven application)
,My application server is tomcat 7 I am using jsps and servlets my OS is windows 7.
I downloaded and added the jquantlib binary to my application, but when I run it keeps saying that it needs the slf4j-api extension that is not found so i download it also and added its jar to my project but still the error persists.
How can I solve this ? and can anyone give me some guidelines on how to do it ?
The key here is that jquantlib requires slf4j-api version 1.4.0 in the jar manifest:
(from MANIFEST.MF in jquantlib.jar)
Implementation-Vendor-Id: org.jquantlib
Extension-List: slf4j-api
slf4j-api-Extension-Name: slf4j-api
slf4j-api-Implementation-Version: 1.4.0
Tomcat will try to use the version of slf4j-api that you're including in your app, but it's likely that what you've included isn't actually compatible. See http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.34/org/apache/catalina/util/Extension.java#Extension.isCompatibleWith%28org.apache.catalina.util.Extension%29 for details.
Bottom line - try to use slf4j-api version 1.4.0 in your application.
Try removing the lines from the MANIFEST.MF file that mention the sfl4j