Tuesday 20 January 2009

Apache Camel goes top level!

Apache Camel is now a top level project at Apache - you can find it at http://camel.apache.org/. Yay! 

Many thanks to all the Camel Riders who made this happen!


Ales Justin said...

Any interest in integrating Camel with JBoss Microcontainer (same way as you do Guice or Spring)?

ps: I'm just building the project to have a quick peek at how it's done - the Guice part

James Strachan said...

Sure! Am sure JBoss Microcontainer users who want to use Camel will find it handy.

It should be relatively easy - the default Registry uses the current JNDI context.

if there's some other kind of way of looking up configured endpoints / components / beans in JBoss Microcontainer you might wanna expose that in a custom Registry implementation; that should mostly be it I think

Ales Justin said...

OK, thanks for the info.

I was finally able to build the Camel project (heap space problems), so I'll have a look asap.

Ales Justin said...

I've (locally) added camel-jbossmc to components (and fixed all necessary pom.xml's).
How to get this in? Patch?

My Registry impl is trivial.
Is that really it?

What's the purpose of all the Guice or Spring glue code then?
If you could just point me to some docs, or should I look at the code?

James Strachan said...

Yes please - we love contributions & patches. See the sections on creating and submitting patches.

It might be easier to continue this conversation on the Camel developer forum as I'm sure other camel riders are interested.

In summary - Camel tries to abstract the IoC container so its kinda IoC agnostic; working nicely with Guice or Spring or anything else -e.g. JBossMC.

The main interface for hooking into the IoC container is the Registry which is lazily created by the CamelContext which is then used to lookup components, endpoints, beans by name.

When using Spring, this is the ApplicationContext - otherwise it defaults to JNDI

Ales Justin said...

OK, I'll prepare a patch.

This is the last post here,
I'll move future discussion to the dev forum.

Yeah, there are only 2 Registry impls (OK, now three :-)).
JNDI and Spring's AppContext.

I guess Guice doesn't have one,
since handling Guice's beans by name, is not exactly why Guice was created in the first place.

James Strachan said...

FWIW by default we tend to use GuiceyFruit's JNDI provider when working with Camel; so that its easy to use Guice to IoC components and endpoints and expose them into JNDI so they are easily used by URI or endpoint name in Camel

Ales Justin said...

Now I see the reason behind your Guice ml posts. :-)

Thinking about the patch.
Since I'll be just adding a simple file + modifying a few pom.xml's.

I guess the easiest way would be if the Camel + MC paths already existed.
Then a simple 'svn diff' would do it.

Or how else do you patch newly created paths (directories)?

The path that I added:
+ the normal mvn structure (src/test & src/main/resources - currently not used)

James Strachan said...

Since its all new code and not so much patching existing code, attaching a tarball / zip to a JIRA is probably the easiest thing to do. Remember to tick the 'grant to the ASF as Apache Licensed code' checkbox when adding your attachment