[
https://issues.apache.org/activemq/browse/CAMEL-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42861#action_42861
]
Christian Schneider commented on CAMEL-264:
-------------------------------------------
When I look into the current Interceptor implementation I think the two main
methods that need to be in the interface are process and proceed. Process can
be inherited from Processor but proceed is only declared in the implementation
class DelegateProcessor. So I tihnk the clean way to handle this would be to
create an interface DelegateProcessor.
public interface DelegateProcessor extends Processor {
/**
* Proceed with the underlying delegated processor
*/
public abstract void proceed(Exchange exchange) throws Exception;
}
and an interface Interceptor
public interface Interceptor extends DelegateProcessor {
public abstract void process(Exchange exchange) throws Exception;
public abstract Processor getInterceptorLogic();
public abstract void setInterceptorLogic(Processor interceptorLogic);
}
When we put these to spi and use them instead of the implementations where
possible the spi would not depend on processor anymore. As this is no trivial
change I think this should be handled in a separate Jira issue. Should I open
one?
> The spi package should not depend on implementation packages
> ------------------------------------------------------------
>
> Key: CAMEL-264
> URL: https://issues.apache.org/activemq/browse/CAMEL-264
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Christian Schneider
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: camel_routecontext.patch, Main cluster (12).png, new
> Main cluster (12).png, screenshot-1.jpg
>
>
> Currently spi.LifecycleStrategy depends on impl.RouteContext.
> This is bad because the spi is an interface package that should have no
> dependencies on implementation packages.
> The solution is to rename RouteContext to RouteContextImpl, extract an
> interface class RouteContext from the implementation and put this interface
> into spi. So spi is self contained.
> The other problem is that spi.InstrumentationAgent depends on
> management.CamelNamingStrategy. In this case I would suggest to simply remove
> the method getNamingStrategy from the IntrumentationAgent. Instead I add the
> naming strategy param to the constructor of InstrumentationLifecycleStrategy.
> So the dependency disappears. Of course this way the naming strategy is no
> longer part of the spi but I think it is an internal thing anyway. What do
> you think?
> I will attach a patch for the issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
