[
https://issues.apache.org/activemq/browse/CAMEL-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42983#action_42983
]
Christian Schneider commented on CAMEL-527:
-------------------------------------------
I have another idea how to solve the cycle. The references from camel to impl
go from CamelTemplate to ServiceSupport. So we could move CamelTemplate to
impl. Perhaps it would be a good idea to also create an interface for
CamelTemplate in camel and a way to retrieve the CamelTemplate without knowing
the concrete implementation. This part would solve the cycle between camel and
impl.
ServiceSupport is also referenced from util.ProducerCache. As util should not
reference impl we should move ProducerCache to impl. As ProducerCache is
currently only referenced from CamelTemplate and the processor package this
should be ok.
What do you think about this change? Is impl a good place for CamelTemplate? I
am not sure about it myself as CamelTemplate is visible to Camel users. If we
create an interface for CamelTemplate I think it should be ok.
> Break dependency cycle between camel and camel.impl
> ---------------------------------------------------
>
> Key: CAMEL-527
> URL: https://issues.apache.org/activemq/browse/CAMEL-527
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Affects Versions: 1.3.0
> Reporter: Christian Schneider
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: servicehelper.patch
>
> Original Estimate: 3 hours
> Remaining Estimate: 3 hours
>
> Currently there is a dependency cycle between camel and camel.impl. While I
> think there is no problem when impl uses camel the other direction should not
> occur. Luckily there ist only one case where this happens. The class
> CamelTemplate from camel uses ServiceSupport from impl.
> As a solution I would suggest to move ServiceSupport and Service to util.
> ServiceHelper is already in util and Service as well as ServiceSupport do not
> need any other classes. This would help to break the dependency cycle and at
> the same time move some classes out of the already quite big camel package.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.