You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Christian Schneider <ch...@die-schneider.net> on 2011/09/05 15:04:10 UTC
[Discuss] How to create Exchanges?
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
Re: [Discuss] How to create Exchanges?
Posted by Claus Ibsen <cl...@gmail.com>.
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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [Discuss] How to create Exchanges?
Posted by Christian Schneider <ch...@die-schneider.net>.
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
Re: [Discuss] How to create Exchanges?
Posted by James Strachan <ja...@fusesource.com>.
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: james@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging