I had written a library and published it as a jar. Other applications used my library and everything was great.
Now the other application upgraded their dependencies. and now when they run. the application crashes when it calls my library. It seems that the application now depends on netty 4.1.8 whereas my library depended on a third party library which used an older version. Now when building the other application, sbt evicts my netty version with the newer one. The newer netty version does not have the method on which my code depends upon.
Thus the exception
org.jboss.netty.handler.codec.http.HttpRequest.setHeader(Ljava/lang/String;Ljava/lang/Object;)V"
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.construct(NettyAsyncHttpProvider.java:693)
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.buildRequest(NettyAsyncHttpProvider.java:650)
com.ning.http.client.providers.netty.NettyConnectListener$Builder.build(NettyConnectListener.java:144)
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.doConnect(NettyAsyncHttpProvider.java:1070)
com.ning.http.client.providers.netty.NettyAsyncHttpProvider.execute(NettyAsyncHttpProvider.java:935)
com.ning.http.client.AsyncHttpClient.executeRequest(AsyncHttpClient.java:499)
dispatch.HttpExecutor$class.apply(execution.scala:47)
dispatch.Http.apply(execution.scala:12)
dispatch.HttpExecutor$class.apply(execution.scala:42)
dispatch.Http.apply(execution.scala:12)
scalaxb.DispatchHttpClients$DispatchHttpClient$class.request(httpclients_dispatch.scala:21)
scalaxb.DispatchHttpClients$$anon$1.request(httpclients_dispatch.scala:6)
scalaxb.SoapClients$SoapClient$class.soapRequest(soap12.scala:41)
scalaxb.SoapClients$$anon$1.soapRequest(soap12.scala:23) scalaxb.SoapClients$SoapClient$class.requestResponse(soap12.scala:60)
scalaxb.SoapClients$$anon$1.requestResponse(soap12.scala:23)
I am already using the latest version of the 3rd party library (scalaxb) which depends on old netty.
This is really killing because my library is holding back the entire upgrade process of the application.
There isn't much you can do about this, aside from telling that application's maintainers that using your library requires that specific version of netty, and is not compatible with newer versions. They have to either downgrade back or replace you library with something else.
Related
I am working on a Project which is Using Socket-io library for WebSocket Implementation. So, basically the library that my server is using and the library that I have used in Front-End both have different versions. So, I am confused that is it fine or I should use the same version for both. Also, which one is Appropriate?
You will need to use the same version on both sides. You can review the migration section of the socket.io docs with the breaking changes from version to version. See links below:
2.x -> 3.0
3.x -> 4.0
I'm developing an Eclipse plugin and i've run into this problem several times already.
I always keep my Target Platform updated for the latest (stable) Eclipse release so that i test my code against all the recent updates, fixes etc.
However, this may (and have) result in accidental breakage of backward compatibility of my plugin, e.g. when i accidentally use new API that did not exist in the Eclipse version i aim to support.
Or, more sneaky example, in 4.6 Eclipse moved to Java 8 and some interface methods got default implementations. Now when i implement these interfaces my IDE doesn't automatically generate empty implementations for those methods and no error is generated. If i install and run this code against a previous Eclipse version these methods will throw AbstractMethodError since no implementation has been provided.
So my question is: is there a tool to further restrict API my Target Platform provides to some earlier Eclipse API version?
Is API Baseline an appropriate tool for this? Because i couldn't get it to work like this. (It allowed even non-baseline method calls not to mention the more complex default-methods example.)
You can use multiple target platforms, switching between them doesn't take long. For testing Stack Overflow questions I have one Eclipse install with 10 target platforms.
So have a target platform for the oldest release you want to support as well as your current release target platform and check the code runs against that.
It is particularly important to test with the actual Target Platform if you want to support Eclipse 3 releases as the were large changes going from Eclipse 3 to 4.
Can I expect that I replace the Java .jar files and client-side .js files of version 2.4 or 2.5 of CometD in an existing software that is running fine, with the same files in 2.9.1 and it all runs the same?
1- Are the API of CometD exactly the same on all 2.x versions?
2- Is there an upgrade guide that I can use?
Also, I noticed that on the client side, CometD 2.4/2.5 is not AMD and is a single file, but on 2.9.1 it is AMD-based. Is there a single .js file that contains all client-side CometD code?
You can expect upgrades from 2.4/2.5 to 2.9.x to be either without problems, or requiring very little changes, so yes, it should be typically be a drop-in replacement.
While you're upgrading, I suggest to move to CometD 3. You can find here the migration guide from CometD 2.x.
CometD 2.9.x is AMD compliant, and the single file you should include in your HTML is typically org/cometd.js along with a binding for a toolkit (either jquery or dojo).
If you use extensions, you should add also those, see for example http://docs.cometd.org/3/reference/#_primer, or if you don't want to use Maven, this other section.
Follow also the tutorials, that should get you going.
Full documentation link.
I was looking around and couldn't find this anywhere, but is there any way to update the JRE through a java application and then to restart said application using the new JRE?
Updating the JRE from within a running Java app. is not something that is commonly done.
Instead look to deployJava.js for ensuring a particular major version of Java is installed, and Java Web Start for ensuring a particular micro-version is available.
These technologies are both related to launching rich clients (applets and desktop apps.) so if the app. has a GUI as mentioned here it should be 'all systems go'.
Is there a service available that responds with the latest version of Java that's available?
I'm writing system check for an application that uses applets. As part of the check I'd like to inform users if a new version of Java is available for download. Is there any online service that simply responds with the version number for the latest Java version?
How about a different strategy of 'leave it to the manufacturer'?
The JRE is configured by default to be auto-updating to the latest version Oracle considers to be stable enough for general use. Best leave it to the auto-update feature.
Run-time testing
Of course, there is always How do I test whether Java is working on my computer?
FireFox
An old version of Java has been detected on your system.
Update Java by clicking the button below:
A polite way of saying 'no plug-in found for FF'.
Chrome
User Friendly
But ultimately either way, leave it to the end-user's discretion as to what version to use, and whether to update.