On 5 September 2011 14:04, Christian Schneider <ch...@die-schneider.net> wrote: > Hi all, > > I am currently trying to minimize the use of impl classes in components and > check how to completely hide impl classes for 3.0. > > So I will have to move several classes from impl to support as they are used > as base classes anyway (e.g. DefaultEndpoint). A special case is > DefaultExchange. It is not a base class, in fact it is the only > implementation of Exchange. > So the big question is how do we want to handle exchange creation. There are > two main solutions I can think of: > > - Hide the implementation and offer factory methods on camelContext > - Move the implementation to support and so allow new DefaultExchange from > any class > > We also have factory methods for Exchange on Endpoint and DefaultEndpoint. > The question is do we need these? DefaultEndpoint would not be able to hide > the impl of DefaultExchange as it has to reside in support and is a base > class. So if we want to hide DefaultExchange the factory impl must be in a > real 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. -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration and Messaging
