I'm stuck in a project where I have two dependencies that seem to be contradicting themselves.
One lib is apache's httpClient 4.1.* and the other is apache's HttpClient 4.3.*.
Is there a way to have HttpClient 4.3.* and keep it backwards compatible with 4.1.*?
According to the javadoc, the interface is deprecated, not removed.
When I try to use just the 4.3.2, I get:
java.lang.ClassNotFoundException: org.apache.http.protocol.HttpContext
I'm running on Tomcat 7.0.50 and I'm running on eclipse
In the end, this happened because of the IDE I am using (eclipse) even though I once tell that I want to use all dependencies on the server I have it associated with (in this case, tomcat 7.0), It didn't update when I had added this HttpClient 4.3.2.
Furthermore, the program was giving problems in one of the sub-systems that was requiring 4.1.* in a class that is classified as deprecated in 4.3.2.
It was just a series of coincidences (and misreading the manual or gap in the manual) that lead to my misinterpretation of what was really happening.
On eclipse, to add libraries from the project to make them available from the server, use this tool:
project -> properties -> deployment assembly
Related
We've updated our buildserver (Atlassian Bamboo) to Java 8 (JDK).
Since then our integrationtests are failing because our started product does not open any port.
We are building with maven and as part of the integrationtest we are starting our builded product. Our product is a Rest-Api based in an OSGI (equinox) and Jetty.
I tried a lot of things, but nothing helped me to get the product start properly in the maven build.
When I log in on my remote machine and start the product manually everything works fine.
Some more information:
Our buildserver runs as a windows service and our product is written in plain Java.
Presumably you are affected by one or more of the issues discussed in Custom AMIs will not start anymore in Bamboo Cloud (BAM-16291), notably that Bamboo is not compatible with JDK8u60 yet:
Joda-time, one of the libraries used by Bamboo is not compatible with
8u60. We've fixed this problem, but the fix has not been rolled out
yet. Known breakages include S3 interaction and CodeDeploy plugin.
Most/All participants got things working again by downgrading to JDK8u45, as also recommended in Atlassian's most recent update:
Use JDK 8u45. The latest JDKs are incompatible with some 3rd party libraries we're using.
Try to match the layout and scripts of our stock images as closely as possible. This will make it easier for us to provide help if
anything goes wrong.
Choose Oracle if you have the choice between Oracle and OpenJDK flavor of JDK.
Disclaimer
I know we shouldn't use HttpClient on Android anymore
In API 23 we have option to use useLibrary 'org.apache.http.legacy'
I'd like to continue using HttpClient (also I maintain libraries and projects based on it) however, with API 23 the classes are gone.
Well not gone with useLibrary workaround, but cannot be used to develop any further (classes don't autocomplete, everything is shown as invalid code)
We also have option to use HttpComponents provided Android fork of HttpClient 4.3.5.1, which however doesn't provide classes/headers/interfaces that Android provided on API < 22, so it compiles, but we're still unable to developer effectively.
Is there any full HttpClient library repackage (favorably even versions higher than 4.3) which can be used further with target/compile-Sdk of version 23 ?
Latest full repackage I could find is https://code.google.com/p/httpclientandroidlib/ which uses version 4.3.2
I've also added comment to HC JIRA issue https://issues.apache.org/jira/browse/HTTPCLIENT-1632
This workaround will be probably needed only until HttpClient 5.X will be released, as it should have completely different package names.
Well, to answer my own question, I've put up project, which will repackage and build HttpClient in bundle with HttpMime, HttpCore and HttpClient-Cache packages into different namespace.
Currently the version provided is 4.3.3 (in sync with ASF HC 4.3.3 version)
https://github.com/smarek/httpclient-android
It's quite customizable, so changing the package/artifact name or version, adjusting the build to your needs and so on should be no problem.
It's also published on Maven Central under identifier cz.msebera.android:httpclient:4.3.3 and all your code imports currently using org.apache.http should be migrated (for sake of using this library) to cz.msebera.android.httpclient
I'm developing an application that should run on a server. The application uses some external jars.
I have build the application and run it on a local machine without a problem.
Now, I need to deploy it on the server. The server has some of the jars located.
What should I do to make my application work on the server, using the jars that are already there?
I don't have much experience with Java, but I understand that there is a manifest file which has a class-path field that points to all the jars needed. Should I change the manifest "manually", so that it points to the location of the jar on the server? What do you do in situations like this, what is the correct procedure?
Also, if I use one version of jar during development, and there is a bit older version of that jar on the server, what should I do to perform the deployment correctly?
And what is the procedure in case of using maven, should I copy the jars from where it locates them on the local drive to one directory, or is there a way for maven to do it itself?
I'm using NetBeans btw.
Thanks
Re "using the jars that are already there":
See Introduction to the Dependency Mechanism, Dependency Scope: "provided ... indicates you expect the JDK or a container to provide the dependency at runtime."
Re "there is a bit older version of that jar on the server":
Update the library on the server or use the older when developing. I'd consider it a really bad idea to use different versions of a library for developing and runtime. This can lead to subtle errors that are hard to identify.
Re "And what is the procedure in case of using maven":
Does the introduction linked above help you in answering this as well?
Maven is supposed to work the same with any type of IDE.
I have a web service and I'm using the Endpoint.publish("http://0.0.0.0:8080")
Thing is that JAX-WS 2.0 and 2.1 is affected by an issue that throw a NullPointerException when executing endpoint.stop().
The issue is fixed in 2.2 but when adding the dependency in the pom.xml publishing fails due to a java.lang.NoSuchMethodError: javax.xml.ws.WebFault.messageName()Ljava/lang/String; since I'm using java 1.6.
The workaround is to add to the endorsed folder some libs. But I want to pack it all in jar-with-dependencies. An executable java jar.
Said this, I would be thankful if you help me:
Publishing the endpoint in 2.0 or 2.1 listening to all addresses (0.0.0.0)
or
Configuring dependencies in maven to pack everything using 2.2.x
but executable with JDK6
EDIT:
Requirements are a deliverable jar. A single jar that pack all of the dependencies (2 so far, about a 400k jar).
But if you think that the only way to make it work is to add an external shell script please let me know too.
Thank you!
The executable jar format does not allow for endorsed folders required for JAX-WS replacement (and neither does the Java WebStart launcher apparently).
You need to use something that can construct and execute a new "java" command on the fly. The best way from here is most likely to look for an installer which can run the program directly without needing to install.
What exactly do you need to happen?
EDIT: As the requirement is a runnable jar you simply cannot do this with JAX-WS 2.2 Find a workaround with the JAX-WS present in the latest release of the Java version you are targetting.
It is very nice that the JAX-WS stack ship with core Java allowign for very small deployments, but a pain that you cannot easily provide your own.
Note that you can provide your own with Java 5 but then you need to bring your own Endpoint implementation.
Do you need to use the JAX-WS RI? You could use CXF instead which is a fine JAX-WS implementation and doesn't suffer the same collision problems as the RI.
Edit: You could try to generate the classes with the RI, but use CXF in the deployment. JAX-WS is a spec after all so it should work...
I haven't been using Java extensively hence forget a lot fundamental things. Basically, I am working with a web-dynamic project (using Eclipse IDE with jdk 1.6), and during the build, I get errors that Cookie class and other web related classes cannot be found. What am I missing?
What Jars files do I need to add (and how)?
thanks
Think you need servlet-api.jar
Try here for any jar files you need http://www.java2s.com/Code/Jar/CatalogJar.htm
Sounds like you are missing servlet-api.jar
You can download it from the Maven repository.
Servlets are only part of the Enterprise Edition, not of the Standard Edition of Java. So you need the Java Enterprise Edition, AKA Java EE.
http://java.sun.com/javaee/
As others have said, you're missing the server api jar.
Having said that, downloading just the servlet api jar and not the server that goes with it means that you can't actually test your code.
In Eclipse, once you're installed a servlet container, such as Sun's Glassfish, Apache Tomcat, or Jetty, you can create a server instance of it so that Eclipse will compile against your server's servlet implementation. Creating a server instance also means that Eclipse's Run on Server command works.
IBM has a slightly outdated guide on Developing Web applications with Tomcat and Eclipse. The entire "Install the Web tools" section can be skipped if you have the Eclipse EE version, as Web Tools are already installed.