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
On 5 September 2011 14:04, Christian Schneider 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 an
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. Thes
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
