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. http://camel.apache.org/registry.html
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
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
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
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: C:\projects\camel\components\camel-jbossmc\src\main\java\org\apache\camel\jbossmc\registry\ControllerRegistry.java + the normal mvn structure (src/test & src/main/resources - currently not used)
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
9 comments:
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
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.
http://camel.apache.org/registry.html
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
OK, thanks for the info.
I was finally able to build the Camel project (heap space problems), so I'll have a look asap.
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?
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
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.
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
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:
C:\projects\camel\components\camel-jbossmc\src\main\java\org\apache\camel\jbossmc\registry\ControllerRegistry.java
+ the normal mvn structure (src/test & src/main/resources - currently not used)
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
Post a Comment