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 https://github.com/arun-gupta/javaee7-samples/issues/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/javaee-samples/javaee7-samples/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/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.

[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/javaee-samples/javaee7-samples/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.

[myfear]

@arun-gupta it is true, that the beans.xml solution isn't working. It only impacts the bean discovery in the archive, where it actually resists. Which is not true in this case, because both ambiguous dependent beans are part of Camel. @svenpanko's workaround is the only way to do it as of today. Weld:scan in GF 3 works, because it is still Weld 1.x (cdi 1.0). I'm opening a ticket with the camel community and see, if we can get it fixed. UPDATE: https://issues.apache.org/jira/browse/CAMEL-7760

A working example with the Veto-Extension approach can be found here: for the impatient. https://github.com/myfear/CamelEE7

[arun-gupta]

@antoinesd @cmoulliard would know ?

[johnament]

I'm also a bit curious where CDI support for Camel ended up. There was a short lived attempt by myself and Romain Manni-Bucau to try to revive it, ended up with me creating Injectahvent as a POC. The best way to work with it (Camel-CDI) currently is to extend CamelContextAware, providing a setter for the camel context, and registering your custom routes that way. You can also just extend RouteBuilder and it should be picked up by the extension automatically.

[astefanutti]

Hi all,

I've just added @myfear's example to the revamp version of the CDI Camel extension that I'm working on: javaee7-samples test.

It's tested as an Arquillian test here: CamelEE7Test and works fine. To run it:

git clone https://github.com/astefanutti/camel-cdi camel-cdi
cd camel-cdi
mvn install
mvn test -pl envs/ee -Pwildfly -Dtest=CamelEE7Test

I'm close to having that improved version done:

• It leverages the latest version of the CDI specification,
• It fixes a large number of the outstanding issues in the Camel CDI backlog,
• It is written with the CDI programming model in mind so that should address @antoinesd concerns,
• It is tested against Weld 2.x, OpenWebBeans 2.x (yet to be released) and Wildfly 8.1.

The project is here: https://github.com/astefanutti/camel-cdi. I'd be glad to have that code contributed to the Apache Camel project.

[johnament]

Honestly, for me the big thing missing in Camel CDI is support for outbound CDI events, as well as registration of inbound events. CDI support would gain so much from having an observer method defined like this:

    public void receive(@Observes @To("") Object obj, EventMetadata eventMetadata) {
        String destination = null;
        for(Annotation a : eventMetadata.getQualifiers()) {
            if(a instanceof To) {
                To to = (To)a;
                destination = to.value();
            }
        }
        producerTemplate.sendBody(destination,obj);
    }

When obj is probably an Exchange (so send instead of sendBody) and To is a qualifier indicating what the endpoint is to send to. Likewise, need a way to setup observer methods that receive from URI's defined.

[myfear]

@johnament can you put a feature request into the bug tracker? Makes total sense to me. Would love to try to drive that.

[astefanutti]

@johnament, definitely. To push that idea further, transactional observers could be supported in order to bind the delivery of the event to transaction phases, e.g.:

void receive(@Observes(during=AFTER_SUCCESS) @ToEndpoint("url") Exchange exchange) {
    // exchange sent to endpoint "url" when the transaction is committed successfully
}

And that could be generalized to any Camel Processor with an explicit id defined (as in ProcessorDefinition) so that AOP on the Camel model could be declared via CDI observers, e.g.:

void interceptProcessor(@Observes @Before @Node("Id") Exchange exchange) {
    // intercept the exchange before processor with id "id"
}

Finally, the event type could support the Camel parameter binding annotations so that one can write:

void void interceptProcessorBody(@Observes @Node("Id") @Body String body) {
    //...
}

@antoinesd and I will be talking exactly about that at JavaOne 2014 in "Going farther with CDI 1.2", hence my current work on Camel CDI.

@myfear, I'd love to help you driving further the elaboration of samples that show the real power of Camel and CDI put together, which I understand is the point of that issue. In that perspective, as @davsclaus is completing the work of integrating Camel and Metrics, I think that Camel + CDI + Metrics (I've done the Metrics + CDI part in Metrics CDI) all glued together would be an even more powerful combo that'd really make value-added examples IMHO.

[fthamura]

by bring camel, will this javaee-example extended to bring non javaee to the example project?

[tdiesler]

RedHat is doing work on this with a dedicated camel subsystem https://github.com/wildflyext/wildfly-camel

[fthamura]

i love we have comparison run camel on jboss and on karaf :)

we use camel intensively here

Frans Thamura (曽志胜) Shadow Master and Lead Investor Meruvian. Integrated Hypermedia Java Solution Provider.

Mobile: +628557888699 Blog: http://blogs.mervpolis.com/roller/flatburger (id)

FB: http://www.facebook.com/meruvian TW: http://www.twitter.com/meruvian / @meruvian Website: http://www.meruvian.org

"We grow because we share the same belief."

On Thu, Nov 6, 2014 at 10:37 PM, Thomas Diesler notifications@github.com wrote:

RedHat is doing work on this with a dedicated camel subsystem https://github.com/wildflyext/wildfly-camel

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