Re: starting, stopping, creating & editing routes at runtime now works - CAMEL-1004
On Wed, Feb 25, 2009 at 7:29 PM, James Strachan wrote: > Here's a test case to show the kind of thing we can now do... > http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/impl/StartAndStopRoutesTest.java > > there's now a start/stop route method on CamelContext where you can > start or stop individual routes using the route definition (which lets > you also mutate routes). Routes with the same ID replace old ones, > otherwise its a new route. So you could get a route definition, clear > the ID and start it to clone a route. > > So far it looks like most of the tests still pass. Do folks think the > API seems OK to them? I've tried to hide as much of the internal > details as possible - so the API is primarily dealing with the route > definitions (RouteType classes) Looks great. We can always ponder with the API later. Maybe from a maintenance point of view you would like to be able to stop routes based on the id alone, so you from a web console can stop / start routes and submit the id from the web form. I assume each route has a unique id that can be used for higher level manipulation from scripts (yeah there is a id on the route type and route service as well)? So you can eg. submit a route to be replace an existing route from a script and pass in the route id? And a feature I would love in the future was to be able to pause individual consumers. eg. pause a file consumer temporary to pile up files and you can tamper with the routes, or you were told to pause it since some back end system is not available. So you can say that if you could pause routes then that would be lovely as it can be used as well. However we do have support for routes with multiple inputs (eg multiple from -> same route) so if you pause the route you pause them all, but I guess that could make sense. > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Data-driven routing
I have tried that approach. It was pretty intuitive and made sense. The
problem came when I had two routes from the same source (e.g., a log), one
portion of which I wanted to route to one topic, the other part going to
another topic. It appeared that, using the DSL with two routes, one message
would go to one route (and get resolved properly), then the next would go to
the next route (and not get resolved properly).
So, graphically:
Source 1 --> Xpath 1 --> Process A --> Sink 1
Source 1 --> Xpath 2 --> Process A --> Sink 2
It seemed that message 1 hit the first route and ended up in the right
place. Message 2, which should have been resolved by the first route, went
to the second route and did not proceed (no match on the xpath filter). My
conclusion, drawn without getting Trace to work, was that I needed a
recipientlist, so that each message was presented to each route). That I
could not do with DSL, as each "recipient" would be a pipeline, not a simple
endpoint, and would require assembly within the result list loop.
I am probably missing something. At any rate I do not yet have a scenario
that works.
Thanks for your help,
Jim Bower
James.Strachan wrote:
>
> 2009/2/25 jbower1950 :
>>
>> After working through Camel-Spring-ActiveMQ configuration and a DSL
>> approach
>> I am still struggling with the pieces necessary to achieve dynamic,
>> data-driven routing for JMS as follows.
>>
>> Each "source" (ActiveMQ topic or queue) may have 0-n routes, each defined
>> below:
>>
>> 1. Optional xpath expression for filtering
>> 2. Optional processes
>> 3. forwarding of the message to a destination (a different queue or
>> topic)
>>
>> The recipientlist pattern is appropriate. However, it does not seem
>> possible
>> to use the DSL to assemble the route in pieces, as each recipient must be
>> a
>> pipeline of [xpath filter] [0-n processes] and an endpoint. The pieces
>> are
>> contained in a JPA result set, so I cannot piece the route together with
>> DSL
>> (have to loop to get the syntax.
>>
>> I have tried a processor with a producer template, but it does not seem
>> to
>> be reliable.
>>
>> Any hints?
>
> If I understand what you're saying - you're doing a JPA query to find
> all the xpath expressions and processes to execute and you want to
> create a route for each combination right?
>
> So something like this...
>
> public class MyRouteBuilder {
> // inject JPA resources and whatever else you need with IoC
>
> public void configure() {
> List foos = ... // some query
> for (Foo foo : foos) {
> String u = foo.getFromEndpointUri();
> String xp = foo.getXPath();
> Class type = foo.getBeanType(); // or processor type
>
> // lets add a route from the uri and filter to the given
> processor
> from(u).filter().xpath(xp).bean(type);
> }
> }
>
> i.e. you can use the Java DSL within any regular Java code (loops,
> conditional branches and whatnot) plus you can dependency inject your
> RouteBuilder with whatever resources it needs (like JPA stuff)
>
> --
> James
> ---
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
>
--
View this message in context:
http://www.nabble.com/Re%3A-Data-driven-routing-tp22214166p22216427.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Data-driven routing
2009/2/25 jbower1950 :
>
> After working through Camel-Spring-ActiveMQ configuration and a DSL approach
> I am still struggling with the pieces necessary to achieve dynamic,
> data-driven routing for JMS as follows.
>
> Each "source" (ActiveMQ topic or queue) may have 0-n routes, each defined
> below:
>
> 1. Optional xpath expression for filtering
> 2. Optional processes
> 3. forwarding of the message to a destination (a different queue or topic)
>
> The recipientlist pattern is appropriate. However, it does not seem possible
> to use the DSL to assemble the route in pieces, as each recipient must be a
> pipeline of [xpath filter] [0-n processes] and an endpoint. The pieces are
> contained in a JPA result set, so I cannot piece the route together with DSL
> (have to loop to get the syntax.
>
> I have tried a processor with a producer template, but it does not seem to
> be reliable.
>
> Any hints?
If I understand what you're saying - you're doing a JPA query to find
all the xpath expressions and processes to execute and you want to
create a route for each combination right?
So something like this...
public class MyRouteBuilder {
// inject JPA resources and whatever else you need with IoC
public void configure() {
List foos = ... // some query
for (Foo foo : foos) {
String u = foo.getFromEndpointUri();
String xp = foo.getXPath();
Class type = foo.getBeanType(); // or processor type
// lets add a route from the uri and filter to the given
processor
from(u).filter().xpath(xp).bean(type);
}
}
i.e. you can use the Java DSL within any regular Java code (loops,
conditional branches and whatnot) plus you can dependency inject your
RouteBuilder with whatever resources it needs (like JPA stuff)
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Data-driven routing
After working through Camel-Spring-ActiveMQ configuration and a DSL approach I am still struggling with the pieces necessary to achieve dynamic, data-driven routing for JMS as follows. Each "source" (ActiveMQ topic or queue) may have 0-n routes, each defined below: 1. Optional xpath expression for filtering 2. Optional processes 3. forwarding of the message to a destination (a different queue or topic) The recipientlist pattern is appropriate. However, it does not seem possible to use the DSL to assemble the route in pieces, as each recipient must be a pipeline of [xpath filter] [0-n processes] and an endpoint. The pieces are contained in a JPA result set, so I cannot piece the route together with DSL (have to loop to get the syntax. I have tried a processor with a producer template, but it does not seem to be reliable. Any hints? Thanks, Jim -- View this message in context: http://www.nabble.com/Data-driven-routing-tp22209256p22209256.html Sent from the Camel - Development (activemq) mailing list archive at Nabble.com.
[jira] Resolved: (CAMEL-1004) make it easy to start/stop routes by their definition (RouteBuilder or Route class)
[ https://issues.apache.org/activemq/browse/CAMEL-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Strachan resolved CAMEL-1004. --- Resolution: Fixed Fix Version/s: (was: 2.1.0) 2.0.0 see the test case http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/impl/StartAndStopRoutesTest.java for how we can start/stop routes based on their definition > make it easy to start/stop routes by their definition (RouteBuilder or Route > class) > --- > > Key: CAMEL-1004 > URL: https://issues.apache.org/activemq/browse/CAMEL-1004 > Project: Apache Camel > Issue Type: New Feature >Reporter: James Strachan >Assignee: James Strachan > Fix For: 2.0.0 > > > There should be some way to stop a Route from either the XML (e.g. by > routeID) or from a RouteBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
starting, stopping, creating & editing routes at runtime now works - CAMEL-1004
Here's a test case to show the kind of thing we can now do... http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/impl/StartAndStopRoutesTest.java there's now a start/stop route method on CamelContext where you can start or stop individual routes using the route definition (which lets you also mutate routes). Routes with the same ID replace old ones, otherwise its a new route. So you could get a route definition, clear the ID and start it to clone a route. So far it looks like most of the tests still pass. Do folks think the API seems OK to them? I've tried to hide as much of the internal details as possible - so the API is primarily dealing with the route definitions (RouteType classes) -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
[jira] Resolved: (CAMEL-1377) create a war maven archetype which lets folks spin up a new project which comes with the camel-web application and REST API - but lets folks include whatever dependencies
[ https://issues.apache.org/activemq/browse/CAMEL-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-1377. Resolution: Fixed > create a war maven archetype which lets folks spin up a new project which > comes with the camel-web application and REST API - but lets folks include > whatever dependencies they want > > > Key: CAMEL-1377 > URL: https://issues.apache.org/activemq/browse/CAMEL-1377 > Project: Apache Camel > Issue Type: Improvement >Reporter: James Strachan >Assignee: Jonathan Anstey > Fix For: 2.0.0 > > > e.g. see this project as a useful base > https://svn.apache.org/repos/asf/camel/trunk/components/camel-activemq-web/ > which just depends on camel-web so it gets all the good stuff from the [Camel > Web Console|http://camel.apache.org/web-console.html] but adds some new > dependencies (components) and a different spring XML. > We should wrap up this behaviour so folks can do the same to create their own > custom camel web apps -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1384) ExchangeHelper should respect ExchangePattern.InOptionalOut
ExchangeHelper should respect ExchangePattern.InOptionalOut
Key: CAMEL-1384
URL: https://issues.apache.org/activemq/browse/CAMEL-1384
Project: Apache Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 1.6.0
Environment: ActiveMQ/Camel
Reporter: Michael Chen
The utility method org.apache.camel.util.ExchangeHelper.copyResults() is use by
many core classes. However, this method does not properly support MEP
InOptionalOut.
Assuming in an InOptionalOut exchange, having no out message means just that --
no out message should be sent, then the following lines in this method
{code}//
Message out = source.getOut(false);
if (out != null) {
result.getOut(true).copyFrom(out);
} else {
// no results so lets copy the last input
{code}
should be changed to:
{code}//
Message out = source.getOut(false);
if (out != null) {
result.getOut(true).copyFrom(out);
} else if (result.getPattern() == ExchangePattern.InOptionalOut) {
result.setOut(null);
} else {
// no results so lets copy the last input
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1366) EndpointMessageListener should respect ExchangePattern
[
https://issues.apache.org/activemq/browse/CAMEL-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49993#action_49993
]
Michael Chen commented on CAMEL-1366:
-
exchange.isOutCapable() is always true downstream due to the logic in method
EndpointMessageListener.createExchange(). That method forces the MEP to be
InOut if JMSReplyTo is present in the original request.
If your reason for forcing a reply is to honor the JMS spec, I can't argue
otherwise. Please close this bug.
However, I believe the camel.component.jms implementation should offer the
option of not replying the original request and give that job to other
components or processors downstream. This does not break the JMS spec, but
just a matter of which Camel component is replying.
> EndpointMessageListener should respect ExchangePattern
> --
>
> Key: CAMEL-1366
> URL: https://issues.apache.org/activemq/browse/CAMEL-1366
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 1.6.0
> Environment: ActiveMQ/Camel
>Reporter: Michael Chen
>
> In all current releases,
> org.apache.camel.component.jms.EndpointMessageListener.onMessage() has the
> following logic (line 90 in 1.6.0 code):
> {code}
> // send the reply
> if (rce == null && body != null && !disableReplyTo) {
> sendReply(replyDestination, message, exchange, body);
> }
> {code}
> This logic should also respect ExchangePattern of the exchange, so I propose
> a change to:
> {code}
> // send the reply
> if (rce == null && body != null && exchange.isOutCapable()) {
> sendReply(replyDestination, message, exchange, body);
> }
> {code}
> This change allows a processing pattern where the route may change the
> ExchangePattern using methods like RouteBuilder.inOnly() to switch the MEP at
> will so that the reply is send at a later time (true asynchronous exchange).
> This processing pattern is particularly useful for integrating long running
> services. For example,
> {code}
> // Java DSL
> from("activemq:my_queue?exchangePattern=InOnly").to("predict_weather://?reply_later=true");
> // or
> from("activemq:my_queue2").inOnly().to("predict_weather://?reply_later=true");
> {code}
> The flaw of the current logic makes it impossible to do true asynchronous
> exchange, because 1) it does not respect the ExchangePattern; 2) if property
> "disableReplyTo" is used, the "org.apache.camel.jms.replyDestination"
> property will not be set (see method createExchange in the same file), thus
> downstream cannot find the reply destination.
> The proposed change can also deprecate the disableReplyTo property and put
> the MEP concept into good use.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Discussion of scope for next Apache Camel 1.x release
+1 On Wed, Feb 25, 2009 at 9:08 AM, Hadrian Zbarcea wrote: > +1 > > I created a 2.0-M1 version in jira. Let's assign the issues we want to > close down in the M1 release and I will cut the release. > > > > On Feb 24, 2009, at 8:08 AM, James Strachan wrote: > >> Agreed - lets get 2.0 out ASAP - while releasing bug fixes in 1.6.1. >> Not sure if we'll ever need a 1.7? >> >> 2009/2/24 Jon Anstey : >>> >>> +1 on fully compatible 1.6.1 >>> >>> We're getting closer to 2.0 being complete anyways so it makes sense to >>> add >>> new features on one branch only. >>> >>> On Tue, Feb 24, 2009 at 4:52 AM, Claus Ibsen >>> wrote: >>> Hi I was wondering if we should start a discussion on the scope for the next Apache Camel 1.x release (notice 1.x branch) As we have always done minor versions and no patch releases I was wondering if we should focus on doing a - 1.6.1 patch release so end users have a stable release that should be drop in compatible - or a new 1.7.0 release I am in favor of focusing on a 1.6.1 release. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ >>> >>> >>> >>> -- >>> Cheers, >>> Jon >>> >>> http://janstey.blogspot.com/ >>> >> >> >> >> -- >> James >> --- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ > >
[jira] Work started: (CAMEL-1004) make it easy to start/stop routes by their definition (RouteBuilder or Route class)
[ https://issues.apache.org/activemq/browse/CAMEL-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-1004 started by James Strachan. > make it easy to start/stop routes by their definition (RouteBuilder or Route > class) > --- > > Key: CAMEL-1004 > URL: https://issues.apache.org/activemq/browse/CAMEL-1004 > Project: Apache Camel > Issue Type: New Feature >Reporter: James Strachan >Assignee: James Strachan > Fix For: 2.1.0 > > > There should be some way to stop a Route from either the XML (e.g. by > routeID) or from a RouteBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49990#action_49990
]
Willem Jiang commented on CAMEL-1364:
-
@ Charles
Did you just changed the dateformat's package name, like below ?
BindyKeyValuePairDataFormat camelDataFormat = new
BindyKeyValuePairDataFormat("org.apache.camel.dataformat.bindy.model.fix.simple");
If so , I will commit the code with that change, since I also fixed some check
style error in my workspace.
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
> Attachments: camel-bindy.txt
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1383) provide a text search - or a way to search by some expression for messages on an endpoint
[ https://issues.apache.org/activemq/browse/CAMEL-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49988#action_49988 ] James Strachan commented on CAMEL-1383: --- we could support a RAM only lucene based search too... http://javatechniques.com/blog/lucene-in-memory-text-search-example/ > provide a text search - or a way to search by some expression for messages on > an endpoint > - > > Key: CAMEL-1383 > URL: https://issues.apache.org/activemq/browse/CAMEL-1383 > Project: Apache Camel > Issue Type: Sub-task > Components: camel-web >Reporter: James Strachan > Fix For: 2.0.0 > > > using a text search to find a message (using headers/body) or using xpath/EL > or whatever -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CAMEL-1356) TryProcessor sets "caught.exception" header to in message, while there can be out already
[
https://issues.apache.org/activemq/browse/CAMEL-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kalukiewicz closed CAMEL-1356.
Resolution: Fixed
Fix Version/s: (was: 1.6.1)
Used exchange property to store the exception. Property name is
Exchange.EXCEPTION_CAUGHT constant.
Committed only to 2.0.0 as it completely changes the behavior of exception
handling. If someone had code depending on "caught.exception" header it will
break.
> TryProcessor sets "caught.exception" header to in message, while there can be
> out already
> -
>
> Key: CAMEL-1356
> URL: https://issues.apache.org/activemq/browse/CAMEL-1356
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 1.6.0
>Reporter: Roman Kalukiewicz
>Assignee: Roman Kalukiewicz
> Fix For: 2.0.0
>
>
> Error exists in
> {{org.apache.camel.processor.TryProcessor.handleException(Exchange,
> Throwable)}}. If your exchange has already out message (that can happen if
> you set out and then throw an exception. Then the exception caught is set on
> in message. When it reaches a pipeline it will be lost after first hop.
> I believe {{TryProcessor}} should do what Pipelient does - copy *out* to *in*
> in new exchange if out exists.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1383) provide a text search - or a way to search by some expression for messages on an endpoint
provide a text search - or a way to search by some expression for messages on an endpoint - Key: CAMEL-1383 URL: https://issues.apache.org/activemq/browse/CAMEL-1383 Project: Apache Camel Issue Type: Sub-task Components: camel-web Reporter: James Strachan Fix For: 2.0.0 using a text search to find a message (using headers/body) or using xpath/EL or whatever -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1004) make it easy to start/stop routes by their definition (RouteBuilder or Route class)
[ https://issues.apache.org/activemq/browse/CAMEL-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Strachan reassigned CAMEL-1004: - Assignee: James Strachan > make it easy to start/stop routes by their definition (RouteBuilder or Route > class) > --- > > Key: CAMEL-1004 > URL: https://issues.apache.org/activemq/browse/CAMEL-1004 > Project: Apache Camel > Issue Type: New Feature >Reporter: James Strachan >Assignee: James Strachan > Fix For: 2.1.0 > > > There should be some way to stop a Route from either the XML (e.g. by > routeID) or from a RouteBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1373) Use CamelCase for Header keys instead of package name prefixes
[ https://issues.apache.org/activemq/browse/CAMEL-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-1373: --- Fix Version/s: (was: 2.0.0) 2.0-M1 > Use CamelCase for Header keys instead of package name prefixes > -- > > Key: CAMEL-1373 > URL: https://issues.apache.org/activemq/browse/CAMEL-1373 > Project: Apache Camel > Issue Type: Task > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.0-M1 > > > We have agreed as part of the 2.0 API rework to use CamelCase header keys. > Currently keys using dots violates the JMS spec and other protocols might > have problems with them as well. > And Camel should of course use CamelCase :) > And they are also easier to read, and less words to type. > There is a discussion on the dev forum about it - title "Camel 2.0 - Keys for > header problem" > Cant like using Nabble as they havent changed to TLP domain -- 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-1373) Use CamelCase for Header keys instead of package name prefixes
[ https://issues.apache.org/activemq/browse/CAMEL-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49979#action_49979 ] davsclaus edited comment on CAMEL-1373 at 2/25/09 7:04 AM: - camel-spring *DONE* camel-jms *DONE* came-http *DONE* camel-jetty *DONE* was (Author: davsclaus): camel-spring *DONE* camel-jms *DONE* > Use CamelCase for Header keys instead of package name prefixes > -- > > Key: CAMEL-1373 > URL: https://issues.apache.org/activemq/browse/CAMEL-1373 > Project: Apache Camel > Issue Type: Task > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.0-M1 > > > We have agreed as part of the 2.0 API rework to use CamelCase header keys. > Currently keys using dots violates the JMS spec and other protocols might > have problems with them as well. > And Camel should of course use CamelCase :) > And they are also easier to read, and less words to type. > There is a discussion on the dev forum about it - title "Camel 2.0 - Keys for > header problem" > Cant like using Nabble as they havent changed to TLP domain -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard updated CAMEL-1364:
-
Attachment: camel-bindy.txt
@Willem,
Here is a new one. I hope it will be complete.
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
> Attachments: camel-bindy.txt
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard updated CAMEL-1364:
-
Attachment: (was: camel-bindy-keyvaluepair.patch)
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard updated CAMEL-1364:
-
Attachment: (was: camel-bindy-fixsimple.txt)
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Camel 2.0 - Keys for header problem
Hi I am working on this now, to change it to CamelCase. I am adding xxxConstants classes to the component where we can put the constants for the key names. This allows end users to easy spot which keys we have. I decided for xxxConstants over Constants when end users work with multiple components and want to import Constants then there is a ambiguity. Hence the component prefix, eg. JmsConstants, HttpConstants And in the future we could merge them into a org.apache.camel.Constants or org.apache.camel.Keys class. In the core the keys are stored on the Exchange that William started with. We can later decide if we want a Constants class as well, or whatever. The values for the keys will be changed to use the new CamelCase syntax. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Discussion of scope for next Apache Camel 1.x release
+1 I created a 2.0-M1 version in jira. Let's assign the issues we want to close down in the M1 release and I will cut the release. On Feb 24, 2009, at 8:08 AM, James Strachan wrote: Agreed - lets get 2.0 out ASAP - while releasing bug fixes in 1.6.1. Not sure if we'll ever need a 1.7? 2009/2/24 Jon Anstey : +1 on fully compatible 1.6.1 We're getting closer to 2.0 being complete anyways so it makes sense to add new features on one branch only. On Tue, Feb 24, 2009 at 4:52 AM, Claus Ibsen wrote: Hi I was wondering if we should start a discussion on the scope for the next Apache Camel 1.x release (notice 1.x branch) As we have always done minor versions and no patch releases I was wondering if we should focus on doing a - 1.6.1 patch release so end users have a stable release that should be drop in compatible - or a new 1.7.0 release I am in favor of focusing on a 1.6.1 release. Any thoughts? -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Cheers, Jon http://janstey.blogspot.com/ -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
[jira] Updated: (CAMEL-963) need to tune JMS <-> JMS routes so that they perform at a more similar performance to using native JMS
[ https://issues.apache.org/activemq/browse/CAMEL-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-963: -- Attachment: perftest.zip Haven't looked at this in a while now and am working on other things at the moment. I'm attaching the test code I was using to compare raw/Camel JMS performance so I won't lose it. > need to tune JMS <-> JMS routes so that they perform at a more similar > performance to using native JMS > -- > > Key: CAMEL-963 > URL: https://issues.apache.org/activemq/browse/CAMEL-963 > Project: Apache Camel > Issue Type: Task >Reporter: James Strachan >Assignee: Jonathan Anstey > Fix For: 2.0.0 > > Attachments: perftest.zip > > > right now we are making way too many copies of an Exchange within a route - > partly due to the generics issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49980#action_49980
]
Willem Jiang commented on CAMEL-1364:
-
@ Charles
I think you still don't put all the files into the patch.
BindySimpleKeyValuePairTabMarshallTest and
BindySimpleKeyValuePairTabUnmarshallTest are failed in my work space.
I checked the code and think you may miss the directory of
org/apache/camel/dataformat/bindy/model/fix/tab
and the src/test/data/fix_tab
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
> Attachments: camel-bindy-fixsimple.txt, camel-bindy-keyvaluepair.patch
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Where exception handling should set a handled exception?
Hi Roman
Could you add a route example to that.
AFAIR this is *only* with the try .. handle DSLs ?
I can enlighten that on the DeadLetterChannel we store previoysly
occured exception as a property when we do redelivery.
There is a constant KEY for it on the Exchange (Camel 2.0)
String EXCEPTION_CAUGHT = "CamelExceptionCaught";
On Wed, Feb 25, 2009 at 12:10 PM, Roman Kalukiewicz
wrote:
> Hello!
>
> Recently I created an issue (CAMEL-1356) about exception handling and
> now I'm not really sure if it is really a bug or not. So I'm asking
> for your opinions.
>
> The problem is that when exception is caught it is set as a
> 'caught.exception' header on IN message. It means that if an exception
> is thrown on an exchange that already has OUT message it will be lost
> after the first step of a pipeline.
>
> We have few possible solutions here:
> 1) Keep it as it is - then we know where to look for this header in
> the first step of the pipeline - we can also use bean integration and
> @Header annotation to retrieve it)
> 2) Put the exception to header on OUT message if it is present - then
> it will be preserved in the pipeline. But then first step of the
> pipeline has to be clever - it has to look for it in OUT message.
> Moreover it is more general problem - if we allow OUT messages there,
> then you cannot use for example setHeader("foo") (you can, but it is
> useless, as out is propagated anyway)
> 3) Put it into exchange property - maybe the best solution as it is
> propagated, and we always know where to look for the exception. It
> will not be lost at some endpoint also.
>
> I believe this change should by put to 2.0 only as it might break
> someones exception handling completely, shouldn't it?
>
> This time I don't want to start flame about need for in/out messages
> once again, but... ;)
>
> Roman
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
[jira] Commented: (CAMEL-1373) Use CamelCase for Header keys instead of package name prefixes
[ https://issues.apache.org/activemq/browse/CAMEL-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49979#action_49979 ] Claus Ibsen commented on CAMEL-1373: camel-spring *DONE* camel-jms *DONE* > Use CamelCase for Header keys instead of package name prefixes > -- > > Key: CAMEL-1373 > URL: https://issues.apache.org/activemq/browse/CAMEL-1373 > Project: Apache Camel > Issue Type: Task > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.0.0 > > > We have agreed as part of the 2.0 API rework to use CamelCase header keys. > Currently keys using dots violates the JMS spec and other protocols might > have problems with them as well. > And Camel should of course use CamelCase :) > And they are also easier to read, and less words to type. > There is a discussion on the dev forum about it - title "Camel 2.0 - Keys for > header problem" > Cant like using Nabble as they havent changed to TLP domain -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (CAMEL-1373) Use CamelCase for Header keys instead of package name prefixes
[ https://issues.apache.org/activemq/browse/CAMEL-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-1373 started by Claus Ibsen. > Use CamelCase for Header keys instead of package name prefixes > -- > > Key: CAMEL-1373 > URL: https://issues.apache.org/activemq/browse/CAMEL-1373 > Project: Apache Camel > Issue Type: Task > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.0.0 > > > We have agreed as part of the 2.0 API rework to use CamelCase header keys. > Currently keys using dots violates the JMS spec and other protocols might > have problems with them as well. > And Camel should of course use CamelCase :) > And they are also easier to read, and less words to type. > There is a discussion on the dev forum about it - title "Camel 2.0 - Keys for > header problem" > Cant like using Nabble as they havent changed to TLP domain -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1382) should we zap the Route class?
should we zap the Route class? --- Key: CAMEL-1382 URL: https://issues.apache.org/activemq/browse/CAMEL-1382 Project: Apache Camel Issue Type: Improvement Reporter: James Strachan Fix For: 2.0.0 it seems kinda confusing and am not sure if its got real value? I'm just about to add a class I'm calling RouteService which is-a Service representing a runtime image of a RouteType which can be started/stopped. Am wondering if we zap Route - or if we just make Route be the RouteService? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Where exception handling should set a handled exception?
Hello!
Recently I created an issue (CAMEL-1356) about exception handling and
now I'm not really sure if it is really a bug or not. So I'm asking
for your opinions.
The problem is that when exception is caught it is set as a
'caught.exception' header on IN message. It means that if an exception
is thrown on an exchange that already has OUT message it will be lost
after the first step of a pipeline.
We have few possible solutions here:
1) Keep it as it is - then we know where to look for this header in
the first step of the pipeline - we can also use bean integration and
@Header annotation to retrieve it)
2) Put the exception to header on OUT message if it is present - then
it will be preserved in the pipeline. But then first step of the
pipeline has to be clever - it has to look for it in OUT message.
Moreover it is more general problem - if we allow OUT messages there,
then you cannot use for example setHeader("foo") (you can, but it is
useless, as out is propagated anyway)
3) Put it into exchange property - maybe the best solution as it is
propagated, and we always know where to look for the exception. It
will not be lost at some endpoint also.
I believe this change should by put to 2.0 only as it might break
someones exception handling completely, shouldn't it?
This time I don't want to start flame about need for in/out messages
once again, but... ;)
Roman
Re: Problem with jetty endpoint
Hi,
I able to run the jetty endpoint with file endpoint successfully and also
received expected output (2 file endpoint).
Thanks,
Ganesh
Claus Ibsen-2 wrote:
>
> Hi
>
> What is the exception you get?
>
> To be able to store it as a file it much use something that is
> InputStream convertable. Maybe the jetty stuff isn't really that.
> Check using the debugging in the java code what Object type the IN
> message body is?
>
> You can use .convertBodyTo(String.class) etc. to force it to use
> String when it stores as a file
> .convertBodyTo(String.class)
> .to("file://todir");
>
>
> Have you tried with a simple URI for the file, without the D:
> to("file://todir")
>
>
>
>
>
> On Tue, Jan 6, 2009 at 11:55 AM, Ganesh_Progress
> wrote:
>>
>> Yes, Using Fuse integration designer to debug.
>>
>> I tried with java DSL also but, facing the same unable to create the file
>> at
>> destination.
>>
>> Java DSL code as follows, which i ran
>>
>> context.addRoutes(new RouteBuilder() {
>>
>>public void configure()
>>{
>>Processor proc = new Processor() {
>>public void process(Exchange e) throws Exception
>>{
>>System.out.println("Received exchange: " +
>> e.getIn().getBody(String.class));
>>}
>>};
>>
>
>>
>> from("jetty:http://localhost:8080/test";).process(proc).to("file:///D:/FID_341/runtime-New_configuration/FuseMR/toDir");
>>
>>
>> from("file:///D:/FID_341/runtime-New_configuration/FuseMR/toDir").process(new
>> Processor()
>> {
>> public void process(Exchange e)
>> {
>> System.out.println("Received exchange: " +
>> e.getIn());
>> }
>> });
>>
>>}
>>}); context.start();
>>
>> Thanks
>> Ganesh
>>
>>
>>
>>
>>
>> Claus Ibsen-2 wrote:
>>>
>>> Hi
>>>
>>> Are you using Fuse integration designer to debug it?
>>> http://fusesource.com/products/fuse-integration-designer/
>>>
>>> I didn't know you could set a breakpoint in a .xml file ;)
>>>
>>> If you get it to some java code then you can set a breakpoint in java
>>> code and then Eclipse should be able to dump all the debug variables.
>>>
>>> So you can create a new class that implements
>>> org.apache.camel.Processor and then route from jetty to that one
>>>
>>>
>>>
>>> Something like this:
>>>
>>>
>>>
>>> Then set a breakpoint in the java code in com.mycompany.MyProcossor
>>> and you should be able to inspect the data.
>>>
>>>
>>>
>>>
>>> On Tue, Jan 6, 2009 at 11:19 AM, Ganesh_Progress
>>> wrote:
I deleted given destination e.g. "in" and started camel, but file is
not
created.
I tried with JMS endpoints and observed same.
Further, i try to debug the camel and observed that "?" as its value at
from
URI.
Please find the attached screen shot for the same.
Still am i missing something.
Claus Ibsen-2 wrote:
>
> On Tue, Jan 6, 2009 at 8:44 AM, Ganesh_Progress
> wrote:
>>
>> Hi Claus,
>>
>> By using the below endpoint i able to run successfully without any
>> exceptions in the console, but file is not created at given
>> destination.
>> Is it a valid endpoint ? if not point me to some valid endpoints.
>>
>> http://localhost:8080/test
>>
>> e.g. from("jetty:http://localhost:8080/test";)
> Yeah that is the correct endpoint, for exposing a http service (= you
> being the server)
>
> If you need the reverse situation then use just http (= you being the
> client calling an external web site)
>
> Could you try replacing the file endpoint with another to see if you
> get some data?
> You can use a log endpoint instead that will log using commons-logger
> to INFO level
>
>
>
> BTW Is the folder created where you expect the file to be dropped?
> D:/FID_341/runtime-New_configuration/FuseFIDCamel/Jetty/in
>
> You can try to delete it and start Camel. If the folder is created
> then something is working ;)
>
> You can also enable org.apache.camel at DEBUG level to see what is
> going
> on.
>
>
>
>>
>>
>> Thanks,
>> Ganesh
>>
>>
>> Claus Ibsen-2 wrote:
>>>
>>> Hi
>>>
>>> You can enable the tracer that logs how exchanges is routed in
>>> Camel.
>>> It will log the payload content and the payload object type.
>>> http://activemq.apache.org/camel/tracer.html
>>>
>>> (hint: setting trace="true" in the spring XML file).
>>>
>>> To be able to store as a file it should be convertible to
>>> InputStream.
>>> But check out if there is any data in the first place from the jetty
>>> endpoint.
>>>
>>> You can also send it to a log instead of a file with:
>>> to("log:hello")
[jira] Created: (CAMEL-1381) PredicateClause in the fluent builder for building predicates using fluent builder syntax
PredicateClause in the fluent builder for building predicates using fluent
builder syntax
-
Key: CAMEL-1381
URL: https://issues.apache.org/activemq/browse/CAMEL-1381
Project: Apache Camel
Issue Type: New Feature
Components: camel-core
Reporter: Claus Ibsen
Fix For: Future
The problem is when using predicates in the fluent builder you can not build an
expression but only call a single predicate.
James gave a hint on a solution:
>> Minor issue but I have been trying to coax folks away from this form
>> of DSL (e.g. figure 15)
>>
>> when(header("type").
>>
>> to
>>
>> when().header("type")...
>>
>> not always applicable - but its just to let the IDE do better
>> completion and let us remove some of the kinda global bits of DSL we
>> still have lying around the code.
> Yeah I will go over and change the ones that is possible. However when
> you chain a method then its not possible, eg:
>
> when().header("type").isEqualTo("foo").to("seda:foo");
Yeah - for things like that we currently have to use the EL / simple /
XPath expression languages.
I guess we could add some DSL to build them maybe...
when().is().header("foo").equalTo("something").
or
when().is().header("foo").equalTo().header("bar");
i.e. the is() builds a kinda binary expression with the first
expression returning a binary expression which is then used to build
an == != > < <= >= type expression with another expression?
Not totally sure its worth it though :)
So something like the ExpressionClause that can do this for expression, we can
create a PredicateClause that preserves the original type so you can continue
routing afterwards.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard updated CAMEL-1364:
-
Attachment: camel-bindy-fixsimple.txt
@Hi,
Here is the patch for the folder required (src/...fix/simple)
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
> Attachments: camel-bindy-fixsimple.txt, camel-bindy-keyvaluepair.patch
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49970#action_49970
]
Charles Moulliard commented on CAMEL-1364:
--
@Willem,
Do I have to update my svn project prior to generate the patch for this
directory ?
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
> Attachments: camel-bindy-keyvaluepair.patch
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49969#action_49969
]
Willem Jiang commented on CAMEL-1364:
-
@Charles
Can you create a patch for
src/test/java/org/apache/camel/dataformat/bindy/model/fix/simple ?
I will take care of the rest :)
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
> Attachments: camel-bindy-keyvaluepair.patch
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1364) Add BindyKeyValuePairFormat to handle content formatted with key value pairs fields like we have in FIX, EMX messages
[
https://issues.apache.org/activemq/browse/CAMEL-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49968#action_49968
]
Charles Moulliard commented on CAMEL-1364:
--
@Willem,
The directory that you mention is not located under src/main but under src/test.
wrong : src/main/java/org/apache/camel/dataformat/bindy/model/fix/simple
correct : src/test/java/org/apache/camel/dataformat/bindy/model/fix/simple
@Hi,
Do I have to do something now ?
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> -
>
> Key: CAMEL-1364
> URL: https://issues.apache.org/activemq/browse/CAMEL-1364
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-bindy
>Reporter: Charles Moulliard
>Assignee: Willem Jiang
> Fix For: 2.0.0
>
> Attachments: camel-bindy-keyvaluepair.patch
>
>
> Add BindyKeyValuePairFormat to handle content formatted with key value pairs
> fields like we have in FIX, EMX messages
> So the following FIX message :
> 8=FIX.4.1\0019=112\00135=0\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001112=19980604-07:58:28\00110=157\001
> could be mapped to POJO like this
> @Link
> public Class Header {
> @KeyValuePair(tag = 8) // e.g. FIX 4.1
> private string BeginStr;
> @(tag = 9)
> private int BodyLength;
>
> }
> @Message(type = FIX, version = 4.1, keyValuePairSeparator = "=",
> pairSeparator = "\001")
> public class Message {
>@Link
>private Header header;
>@Link
>private Trailer trailer;
> @KeyValuePair(tag = 52, pattern = "mmdd-hh:mm:ss", mandatory="false")
> private Date SendTime;
> }
> @Link
> public class Trailer {
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1380) Aggregator - completedPredicate should be renamed to completionPredicate to be in line with wording
[
https://issues.apache.org/activemq/browse/CAMEL-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-1380.
Resolution: Fixed
> Aggregator - completedPredicate should be renamed to completionPredicate to
> be in line with wording
> ---
>
> Key: CAMEL-1380
> URL: https://issues.apache.org/activemq/browse/CAMEL-1380
> Project: Apache Camel
> Issue Type: Task
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.0.0
>
>
> {code:xml}
>
>
>
>
>
> ${header.CamelAggregatedCount} > 2
>
>
> {code}
> Should be:
> {code}
>
>
>
>
>
> ${header.CamelAggregatedCount} > 2
>
>
> {code}
> So its in line with the correlation expression
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
