You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Fintan Bolton (JIRA)" <ji...@apache.org> on 2008/11/20 12:29:10 UTC
[jira] Created: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Add enrich() processor to implement Content Enricher pattern
------------------------------------------------------------
Key: CAMEL-1106
URL: https://issues.apache.org/activemq/browse/CAMEL-1106
Project: Apache Camel
Issue Type: New Feature
Components: camel-core
Affects Versions: 2.0.0
Reporter: Fintan Bolton
Fix For: 2.0.0
Attachments: ContentEnricherExample.zip
Add an enrich() processor with the following overloaded variants:
from(<SourceURI>).enrich(<EnricherURI>)...
from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
Motivation:
-----------
The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
Use Case 1 - Enriching from a flat file:
----------------------------------------
In the original example that Mark worked on, there were two sources of input:
1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
If you chain enrichers as follows:
from(<SourceURI>)
.enrich(<EnricherURI01>, listAggregator)
.enrich(<EnricherURI02>, listAggregator)
...
You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
enrich(<EnricherURI>)
enrich(<EnricherURI>, <Aggregator>)
enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
Where the default value of <CachingFlag> probably ought to be true(?).
Demo
-------
The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Fintan Bolton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fintan Bolton updated CAMEL-1106:
---------------------------------
Attachment: ContentEnricherExample.zip
Updated the demo to include the Apache license in all the source code files.
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Jonathan Anstey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47520#action_47520 ]
Jonathan Anstey commented on CAMEL-1106:
----------------------------------------
Neat demo Fintan!
I can take a look at adding this for you. May not be till next week though :)
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Jonathan Anstey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49369#action_49369 ]
Jonathan Anstey commented on CAMEL-1106:
----------------------------------------
This feature has been added in CAMEL-209 so I'm closing this one.
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Jonathan Anstey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47521#action_47521 ]
Jonathan Anstey commented on CAMEL-1106:
----------------------------------------
Just noticed that you've attached the demo without granting an ASF license. Would you mind re-attaching it with the license?
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Jonathan Anstey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Anstey resolved CAMEL-1106.
------------------------------------
Resolution: Duplicate
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Jonathan Anstey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Anstey reassigned CAMEL-1106:
--------------------------------------
Assignee: Jonathan Anstey
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Jonathan Anstey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47530#action_47530 ]
Jonathan Anstey commented on CAMEL-1106:
----------------------------------------
Thanks Fintan.
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Fintan Bolton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fintan Bolton updated CAMEL-1106:
---------------------------------
Attachment: (was: ContentEnricherExample.zip)
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Jonathan Anstey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47523#action_47523 ]
Jonathan Anstey commented on CAMEL-1106:
----------------------------------------
I should probably also say if any other camel devs want to take a crack at this before I do, you are welcome. I don't mean to be a JIRA hog ;)
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Fintan Bolton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47531#action_47531 ]
Fintan Bolton commented on CAMEL-1106:
--------------------------------------
Gert,
We are probably talking at cross-purposes here. The first argument of enrich() is intended to be a _consumer_ endpoint. So, the example route you gave does not seem to be consistent with that assumption.
But I would be grateful, if you have any ideas on how to improve the caching. The caching in the current demo is fairly simplistic.
Cheers,
Fintan
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1106) Add enrich() processor to implement
Content Enricher pattern
Posted by "Gert Vanthienen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47522#action_47522 ]
Gert Vanthienen commented on CAMEL-1106:
----------------------------------------
Fintan,
Instead of adding the CachingFlag specifically for the content-enricher, wouldn't it be better to make this into a generic service that can be plugged into any route?
It can be useful to have support for caching webservice requests etc. as well.
Something like...
{code:java}
from(<SourceURI>).enrich("direct:enricher", <Aggregator>);
from("direct:enricher").cache(<CacheOptions>).to(<EnricherURI>);
{code}
Gert
> Add enrich() processor to implement Content Enricher pattern
> ------------------------------------------------------------
>
> Key: CAMEL-1106
> URL: https://issues.apache.org/activemq/browse/CAMEL-1106
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.0.0
> Reporter: Fintan Bolton
> Assignee: Jonathan Anstey
> Fix For: 2.0.0
>
> Attachments: ContentEnricherExample.zip
>
>
> Add an enrich() processor with the following overloaded variants:
> from(<SourceURI>).enrich(<EnricherURI>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>)...
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Motivation:
> -----------
> The motivation for this feature comes from a problem that Mark Fynes encountered while trying to integrate an Artix Data Services example with Camel. The Artix DS example had multiple inputs, but it turns out that it is difficult to represent an Artix DS transform with multiple inputs in Camel.
> After thinking about it for a bit, I realized that the problem can be solved using the Content Enricher EIP pattern. Currently, however, writing a Camel content enricher mostly involves rolling your own code. The aim of the 'Content Enricher Pattern' is to generalize the solution of Mark's problem so that you can create a content enricher quickly and easily in the future.
> Use Case 1 - Enriching from a flat file:
> ----------------------------------------
> In the original example that Mark worked on, there were two sources of input:
> 1. A stream of credit card transactions (e.g. containing a Name, Credit Card Number, TransactionAmount, and so on). This input can be represented by the start of a Camel route, e.g. from(<SourceURI>).
> 2. An XML file containing credit ratings for different customers (e.g. a list of associations between Names and credit ratings). This input represents the data that will be fed in through the content enricher processor.
> The two sources of input could be handled by a new 'enrich()' processor, which is specified as follows:
> from(<SourceURI>).enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)...
> Where the <SourceURI> specifies the source of incoming credit card transactions (e.g. from a message queue), <EnricherURI> specifies the flat file containing the credit ratings, <Aggregator> is a Camel aggregator, and <CachingFlag> indicates whether the flat file (from <EnricherURI>) should be read only once (true) or every time a transaction comes in (false).
> For the <Aggregator>, probably the most generally useful implementation would be a ListAggregator that combines the incoming exchange and the enricher exchange into a java.util.List instance. The value list.get(0) would return the exchange from <SourceURI> and list.get(1) would return the exchange from the <EnricherURI>.
> If you chain enrichers as follows:
> from(<SourceURI>)
> .enrich(<EnricherURI01>, listAggregator)
> .enrich(<EnricherURI02>, listAggregator)
> ...
> You would obtain a list with list.get(0) from <SourceURI>, list.get(1) from <EnricherURI01>, and list.get(2) from <EnricherURI02>.
> If you consider ListAggregator to be a good default, you could define the following overloaded variants of enrich:
> enrich(<EnricherURI>)
> enrich(<EnricherURI>, <Aggregator>)
> enrich(<EnricherURI>, <Aggregator>, <CachingFlag>)
> Where the default value of <CachingFlag> probably ought to be true(?).
> Demo
> -------
> The attached ZIP file contains a partial demo of this functionality. To run the demo, unzip the archive and run the command, 'mvn test'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.