Hi,Christian
I agree with you and I think the builder and model package have a little
inconsistency.
When I implement the groovy route editor today, I found that:
1. In Xml schema editing mode, a RouteDefinition instance will be
constructed to receive the web console content.
2. But in Groovy editing mode, a RouteBuilder instance is used because
through groovy mode, a class can generate a set of RouteDefinition
instances.
RouteDefinition is a concept in model package while RouteBuilder is in
builder, which has a set of RouteDefinition instances in it. So when
executing the update operation, some inconsistent process are brought in.
Christian Schneider wrote:
>
> Hi all,
>
> I have looked into the way Camel routes are built and I think I found an
> inconsistency that gives us a lot of dependency cycles.
> There are two main packages involved: builder and model. I would
> describe their purpose in the following way.
> The builder package contains classes that help building the camel routes
> in Java. It is responsible for providing a fluent Java DSL for writing
> routes and for instantiating the model classes.
> The model package contains classes that form the tree that represents a
> camel route. While the builder package is java dsl specific the model is
> language agnostic.
> I would say that builder needs to reference model as it has the
> responsibility to build the route tree. In the other direction model
> should not reference builder.
>
> All the following I write is based on the asumption that above
> responsibilities are correct so I hope I got it right ;-)
>
> If I understood the Fluent Builder Pattern correctly then a method of a
> builder class should return a builder class.
>
> In camel this seems to be different. The RouteBuilder method from
> returns a RouteDefinition which extends a ProcessorDefinition. To make
> the java dsl work
> the ProcessorDefinition also works like a builder. I think this mixes
> responsibilities and causes many cycles between builder and model.
>
> My proposal is to remove any builder methods from any model classes and
> move them to the builder package. This means that RouteBuilder.from
> should return either a RouteBuilder or a ProcessorBuilder.
> Processorbuilder is already existent but it does not seem to follow the
> builder pattern. I think it should contain all the builder methods that
> are currently in ProcessorDefinition (like to or loadBalance).
> ProcessorDefinition should only help to store the static route tree and
> perhaps help to traverse it and of course it is the base class for all
> ProcessorDefinitions.
>
> There remains one other thing I am not so sure about. Where to create
> for example the Processors? Should this be done in builder or in model
> or somewhere else?
>
> What do you think?
>
> Greetings
>
> Christian
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>
>
--
View this message in context:
http://www.nabble.com/Inconsistency-in-Camel-Java-DSL-tp23908692p23919790.html
Sent from the Camel Development mailing list archive at Nabble.com.
