I have been working with Jboss Fuse 6.1.0.redhat-379 for about a month with great results and higher productivity in EIP. Thank you very much to the community for building such a great product.
Now I am getting ready to deploy my bundles in a dev enviroment with several camel routes and even multiple camel contexts in a single bundle and I'm noticing a weird behavior regarding camel contexts JMX display. The bundle with the multiple camel contexts is only showing the first context, others contexts work fine but they are missing in camel JMX display in hawtio.
After research about this behavior I encountered with this JIRA issue https://issues.apache.org/jira/browse/CAMEL-7545 opened by Claus, describing exactly this problem and manifesting that there are Fix Versions (2.12.4, 2.13.2, 2.14.0)
AFAIK my Jboss Fuse version is distributed with camel 2.12.0.redhat-610379 version and there is a mayor 2.14.0.redhat-620031 version that supposedly will fix this issue and it will be bring many other features like json path and sql generated keys.
Is there a way to upgrade versions of camel features in Jboss Fuse?
UPDATE
There is a similar question for this topic (Updating camel version in fuse esb) accepted answer discourages trying to update the version, however, I think it should be better to permit version upgrades if they fix issues
Not a 100% on this but the rollup patches might include the 2.12 fixed versions. Install the latest patch and see if that fixes the issue.
Related
I wonder if it is possible to integrate an old version of a Camel component, with an application of a newer Apache Camel version. In my case I want to integrate to Hbase server version 1.2, that is supported only with HBase client 1.2. Therefore even though I want to use a 3.1 Camel version, I want to use the 3.0.1 version of Camel-HBase component. Is it a fine thing to do?
Or is there any place that I can see the versions of the libraries Apache Camel supports?
You can check the Camel dependencies POM to find the versions of dependencies that are imported by the different components.
See the dependencies POM of Camel 3.10.x. You will find <hbase-version>2.3.1</hbase-version> in it.
Another source is Maven Central where you can see the dependency versions of a specific Camel component version.
See Camel-HBase 3.1.0 that references Hbase-client 1.2.6.
However, normally one cannot choose the Camel version to match a specific component dependency version. In general it is the other way round. You want or have to work with an already existing version or you want to use a current version to get the best of the framework.
If you build a new application with Camel 3.10.x, you get the hbase-client in version 2.3.1.
If newer Hbase client versions are not compatible with Hbase 1.2 it becomes difficult.
you get lots of problems when you mix and match Camel component versions
even if you can build your application with an older Camel version, you could never upgrade
The only solution I see would be to isolate the Hbase integration in its own (freezed) application with an older Camel version that matches your desired Hbase-client version.
I am planning to migrate from Fuse jboss-fuse-6.3.0.redhat-329 to Fuse 7. I am using camel version 2.17.0.redhat-630329. Can anyone please guide me on the steps and issues faced while migrating?
First of all its good that you plan to upgrade from Fuse 6.3 to 7.x.
I recommend to upgrade to the latest Fuse 7.7 release in order to benefit from additional bug fixes, CVE fixes and enhancements.
Your migration to Fuse 7 will upgrade Camel from 2.17 to 2.21.
I suggest you have a read over the Fuse 7.0 migration guide [1], which specifically covers the migration from Fuse 6.3 to 7.
Then you may also want to peak at the migration guide of the specific 7.x release that you are upgrading to, for 7.7 it will be [2].
Please also check for deprecated components...
In terms of Camel, it will depend on the Camel components used if there are any code changes needed or not. For the vast majority of components no changes should be required.
Potentially you only need to recompile your application against the latest Fuse 7 BOM and redeploy the application (in case of Karaf of EAP runtime).
I hope this helps as a starting point.
[1] https://access.redhat.com/documentation/en-us/red_hat_fuse/7.0/html/migration_guide/index
[2] https://access.redhat.com/documentation/en-us/red_hat_fuse/7.7/html/migration_guide/index
I am trying to build a highly available, scalable and performance optimistic Jboss cluster system. I will be using Infinispan subsystem for caching service.
I started off with Jboss 7.1.1 Final version but later on found that it has some really serious bugs. Also, the infinispan subsystem was not behaving as per my requirements in the same.
As of now, I need to evaluate different versions of Jboss which suffices above mentioned requirements.
Please let me know which the most stable and latest version of Jboss currently available.
Just for information, I am performing the whole stuff in Cloud (AWS).
JBoss Application server was renamed to Wildfly, checkout its downloads page. Right now it is stable 9.0.1 (I think this is using Infinispan 7.x) and unstable 10.0.0.Beta2 (I think it still uses 7.x too since Infinispan 8 was not released yet, but it's possible that version 8 will get into the final release).
have anyone done something like upgrading embedded jackrabbit server in Apache Sling v. 2.1?
I'm not sure if it will be compatibile with sling.jcr.api.
Can new version of Jackrabbit be provided as an osgi bundle or is it better to rebuild whole sling?
I cannot find nothing about that in documentation.
You should be able to simply upgrade the dependencies. The Sling bundles are typically backwards compatible, so just try it. If anything breaks, it's probably a bug and should be reported.
We have been using the Apache ActiveMQ and Camel products for a while now but want to look at a good base ESB. I've been reading the Redhat site about Fuse but have been unable to find a good summary of the significant differences between Fuse and Apache for coders.
From a designer's/developer's point of view what are the significant differences between Fuse and the Apache Camel and ActiveMQ that we have been using? I get the lovely overview stuff, FuseIDE and the ESB management tools. But I really just want to know of the differences at the code level, i.e. does it introduce more useful Camel endpoints? are there additional libraries of genuinely useful things that will make my life as a designer/coder easier? are there any pitfalls to look out for?
I just need a few pointers to help me in my search, not a tome. Or better still a quick link to a document that goes over all this (ever hopeful :o) !) I have a short time to form a view to go forward on or the opportunity will pass me by.
Thank you.
SK
At the code level there is "no" difference. The process is that we develop on the Apache projects, and sync the code changes to Red Hat / Fuse git repos. There we cherry pick the changes we want to go into our branches, to keep the product stable. As well backport fixes to older branches if our customers need that / etc (eg you can influence that)
The products from Red Hat is also supported on a much longer timespan than the community support from Apache. There is a guranteed lifetime which you can find here: https://access.redhat.com/support/policy/updates/jboss_notes/
There is only a few additional Camel components from Fuse / JBoss Fuse products, which is part of the open source project Fuse Fabric (http://fuse.fusesource.org/fabric/) which is part of the JBoss Fuse products. Fuse Fabric is in the process of being donated to Apache ServiceMix, so it can benefit that community as well, allowing ServiceMix to bundle Fabric out of the box as well. Fabric has a few Camel components that allows sending messages to a any Camel endpoint that load balances automatic in a clustered environment / cloud environment. And there is another Camel component for selecting a master, and only run the route on the master node, and if the master dies, then another node takes over.
I also think that this move is a testimony of the open source
willingness the Fuse team has and continues to have. We do as much as possible
in the opening. For example the new project - hawtio (http://hawt.io/)
is also fully open source, ASL license, github project, anyone can contribute/fork etc.
And the JBoss Fuse product allows to patch itself in production. So if you need a hotfix asap, we can provide a fix as a .zip file which can be patched using a built-in patch tool in the product. This isn't possible from Apache.
A few links for further material (from our old site and the jboss community site)
http://fusesource.com/enterprise-support/support-offerings/
http://fusesource.com/community/apache-committers-and-fuse/
http://www.jboss.org/products/fuse
http://www.davsclaus.com/2013/04/apache-camel-web-dashboard-with-hawtio.html
Disclosure: I work for Fusesource / Red Hat.
On a code level, the difference is very small, if any at all.
What you get from the commersial RedHat package is support, a package that has been tested and operational benefits (that you mention).
It's all about what happends after the code is made - when you put your things to production and the coder is not still around to handle incidents.
Apache ActiveMQ and Camel are open source projects. Redhat fuse bundles them and possibly many other components into one package and so it can be used as one ESB package. I see the biggest difference as the support that you can get. You can get support for something that your organization has not produced. And the tools that comes with the package does help during development and maintenance in my view.