On 11/03/2008, Taylor Gautier <[EMAIL PROTECTED]> wrote: > James.Strachan wrote: > > > > Great stuff! :) > > > > We should add a link to this on the Camel wiki > > > > > Will do. I'll go back and see if I can't commit the code - it's pretty > small really. It seems like it would be better for this component to be a > part of the camel package, rather than a separate download.
Sure - so long as the license is fine (which at first look being MPL based looks fine) we can host it at Apache if you like; or it could be hosted at terracotta.org if you prefer; your call really. > On a side note, does this usage make sense? Sure > I don't know Camel or its use > cases well enough to know....for example, if you have an application with a > JMS queue connecting one or more JVMs, how would that application be > configured? So Camel works on endpoints; an endpoint being a specific queue or topic or directory or whatever. The JMS endpoints are typically created by a JmsComponent which has the various JMS configuration such as ConnectionFactory or TransactionManager etc. We tend to use Spring to configure that kinda stuff; though you can also configure endpoints on the URI as well. http://activemq.apache.org/camel/jms.html > I think I have modeled what I have done roughly on this usage, but I'm not > an expert here. I'd love to see someone who has more experience give this a > try in a more real-world setting - I would suspect that it might be possible > for any app that has a JMS queue configured as endpoints between two JVMs > this would work pretty much as a drop in replacement, but again, not really > sure here. Sure - wanna pop the code somewhere and we can take a noodle? One of the main benefits of Camel is it abstracts all the middleware & transport protocols from you; so its pretty trivial to switch from in memory SEDA queues to JMS to databases to Terracotta to JavaSpaces to FIX to file systems, Atom or whatever. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
