3 Replies Latest reply on Jul 15, 2011 7:57 AM by kcbabo

    Tighter CDI + Camel integration

    tfennelly

      I started playing with this a little.

       

      First thing I tried was to see what would be involved in wiring the CDI BeanManager into the CamelContext used by our camel components.  Could we reference CDI beans from Camel routes in the same way you can reference Spring beans e.g. to("bean:MagicCDIBean"). 

       

      I first created a Camel Registry impl which has access to the CDI BeanManager.  Hit issues here doing the name (String) based lookups on the BeanManager... never seemed to work... all the cdi beans seem to have a null name and I can't set them.

       

      Then I decided to just focus on exposing SwitchYard CDI bean Services as beans through this Camel Registry.  I got this working through a hack... by matching up the requested bean name against the SwitchYard CDI Bean service QName.

       

      You can see the code here:

       

      Not really sure what this gets us so far.  We can already invoke SwitchYard services from camel using "switchyard:/XXXService".  Difference is, the "switchyard:/..." version is going through the SwitchYard exchange mechansim.

       

      There's also this Github project which is interesting: https://github.com/obergner/camelpe.  I'm waiting on an email reply from the author, hoping he might have some useful input.

       

      Keith... I know you had some ideas... fire them out here please

        • 1. Re: Tighter CDI + Camel integration
          kcbabo

          Tom and I had a quick chat on IRC about this, so I'll summarize for the forum thread.

           

          The main thing we are trying to do is make CDI beans available as bean references within a Camel route.  It's common to augment the processing logic of a route with a bean definition and bean references can also be used in endpoint configuration (IIRC) to influence component behavior (e.g. filtering).  This type of thing is specific to the Camel route and distinct from CDI services which have been registered on the bus.

           

          We discussed possible ways to wire this in and Tom believes that we have most of the plumbing in place today.  What we need to add is the ability to register CDI beans by name.  The @Named annotation looks promising for this purpose.

           

          One other item we discussed is the use of the Camel test support (test/mock endpoints) in a Camel MixIn.  One of the nice things here is that you can test @Reference invocations using mock endpoints defined in Camel.  I'm sure there's lots of other possibilities too.

          • 2. Re: Tighter CDI + Camel integration
            tfennelly

            I've rejigged a bit and have the same thing working for any CDI bean in the module (I'm assuming it won't work for beans outside the deployment unit... need to check that).

             

            Code is in the same place...

             

            Specifically... I added a dumbo SallyLogger bean to the "camel-service" quickstarts, which I then invoke in the Camel RouteBuilder class.  That should give you an idea.

            • 3. Re: Tighter CDI + Camel integration
              kcbabo

              Fantastic!  Haven't had a chance to play with it yet (just looked at your example code), but this looks like it's exactly what we were looking for.  Will dig a bit deeper later today.