I've found out that it is very uncommon to choose a client version that is not the same as the server's version (for example in HBase client - server’s version compatibility).
On the other hand, I've got an answer about Camel compatibility that had been mentioning the Camel-HBase jar that I can find a fit version of the client's jar through downgrading it (for example https://mvnrepository.com/artifact/org.apache.camel/camel-hbase/3.1.0 for an old HBase version). But this answer also said that it is a bad thing to do (Can Apache Camel integrate with an old HBase version?). I wonder what is the solution if there is no such option for me to upgrade the HBase server (since it's not mine). Why choosing a lower Camel component (such as Camel-HBase) version is bad?
It's impossible to work otherwise since it will demand every integrated technology to be the most upgraded.
Sorry, obviously my answer you mention was not clear enough.
You absolutely can use an older Camel version whose dependencies match your specific Hbase-client version need.
But this decision hat some drawbacks:
You cannot upgrade your Camel application (version lock-in)
You cannot use another Camel component in the same application that has a more recent version because mixing Camel component versions (eg. camel-core 3.9.0 and camel-hbase 3.1.0) leads to lots of problems
The consequence of these points is that you probably have to "isolate" your Hbase integration in a Camel application that uses an old, "freezed" Camel version.
"Isolate" because as soon as you want to do something else that needs a newer Camel version, you have to build a new application that communicates with your hbase-integration through an API.
I hope, this answer makes more sense for you.
About your final statement
It's impossible to work otherwise since it will demand every integrated technology to be the most upgraded.
There are a lot of technologies that offer a much wider compatibility. Messaging clients like Kafka or ActiveMQ are wire-compatible with older server versions.
Related
I use the Storm Apache in 1.0.0 version (java client - storm-core) and zookeeper in version 3.4.8. I check the version 2.0.0 is "significant improvements in terms of performance, new features, and integration with external systems". What is the steps needed to this upgrade?
Thanks all
As far as I know it's pretty much the same procedure as any other Storm upgrade:
Stop the Storm services (e.g. Nimbus, Supervisors) on the machine you want to upgrade.
Download and extract the new Storm release on the machine. Make any changes to storm.yaml that are appropriate to your environment (e.g. set nimbus.seeds)
Restart the Storm services using the new code
Check that everything appears to work in Storm UI, and that the new machine has joined the cluster
Repeat for the next machine in your cluster
You also want to update your topology jars. Point your dependency management at Storm 2.0.0 jars instead of 1.0.0. Most likely your topology will compile, if not you can probably find deprecation notices in the Storm 1.2.3 javadoc for any methods you might be using that are removed. These notices will likely also tell you what to do instead.
Finally instead of having a dependency on storm-core, you now want to depend on storm-client. The scope should be provided, same as in 1.0.0.
If I were you I would try this out in a test environment first, so you can catch any surprises before you try upgrading your production environment. You should also consider upgrading to 1.2.3 before you upgrade to 2.0.0, as that will let you see any deprecation notices in your code, and is likely to let you make any necessary changes to your code more gradually.
An important part of the JavaEE platform is backwards compatibility, but I'm curious what that entails for configurations. I'm especially interested in the standalone.xml configuration for WildFly; can I expect the options in it to be stable across versions of WildFly? Or maybe just parts of it?
The WildFly team tries to keep the configuration compatible or offer a migration tooling (for example when moving from jboss-web to undertow). If you're concerned about long term stability then maybe you should use Red Hat JBoss EAP which is a productized version of WildFly.
I think so, but you need to be up to date on each version, with the new releases. The standalone.xml file is updated with a lower frequency than the own server implementations, its base is practically the same since our old JBOSS. I've been using wildfly since its early versions and never had backward compatibilite issues.
What I see happening a lot is that most of the developers do not know the dependencies that the server implements and end up having problems in deploy, jar hell and problems in rutime due to lack of knowledge of the dependencies.
In my opinion widfly is the best server full JavaEE, but there are things I think are bad, one of them is the use of CXF in webservices. Do not worry about standalone.xml, I have not seen to add any feature to cause compatibility issues.
We're experiencing a bug in Glassfish 3.1.2.2 (specifically, in the WSEndpointImpl class in Metro module) which is fixed but due in Glassfish 4.0 or some next release in the 3.1 branch hopefully. As this fix is critical for our application, we would like to patch this class alone and install it somehow to Glassfish, before waiting for the next release. Is this possible? What do you recommend?
Glassfish supports swapping in other versions of certain modules via the Endorsed Standards Override Mechanism and according to the Oracle documentation JAX-WS is among the replaceable components.
You just have to copy the updated version into the /lib/endorsed directory of your domain, but I'm pretty sure you can also put your file in the /lib/endorsed directory of the Glassfish server itself.
See a practical example in this blog entry
Currently our production environment runs JBoss 5.1 and we have been debating whether or not its worth migrating to JBoss 7.1. If it was a simple server upgrade, then it wouldn't be a problem. But, unfortunately, we would have to change configurations and that would take some effort. Also, our server runs in a cluster and I read that JBoss 7.1 has more cluster support.
So is it worth it or not?
Thanks
We're currently in the same situation.
There seem to a a lot of things on the positive side:
We'll have to migrate off 5.1 at one point. We need full profile and there are not that many OSS alternatives (GlassFish and maybe Geronimo). That point alone will probably sell the migration since PCI-DSS forbids us to use EoL'd software.
The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files but one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard appreciate this if you've never configured a JBoss.
The EJB remoting no longer uses a thread per socket.
Removing a subsystem you don't need is so much easier.
The class loding model looks sane and you get a lot of control through jboss-deployment-structure.xml
The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
While we're not too excited about Java EE 6 replacing some of our SLSBs with #Singleton beans and some of our SARs with timer EJBs certainly looks interesting.
Faster start up and less memory usage (at least for an empty server or small deployments). We haven't yet tested a large deployment.
The deployments folder is empty by default
Things that we still need to look into:
We're a bit worried about Infinispan performance. We currently use the TreeCache API of JBoss Cache. While there is an adapter for Infinispan that provides the same API some theoretical tests show worse write performance. This only applies to the tree API of Infinispan.
ExternalContext is no longer supported, we currently use it to populate a JNDI tree from a .bindings file
JMX console is gone, if you have anything that builds on this it needs to be adapted, Edit there is actually a port of JMX-Console available AS7-2227
We don't run in a cluster so I can't comment on that.
What will probably be the biggest effort for us is migrating all the shell scripts (installation, integration tests, …) that interact in one way or another with JBoss.
Update
We have migrated and it was definitely worth it. Some updates to the points above:
Even large deployments are fast with minimal amounts of tuning.
The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
7.1 has so many bugs it was unusable for us, so we are on 7.2 / EAP 6.1 and plan to go to 7.3 / EAP 6.2. Still has its fair share of bugs but we can work around them. We're especially looking forward to role-based access control for the management interface which will allows us to run our scripts with minimal privileges.
There will not be a supported version of GlassFish 4 which puts a big question mark on it for production use.
EJB remoting security is a lot less flexible. We had to put in some workarounds since previously we were mixing authenticated and unauthenticated EJB calls — this is no longer possible.
The JEE 6 BOM POM from JBoss is a mixed bag. In theory it is nice because it manages the versions of all you JEE dependencies. In practice the coordinates are horrible with the version in the artifactId which is going to be annoying when we migrate to JEE 7. Also it isn't very helpful when you want to include an implementation of a JEE API for tests.
Infinispan tree API performance was not an issue.
We replaced the JMX-Console scripts with DMR scripts.
Update 2
There is a deadlock when using EJB remoting over SSL. This deadlock is present even in EAP 6.2. We're now at the point when we have quite a patch set of features backported from WildFly to AS 7.
Is everything working on JBoss 5.1.0 for you? Is your performance something you can live with?
I'm currently in the middle of upgrading from JBoss 5.1.0GA to JBoss 7.1.1 and it has not been easy at all. You're basically upgrading to a new application server. You will need to budget a lot of dollars for this effort I'm guessing.
Having said that JBoss 7.1.1 is VERY fast compared to 5.1.0 (start up times at least). I think in the next 6 months (or so) most of the "hard" migration and transition issues will be fleshed out in the jboss forums or through bug fixes. At that point you and your team can reevaluate if you want to do the migration.
Good luck!
If you are using SSL, one advantage to upgrading is that JBoss 7.1.1 runs on jdk 1.7, which has support for TLS 1.1 & 1.2, while jdk 1.6 only supports up to TLS 1.0. JBoss 5 will not run on java 1.7 so you are susceptible to a BEAST attack.
Regardless, I'd wait a bit.
AS 5 is a EE5 server, AS 7.1 is a EE6 server (and EE6 spec came out in 2009). So that's alot of work for an excellent new runtime environment, but it won't give you any hot architectural possibilities.
The WildFly 8.0.0.CR1 is already due and that's EE7 server bringing you a bunch of new interesting developing possibilitites, like WebSockets and JAX-RS 2.0 (http://www.slideshare.net/dandreadis/2013-11devoxxwild-flybof). New admin features like Single Instance Patching. And it's not sure that AS7-to-WildFly8 will be a super-easy migration since som major new stuff is introduced, like Undertow instead of JBossWeb/Tomcat.
If you gotta go, you gotta go - and if U wind down the dead 7.x path, don't forget to get your hands on the much improved 7.2.0.Final tag (several hundred issues better that 7.1.1). But if you think you can start developing/migrating now using Beta/CR releases and wait some months for a nice production-stable WildFly 8.x.x release, you might be able to sit tight longer before next major update.
br,
Jens
Folks, I am in the process of releasing a plugin for Solr (under ASF license) that implement different ranking strategies. I have tested it against 3.5 version, it works great, since I started fairly recently on open sourcing it went with latest version of Solr (3.5). But then a request came in to use that plugin for version 1.4. The problem is that Solr API has undergone some significant changes between 1.4 & 3.5.
For instance, SolrQueryResponse was moved from
org.apache.solr.REQUEST.SolrQueryResponse (1.4)
to
org.apache.solr.RESPONSE.SolrQueryResponse (3.5)
I use Git for DVCS, Maven for Build/Project Management, Google Code for project hosting, what would be an ideal strategy to make changes & maintain the code for different versions of underlying Solr/Lucene API. Branch could be way to achieve it, but I am not really convinced.
Would like to know if there is a better way to develop/maintain code for different underlying API versions & distribute them ?