Am 05.09.2011 16:12, schrieb James Strachan:
al impl class like DefaultCamelContext. An Endpoint maybe be able to create a more optimal Exchange object since it knows the ultimate destination of the Exchange; e.g. to avoid double-creation of header structures - such as creating a JMS Message to store properties directly rather than creating a Map which later on gets copied to a JMS message etc. So its a handy optimisation hook for sure. Plus an endpoint typically knows the default ExchangePattern value for an Exchange; so I'd suggest keeping it. Being able to just use DefaultExchange directly in code seems fine to me. A factory method on CamelContext would be OK too I guess; though personally I tend to use either the Endpoint or ProducerTemplate as the factory of Exchanges. If I'm sending exchanges from outside of a particular endpoint I use ProducerTemplate - within an Endpoint implementation I use the factory method on Endpoint. So not 100% sure if a factory method on CamelContext has that much value really.
Yes for components the factory methods in the endpoint have some value. So I also think it would be good to keep them. For the other cases I even tend to prefer that people simply use new DefaultExchange. If we only ever have one Exchange impl then it does not hurt much to use this impl
directly. Christian -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
