Add Apache Camel integration sample

[yacota]

Suggestion,
integrate Apache Camel in order to facilitate EE solutions that need to use EIP and deal with a broad range of protocols not supported by a default EE container

Also apache camel has some really nice and remarkable components like

• Quartz - http://camel.apache.org/quartz2.html - already done by Arun in Add Quartz integration sample #6
• Search engine capabilities by using one of their search components - http://camel.apache.org/lucene.html
• Bean Component (pojo consumer and producers) - http://camel.apache.org/bean.html and http://camel.apache.org/pojo-consuming.html not only for JMS
• much more, sure you know

Cloud relative stuff

• Amazon cloud component - http://camel.apache.org/aws-cw.html (http://aws.amazon.com/es/cloudwatch/) you can monitor your EC2 and RDS DB instances, and add or remove them dynamically when needed

• JClouds component - http://camel.apache.org/jclouds.html . quote "ComputeService simplifies the task of managing machines in the cloud. For example, you can use ComputeService to start 5 machines and install your software on them."
  --> I think that jclouds is the defacto standard for Java cloud management, included in Camel, and therefore by using jclouds and some kind of "camel dynamic router builder"(@DynamicRouter), cloud instance governance could be done in an EE container (just and idea)
  --> A concrete sample ? Mmmm...thinking

  What do you think?

  Thanks

  J

[brunoborges]

I can see several examples of Apache Camel and Java EE, but none in particular that could actually become one example-to-rule-them-all, which then makes no sense to actually write one. I've been playing with Camel for years (I wrote the Twitter component). The framework is very flexible, and there are a few ways to start the CamelContext in a Java EE environment (from a @startup bean, a Servlet, a @PostConstruct, etc). And that's it. The rest is all about Camel itself, not Java EE anymore.

Would an example like this be good enough for you?

[yacota]

You are absolutely right about Camel's (I love it too : ) ), "@startup bean" sample will be a nice entry point for Camel.

In regarding about cloud and Camel, some of camel's components let developers manage cloud stuff : storage, #instances, scale on demmand ... and so on ... correct me if I am wrong but there's no JSR about it, but for me the possibility of managing a cloud provider through an EE server is very attractive, As I said just an idea

Thanks again

[arun-gupta]

Starting work on it at https://github.com/javaee-samples/javaee7-samples/tree/master/extra/camel. Still throwing:

Deploying /Users/arungupta/tools/wildfly-8.1.0.CR1/standalone/deployments/camel.war
{"JBAS014671: Failed services" => {"jboss.deployment.unit."camel.war".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit."camel.war".WeldStartService: Failed to start service
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type CdiCamelContext with qualifiers @default
at injection point [BackedAnnotatedField] @Inject org.javaee7.extra.camel.Bootstrap.context
at org.javaee7.extra.camel.Bootstrap.context(Bootstrap.java:0)
Possible dependencies:

• org.apache.camel.cdi.internal.CamelContextBean@5af5b220,
• Managed Bean [class org.apache.camel.cdi.CdiCamelContext] with qualifiers [@Any @default]
  "}}

[arun-gupta]

Works fine in JBoss EAP 6.2

[arun-gupta]

Fails in WildFly 8.0.0-FINAL as well

[cmoulliard]

I must have a look but I think that this issue is related to Weld (cdi 1.1). We have to create an arquillian test to figure out the problem and find a solution.

[antoinesd]

Last time I checked Camel-CDI it was a total mess. @cmoulliard I renew my proposal to help you put that straight...

[cmoulliard]

Hi Antoine,

I should have more time after the 13th of March. So we will work on that

Regards,

Charles

On Fri, May 2, 2014 at 8:43 AM, Antoine Sabot-Durand <
notifications@github.com> wrote:

Last time I checked Camel-CDI it was a total mess. @cmoulliardhttps://github.com/cmoulliardI renew my proposal to help you put that straight...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/36#issuecomment-41995975
.

Charles Moulliard
Apache Committer / Architect @redhat
Twitter : @cmoulliard | Blog : http://cmoulliard.github.io

[antoinesd]

Hope you mean May 13th because March 13th 2015 is a bit late ;). Ok for me.

Le 2 mai 2014 à 11:00, Charles Moulliard notifications@github.com a écrit :

Hi Antoine,

I should have more time after the 13th of March. So we will work on that

Regards,

Charles

On Fri, May 2, 2014 at 8:43 AM, Antoine Sabot-Durand <
notifications@github.com> wrote:

Last time I checked Camel-CDI it was a total mess. @cmoulliardhttps://github.com/cmoulliardI renew my proposal to help you put that straight...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/36#issuecomment-41995975
.

Charles Moulliard
Apache Committer / Architect @redhat
Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
—
Reply to this email directly or view it on GitHub.

[cmoulliard]

13th o May ;-)

On Fri, May 2, 2014 at 11:07 AM, Antoine Sabot-Durand <
notifications@github.com> wrote:

Hope you mean May 13th because March 13th 2015 is a bit late ;). Ok for
me.

Le 2 mai 2014 à 11:00, Charles Moulliard notifications@github.com a
écrit :

Hi Antoine,

I should have more time after the 13th of March. So we will work on that

Regards,

Charles

On Fri, May 2, 2014 at 8:43 AM, Antoine Sabot-Durand <
notifications@github.com> wrote:

Last time I checked Camel-CDI it was a total mess. @cmoulliard<
https://github.com/cmoulliard>I renew my proposal to help you put that
straight...

—
Reply to this email directly or view it on GitHub<
https://github.com/javaee-samples/javaee7-samples/issues/36#issuecomment-41995975>

.

Charles Moulliard
Apache Committer / Architect @redhat
Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/36#issuecomment-42006456
.

Charles Moulliard
Apache Committer / Architect @redhat
Twitter : @cmoulliard | Blog : http://cmoulliard.github.io

[arun-gupta]

mvn package will build the WAR file here. I'll Arquillian-enable it before 5/13.

[intuitiveminds]

Hello all,

any news on this particular issue? I am currently trying to deploy Camel using CDI in Wildfly 8.1 final but get the "Ambiguous dependencies" exception seen above.

Thanks in advance

Sven

[ilmuc]

Hello,

I had the same problem. I had to use weld:scan in beans.xml@Glassfish3 and remove the ambiguous reference to CdiCamelContext.class

[intuitiveminds]

ilmuc's workaround did not work on Wildfly 8.1 (at least not in my scenario), but I was able to circumvent it nonetheless by creating an extension in my own project and vetoing the processing of CdiCamelContext.class. For anyone having to do the same, this is my solution:

public class CoreExtension implements Extension {
    void interceptProcessAnnotatedTypes(@Observes ProcessAnnotatedType processAnnotatedType)
    {
        if (processAnnotatedType.getAnnotatedType().getJavaClass().getName().equals("org.apache.camel.cdi.CdiCamelContext")) {
            processAnnotatedType.veto();
        }
    }
}

Simply create a file called META-INF/services/javax.enterprise.inject.spi.Extension and put the fully qualified class name of this extension into it and that should do the trick.