camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raul Kripalani (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CAMEL-4807) intercept() doesn't store intercepted endpoint in Exchange.INTERCEPTED_ENDPOINT
Date Wed, 04 Jan 2012 18:17:41 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-4807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179716#comment-13179716
] 

Raul Kripalani edited comment on CAMEL-4807 at 1/4/12 6:16 PM:
---------------------------------------------------------------

After investigating this ticket it looks like storing the intercepted endpoint would not align
with the functionality of intercept().

By nature, intercept() intercepts Processors and while there are a number of out-of-the-box
processors which ultimately interact with endpoints (SendProcessor, RecipientListProcessor,
MulticastProcessor, etc.). This isn't a fixed set and indeed keeps on growing as we add functionality
to Camel. Additionally, the end-user may implement custom processors. So all in all, extracting
the endpoint URI(s) from all of them is definitely not the way to go.

My intention was really to provide more richness of runtime routing information to the user,
to enable them to implement dynamic interceptors that may act differently based on where the
exchange is right now.

For example, if custom node IDs have been set along the route, they should be injected in
a message header as part of the interception.
We could also add the shortName or the label of the target processor to enable the user to
react differently if the target processor is an Aggregation, Delay, ThrowException, etc.

If this idea is accepted, I will go ahead and implement it.
                
      was (Author: raulvk):
    After investigating this ticket it looks like storing the intercepted endpoint would not
align with the functionality of intercept().

By nature, intercept() intercepts Processors and while there are a number of out-of-the-box
processors which ultimately interact with endpoints (SendProcessor, RecipientListProcessor,
MulticastProcessor, etc.). This set isn't fix and keeps on increasing as we add functionality
to Camel. Additionally, the end-user may implement custom processors. So all in all, extracting
the endpoint URI(s) from all of them is definitely not the way to go.

My intention was really to provide more richness of runtime routing information to the user,
to enable them to implement dynamic interceptors that may act differently based on where the
exchange is right now.

For example, if custom node IDs have been set along the route, they should be injected in
a message header as part of the interception.
We could also add the shortName or the label of the target processor to enable the user to
react differently if the target processor is an Aggregation, Delay, ThrowException, etc.

If this idea is accepted, I will go ahead and implement it.
                  
> intercept() doesn't store intercepted endpoint in Exchange.INTERCEPTED_ENDPOINT
> -------------------------------------------------------------------------------
>
>                 Key: CAMEL-4807
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4807
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.8.3
>            Reporter: Raul Kripalani
>            Assignee: Raul Kripalani
>            Priority: Minor
>              Labels: interceptors
>
> The intercept() DSL doesn't seem to store the intercepted endpoint (if the original intended
destination at that point is an endpoint) in the Exchange.INTERCEPTED_ENDPOINT property.
> This could be useful if you want to build generic interceptor logic which has the capability
of taking decisions based on if the next processor is a specific endpoint.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message