Thx. I will pick up the code from your svn server and test it. One question : According to this architecture (Camel + Terracotta), the clustering/loadbalacing functionality is not provided by a ESB like ServiceMix or Mule or using a cluster of JMS queues but by Terracotta. So, conceptually speaking, Terracotta could play the role of an ESB except that functionalities used to create/plug endpoints, services, ... are not part of Terracotta package.
So, what do you think about the idea to embed Terracotta into a ESB product (Mule, ServiceMix, ...) in order to provide such functionalities by default ? Terracotta could be part of the kernel engine of the ESB ? Regards, Charles Taylor Gautier wrote: > > I haven't yet integrated the camel code into Camel proper. It currently > lives on the Terracotta Forge site. > > You can check it out using: > > svn co http://svn.terracotta.org/svn/forge/projects/labs/tim-camel > > Read the README.txt to run the sample. > > > cmoulliard wrote: >> >> Hi, >> >> Can you tell me if the integration of Terracotta with Camel has been >> finally integrated into the Camel project ? If this is the case, where >> this code is located (in the source directory of Camel-core / >> Camel-component) ? >> >> Regards >> >> Charles Moulliard >> Senior Enterprise Architect >> Xpectis - www.xpectis.com >> >> >> >> Taylor Gautier wrote: >>> >>> >>> James.Strachan wrote: >>>> >>>> On 11/03/2008, Taylor Gautier <[EMAIL PROTECTED]> wrote: >>>>> James.Strachan wrote: >>>>> >>>>> 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. >>>> >>> >>> Oh, I was thinking to donate it with an Apache license. Just have to >>> get the OK on that, worst case we have it on TC site with TC license, >>> but it seems better to be in Camel proper. >>> >>> >>> James.Strachan wrote: >>>> >>>>> 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 >>>> >>>> >>> >>> Ok, sounds like I did the right thing. >>> >>> >>> James.Strachan wrote: >>>> >>>>> 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? >>>> >>> >>> It's already there - in my original message I posted a working sample >>> that should take about 1 minute to run - it all builds and compiles and >>> downloads via maven, so the checkout is next to nothing. >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-tp15941549s22882p16823741.html Sent from the Camel - Users mailing list archive at Nabble.com.
