Hy there,
I'm currently writing a camel client, that integrates into our companies file transfer tool.
As our next feature, we want to be able to scan files, that are send via our software with some antivirus software.
For different reasons we decided to do this with our camel client.
After resarching a bit I could not find any article or project, that talks about camel and scanning files for viruses.
Does anyone have any experience with this topic or is there something planed for camel to have an component for this in the future?
I think as the first step having a clamav client as a component would be awesome.
Any thoughts?
Greets
Chris
Related
I am trying to explore is there any tools or any document is available in order to do the Migration from Mule into Apache camel.
please share if anything is available.
Thanks
Arun K
After a quick Internet search I suspect the answer is no. Probably their models are two different. You will need to rewrite from scratch the integrations. Note that Camel.appears to favor a Java DSL approach while Mule uses an XML DSL to configure flows.
However if you have a significant number of integrations in Camel XML DSL it might make sense to create a translator at least to get some base translation that will need to be completed manually.
I have gone through google but I didn't find anything like how to execute sftp commands using Apache camel could any one refer the example or some link relevant
to the example. any help is greatly appreciated.
The camel-ftp component (and all the other Camel components) are intended for exchanging data (messages) between systems. They are not really intended for a Java client library with a free API you can do all sorts of thing with.
So if you want to do some special things on the FTP server then maybe use the Java FTP client API directly, and not the camel-ftp component.
That said the camel-ftp component has a download=false option you may be able to use to consume the FTP files metadata (name, size etc). But again the consumer is intended for keep monitoring the FTP server and download new files. So its not a perfect fit for your use-case.
I am currently learning Camel, and have a specific project in mind that requires a Websphere MQ back-end, but I can't use JMS components, since I need a lot of non-jms headers, like MQIIH.
I found the camel-wmq project.
Is it the recommended solution ? Is it any good ?
You don't need to use jms. WMQ has a client API. Just download the wmq client jars and put them in your project and use them together with your Camel routes. You will probably put the wmq client code in a processor class or something similar. Off course best to test to put a message on a queue manually via RFHUTIL or something similar as a client so you are sure the environment setup is correct.
The suggested way of working with WMQ has always been through the JMS component since it enables you to painlessly switch to other providers if the need arises.
However, if you need to use some WMQ-specific function then my suggestion would be to extend the camel-wmq library - it contains only a subset of features supported by WMQ and does not support MQIIH headers that you need. Adding functionality to a component would probably involve more work than the solution Souciance Eqdam Rashti suggested but it would be a cleaner solution and more in line with Camel's philosophy. Also, you'd be giving back to the community and thus help make Camel a better tool for everyone :)
I would also suggest you go through the IBM MQ discussions on the Camel's official user group mailing list and see if you can salvage anything.
I am studying Apache Camel.
Could some one please explain the difference between a processor, component and endpoint with regard to Apache Camel.
A component allows you to talk with other systems. It allows you to send or receive messages and encapsulates the protocol to deal with another system. For e.g. jms-component allows to talk with JMS brokers.
An endpoint is nothing but the channel by which you send or receive a message through component e.g. "jms:queue:order" this defines a jms endpoint which is a queue from where your (jms) component will either consume or publish a message.
While a processor is piece of code which goes in between routes. There you write code to manipulate (transform/enrich/extract etc.) the message or have some integration logic.
For more details refer to camel's documentation
All whom are new to Apache Camel I suggest to read this article which explains really well what Camel is, and has an example to go along.
http://java.dzone.com/articles/open-source-integration-apache
Another great piece is chatper 1 of the Camel in Action book, which can be freely downloaded from here: http://www.manning.com/ibsen/Camel_ch01_update.pdf
Disclaimer: I am co-author of that book.
And there is this old by good tutorial that still applies today: http://camel.apache.org/tutorial-example-reportincident.html
And you can find more tutorials / examples on the Camel website
http://camel.apache.org/tutorials.html
http://camel.apache.org/examples.html
And there is also some links to 3rd party blogs/articles/videos about Camel, where you can find some great information:
http://camel.apache.org/articles.html
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.