Hi Just to be clear when I wear the "watchdog of the community hat".
The API in Camel 2.x should be kept to a minimum changes. For example we cannot move DefaultEndpoint, DefaultExchange etc. They should stay to ensure 100% backwards compatibility and not cause more trouble in the community. These classes is central for people creating custom components. The community expect Camel 2.x API to be stable. On Mon, Sep 5, 2011 at 3:04 PM, 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. > > Christian > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
