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 (JIRA)" <ji...@apache.org> on 2008/06/08 13:01:00 UTC
[jira] Created: (CAMEL-588) Remove cycle between camel, spi and
model
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
Reporter: Christian Schneider
Fix For: 1.4.0
Attachments: 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.
[jira] Commented: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50129#action_50129 ]
Claus Ibsen commented on CAMEL-588:
-----------------------------------
CamelPostProcessorHelper from impl uses component/bean, try to avoid this
> 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.
[jira] Updated: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-588:
------------------------------
Fix Version/s: 1.5.0
2.0.0
(was: 1.4.0)
Affects Version/s: 1.4.0
> 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
> Fix For: 1.5.0, 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.
[jira] Commented: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50126#action_50126 ]
Claus Ibsen commented on CAMEL-588:
-----------------------------------
StreamCache interface should be moved to root package *DONE*
Bean- and MockComponent uses Converter classes directly. *DONE*
> 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.
[jira] Commented: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50124#action_50124 ]
Claus Ibsen commented on CAMEL-588:
-----------------------------------
LoggingLevel enum should be moved to root package and use a LoggingLevelType in model
> 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.
[jira] Issue Comment Edited: (CAMEL-588) Remove cycle between
camel, spi and model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50124#action_50124 ]
davsclaus edited comment on CAMEL-588 at 3/1/09 10:39 PM:
------------------------------------------------------------
LoggingLevel enum should be moved to root package *DONE*
was (Author: davsclaus):
LoggingLevel enum should be moved to root package and use a LoggingLevelType in model
> 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.
[jira] Updated: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider updated CAMEL-588:
--------------------------------------
Attachment: pre_camel_model_patch.png
> 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
> Reporter: Christian Schneider
> Fix For: 1.4.0
>
> Attachments: 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.
[jira] Commented: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50119#action_50119 ]
Claus Ibsen commented on CAMEL-588:
-----------------------------------
ExpressionAdapater should be moved from impl to util or a support package
> 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.
[jira] Resolved: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-588:
------------------------------
Fix Version/s: (was: 1.5.0)
> 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
> 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.
[jira] Assigned: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-588:
---------------------------------
Assignee: Claus Ibsen
> 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.
[jira] Updated: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider updated CAMEL-588:
--------------------------------------
Attachment: camel_model.patch
> 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
> Reporter: Christian Schneider
> Fix For: 1.4.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.
[jira] Commented: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50123#action_50123 ]
Claus Ibsen commented on CAMEL-588:
-----------------------------------
Bean component uses model *DONE*
> 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.
[jira] Commented: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50160#action_50160 ]
Claus Ibsen commented on CAMEL-588:
-----------------------------------
I will close this one now as we got most fixed and have a much better package structure now.
The bean component is becoming a central piece in Camel and I am wondering if we should move parts of it into the spi/camel/impl and let the bean component be a endpoint factory facade as most others are.
> 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.
[jira] Updated: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider updated CAMEL-588:
--------------------------------------
Attachment: post_camel_model_patch.png
> 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
> Reporter: Christian Schneider
> Fix For: 1.4.0
>
> Attachments: 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.
[jira] Issue Comment Edited: (CAMEL-588) Remove cycle between
camel, spi and model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50120#action_50120 ]
davsclaus edited comment on CAMEL-588 at 3/1/09 9:54 PM:
-----------------------------------------------------------
DataFormatType should not implement DataFormat *DONE*
was (Author: davsclaus):
DataFormatType should not implement DataFormat
> 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.
[jira] Commented: (CAMEL-588) Remove cycle between camel, spi and
model
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50120#action_50120 ]
Claus Ibsen commented on CAMEL-588:
-----------------------------------
DataFormatType should not implement DataFormat
> 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.