[
https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-588.
-------------------------------
Resolution: Fixed
> Remove cycle between camel, spi and model
> -----------------------------------------
>
> Key: CAMEL-588
> URL: https://issues.apache.org/activemq/browse/CAMEL-588
> Project: Apache Camel
> Issue Type: Improvement
> Affects Versions: 1.4.0
> Reporter: Christian Schneider
> Assignee: Claus Ibsen
> Fix For: 2.0.0
>
> Attachments: camel_model.patch, post_camel_model_patch.png,
> pre_camel_model_patch.png
>
>
> Currently there is a bad dependency cycle between camel, spi and model.
> camel.CamelContext references model.RouteType. spi.RouteContext references
> model.RouteType and model.FromType. Additionally spi.RouteContext and
> spi.InterceptStrategy reference model.ProcessorType. These references are
> especially bad ones as camel and spi are the most low level packages and
> these references close the loop that makes camel one big tangle. I managed to
> remove this tangle and so lower the excess(xs) measurement in structure 101
> from 4300 to 2400. I added the dependency views to the issue. I hided the
> deprecated CamelTemplate in the views to show that the cycle will be broken
> once we can delete this.
> The first thing I found out is that model is in my opinion not especially
> well named. The model package is not the inner domain model of camel as the
> name suggests but more the java dsl. So I think it could make sense to rename
> it at some point into javadsl or dsl. This change would be too destructive so
> I did not change this. But I think it is reasonable to define that camel and
> spi should not be dependent on the dsl as the dsl is only needed while
> creating the routes. So my goal was to cut these dependencies.
> I first moved spi.RouteContext and spi.InterceptStrategy to model. With
> RouteContext I am quite sure that this is a good thing as it is only needed
> in the Java DSL and the builders. InterceptStrategy is of course part of an
> spi but as it references model it can´t life in spi. As LifecycleStrategy
> references RouteContext I split this interface in the part that does not
> references RouteContext which I just left in spi and a new interface
> ModelLifecycleStrategy which lives in model. This interface has the
> onRouteContextCreate.
> Then I reworked the communication between DefaultCamelContext and
> RouteBuilder. I removed the routedefinitions from DefaultCamelContext and
> mode sure they are not needed anywhere. So only the RouteBuilder knows about
> the definitions and keeps them encapsulated. In the current code the
> intialization of the RouteBuilder and the transfer of Routes and
> RouteDefinitions between Routebuilder and DefaultCamelContext is very
> complicated and intransparent. The getRouteList does the initialization as a
> side effect and additionally feeds the route definitions into the
> CamelContext. This is extremly intransparent. I replaced this with a simple
> and speaking method in Routes. btw I would vote to rename Routes to
> RouteProvider. This would make the responsbility clearer.
> List<Route> configureAndRetrieveRoutes(CamelContext context) throws Exception;
> This method intializes the RouteBuilder, creates the definitions and routes
> and simply returns the List of Routes. This is all communication between
> DefaultCamelContext and RouteBuilder. The only little difference in behaviour
> compared to before is that the Endpoint resolution happens already in this
> step and not when the CamelContext is started.
> All unit tests except one worked out of the box with this change. The one
> that failed was RouteWithMistypeComponentNameTest. I this test the expected
> exception happened now while adding the RouteBuilder to the context not when
> starting the context. This was easily solved by extending the try to include
> the addRoutes call. This is of course a minor change in contract but I
> believe the architectural benefits are worth this little change.
> I also had to do some little tweaks to make the GraphGeneratorSupport work
> again. As CamelContext now does not know the route definitions this
> information has to be taken from BuilderSupport. So made the CamelContext
> know all its RouteBuilders as a list of Routes. In the Graph generation I
> then cast them to BuilderSupport and extract the route defintions. So I was
> able to keep the balance between encapsulation and enough knowledge to draw
> the graphs.
> The last thing I did was to remove the createProcessor method from
> RouteContext. I think this method was quite redundant. I was able to replace
> all occurances of this with the much simpler call.
> RouteType.createOutputProcessor. This removes another part of a cycle.
> I set the version for this issue to 1.4.0 so it does not get lost but feel
> free to move it to the version of camel where you want it solved. As this is
> a big patch I would of course prefer it to be commited as soon as possible.
> If we wait too long I probably have to redo the patch as there will be too
> many changes in camel in the mean time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
