Re: question on HttpMessage.populateInitialHeaders
On Tue, Feb 24, 2009 at 2:34 AM, William Tam wrote:
> In HttpMessage.populateInitialHeaders(), we only propagate parameters
> for GET request. Does anyone see any harm in propagating other
> parameters of HTTP methods?
I was wondering if the API below can return parameters for POST etc?
Maybe the answer is obvious but I thought that API below fetches the
GET URI parameters?
So which other operations can it also get parameters from?
For POST aren't "paramenters" not stored as HTTP headers?
>
> //if the request method is Get, we also populate the http
> request parameters
> if (request.getMethod().equalsIgnoreCase("GET")) {
> names = request.getParameterNames();
> while (names.hasMoreElements()) {
> String name = (String)names.nextElement();
> Object value = request.getParameter(name);
> map.put(name, value);
> }
> }
>
> Thanks,
> William
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Discussion of scope for next Apache Camel 1.x release
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/
[jira] Created: (CAMEL-1376) wiretap() to be able to send an InOnly message exchange with the result of an InOut request without affecting the current message exchange
wiretap() to be able to send an InOnly message exchange with the result of an
InOut request without affecting the current message exchange
--
Key: CAMEL-1376
URL: https://issues.apache.org/activemq/browse/CAMEL-1376
Project: Apache Camel
Issue Type: Improvement
Reporter: James Strachan
Fix For: 2.0.0
we should be able to do something like this...
{code}
from("jetty:http://localhost:8585/cxf/HelloWorld";)
.to("http://localhost:8080/cxf/HelloWorld";)
.wiretap("seda:cheese");
{code}
such that the *seda:cheese* gets the output of the HelloWorld service as an
InOut - but the response is returned fine to the HTTP client. i.e. the presence
of the wiretap() does not in any way affect the exchange - it appears to work
exactly the same as
{code}
from("jetty:http://localhost:8585/cxf/HelloWorld";)
.to("http://localhost:8080/cxf/HelloWorld";);
{code}
and any output of the seda:cheese does not affect the response to the HTTP
client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CAMEL-1365) Refactor the class BindyCsvDataFormat in order to create an abstract class to keep what will be common between BindyCsvDataFormat, BindyKeyValuePairDataFormat, ....
[ https://issues.apache.org/activemq/browse/CAMEL-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Moulliard closed CAMEL-1365. Resolution: Fixed > Refactor the class BindyCsvDataFormat in order to create an abstract class to > keep what will be common between BindyCsvDataFormat, > BindyKeyValuePairDataFormat, > - > > Key: CAMEL-1365 > URL: https://issues.apache.org/activemq/browse/CAMEL-1365 > Project: Apache Camel > Issue Type: Sub-task > Components: camel-bindy >Reporter: Charles Moulliard > Fix For: 2.0.0 > > > Refactor the class BindyCsvFactory in order to create an abstract class to > keep what will be common between BindyCsvFactory, BindyKeyValuePairFactory, > > BindyCsvFactory --> extract common part and put it in BindyAbstractFactory -- 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-keyvaluepair.patch
Here is camel patch for key value pair format (FIX message), refactoring + doc
update
> 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
> 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] Assigned: (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 reassigned CAMEL-1356:
Assignee: Roman Kalukiewicz
> 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
>Priority: Critical
>
> 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.
Re: Discussion of scope for next Apache Camel 1.x release
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/
Re: Discussion of scope for next Apache Camel 1.x release
+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/
[jira] Created: (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
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 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.
Re: Discussion of scope for next Apache Camel 1.x release
+1 for doing a mile stone release of Camel 2.0. And we just do the bug fix on the Camel 1.x branch. Willem On Tue, Feb 24, 2009 at 9:08 PM, 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] Assigned: (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 reassigned CAMEL-1377: -- Assignee: Jonathan Anstey > 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-1378) @Header should have a value default so you do not have to set the name attribute
@Header should have a value default so you do not have to set the name attribute
Key: CAMEL-1378
URL: https://issues.apache.org/activemq/browse/CAMEL-1378
Project: Apache Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 1.6.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 2.0.0
Doing this bean binding:
{code}
public List route(@XPath("/customer/id") String customerId,
@Header("Location") String location, Document body) {
{code}
The @Header does not have a default value, so you have to do this to get it to
work:
{code}
public List route(@XPath("/customer/id") String customerId,
@Header(name = "Location") String location, Document body) {
{code}
So we should support you do not have to set the name attribute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAMEL-1378) @Header should have a value default so you do not have to set the name attribute
[
https://issues.apache.org/activemq/browse/CAMEL-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-1378.
Resolution: Fixed
Committed revision 747428.
Fixed @Property as well
> @Header should have a value default so you do not have to set the name
> attribute
>
>
> Key: CAMEL-1378
> URL: https://issues.apache.org/activemq/browse/CAMEL-1378
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 1.6.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.0.0
>
>
> Doing this bean binding:
> {code}
> public List route(@XPath("/customer/id") String customerId,
> @Header("Location") String location, Document body) {
> {code}
> The @Header does not have a default value, so you have to do this to get it
> to work:
> {code}
> public List route(@XPath("/customer/id") String customerId,
> @Header(name = "Location") String location, Document body) {
> {code}
> So we should support you do not have to set the name attribute.
--
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=49958#action_49958
]
Michael Chen commented on CAMEL-1366:
-
As I stated above, I want to end the current process chain without sending back
a reply. When the long running services is completed, the reply will be sent
then and only then. This free up the original processing thread immediately.
The original caller still gets the response it expect.
I now realize that the RouteBuilder methods like inOnly(), outOnly(), etc. are
useless. They only effects downstream processors in the route. It does NOT
change the MEP of the endpoint and its behavior. I will submit a separate bug
on this.
> 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.
[jira] Commented: (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 dependencie
[ https://issues.apache.org/activemq/browse/CAMEL-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49959#action_49959 ] Jonathan Anstey commented on CAMEL-1377: Put initial stab at this in revision 747543. Will look a bit tomorrow at adding docs and throwing another component into the sample route. > 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-1379) Mina configuration is shared between endpoints
Mina configuration is shared between endpoints -- Key: CAMEL-1379 URL: https://issues.apache.org/activemq/browse/CAMEL-1379 Project: Apache Camel Issue Type: Bug Components: camel-mina Affects Versions: 1.5.0 Environment: All Reporter: Christopher Hunt Establishing a MINA endpoint with a custom codec, and then establishing another without a custom codec is a problem. The second endpoint inherits the first endpoint's codec. My recommendation is to not share configuration data between endpoint creation. I recommend that the MINA component instantiate a new configuration for each new endpoint instead of copying the previous configuration. As a workaround the user can specify "codec" as a URI parameter with no value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (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
]
Willem Jiang reassigned CAMEL-1364:
---
Assignee: Willem Jiang
> 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=49960#action_49960
]
Willem Jiang commented on CAMEL-1364:
-
Hi Charles,
Thanks for your patch , I just tried to apply your patch, but I got the compile
error when I built the camel-bindy module with your patch.
You may forget to add the
src/main/java/org/apache/camel/dataformat/bindy/model/fix/simple directory into
the svn repo before you creating the patch.
Please run "svn st" to check the file with ? before using "svn diff" to
generate the patch.
In this way we could avoid the missing part :)
Cheers,
Willem
> 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-1308) camel-cxf to support jaxrs consumer
[ https://issues.apache.org/activemq/browse/CAMEL-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Tam resolved CAMEL-1308. Resolution: Fixed > camel-cxf to support jaxrs consumer > --- > > Key: CAMEL-1308 > URL: https://issues.apache.org/activemq/browse/CAMEL-1308 > Project: Apache Camel > Issue Type: New Feature > Components: camel-cxf >Reporter: William Tam >Assignee: William Tam > Fix For: 2.0.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAMEL-1379) Mina configuration is shared between endpoints
[ https://issues.apache.org/activemq/browse/CAMEL-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-1379: --- Assignee: Willem Jiang > Mina configuration is shared between endpoints > -- > > Key: CAMEL-1379 > URL: https://issues.apache.org/activemq/browse/CAMEL-1379 > Project: Apache Camel > Issue Type: Bug > Components: camel-mina >Affects Versions: 1.5.0 > Environment: All >Reporter: Christopher Hunt >Assignee: Willem Jiang > > Establishing a MINA endpoint with a custom codec, and then establishing > another without a custom codec is a problem. The second endpoint inherits the > first endpoint's codec. > My recommendation is to not share configuration data between endpoint > creation. I recommend that the MINA component instantiate a new configuration > for each new endpoint instead of copying the previous configuration. > As a workaround the user can specify "codec" as a URI parameter with no value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-1379) Mina configuration is shared between endpoints
[ https://issues.apache.org/activemq/browse/CAMEL-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49962#action_49962 ] Claus Ibsen commented on CAMEL-1379: Please add an unit test verifying the fix, but adding 2 mina consumers: - with custom codec - no custom codec, eg textline=true And backport the fix to 1.x if possible. Mina on trunk is changed a bit over 1.x > Mina configuration is shared between endpoints > -- > > Key: CAMEL-1379 > URL: https://issues.apache.org/activemq/browse/CAMEL-1379 > Project: Apache Camel > Issue Type: Bug > Components: camel-mina >Affects Versions: 1.5.0 > Environment: All >Reporter: Christopher Hunt >Assignee: Willem Jiang > > Establishing a MINA endpoint with a custom codec, and then establishing > another without a custom codec is a problem. The second endpoint inherits the > first endpoint's codec. > My recommendation is to not share configuration data between endpoint > creation. I recommend that the MINA component instantiate a new configuration > for each new endpoint instead of copying the previous configuration. > As a workaround the user can specify "codec" as a URI parameter with no value. -- 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=49963#action_49963
]
Claus Ibsen commented on CAMEL-1364:
Charles please do NOT change anything in the root pom.xml.
In your patch you have added log4j as default. You should use Apache Commons
Logging for ALL your logging.
log4j is only allowed to be in maven test scope.
So the patch should be created on the camel-bindy project alone.
> 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-1366) EndpointMessageListener should respect ExchangePattern
[
https://issues.apache.org/activemq/browse/CAMEL-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49964#action_49964
]
Claus Ibsen commented on CAMEL-1366:
@Michael
The last one is not a bug. inOnly, inOut is used to affect/change the MEP on
route.
What you are asking for is on the consumer side (jms consumer, the from node)
to set it to request only, or request-reply.
However the jms spec has this JMSReplyTo that we should honor. So if someone
sends a JMS message to a queue with a JMSReplyTo header then that caller would
expect a reply on that destination and thus Camel should honor this and return
a reply.
So today you can do what you want:
{code}
from("activemq:my_queue").to("predict_weather://?reply_later=true");
{code}
If the message sent to my_queue does NOT contain a JMSReplyTo then its a
request only.
However what we could consider is to also test for exchange.isOutCapable() and
send a "null" body if the test fails to signal no/empty reply.
> 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.
[jira] Updated: (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
]
Claus Ibsen updated CAMEL-1356:
---
Priority: Major (was: Critical)
Fix Version/s: 1.6.1
2.0.0
Roman please also change the header key to the new CamelCase syntax for the 2.x
commit. You can look at samples on the Exchange interface in 2.0.
> 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, 1.6.1
>
>
> 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] 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=49966#action_49966
]
Willem Jiang commented on CAMEL-1364:
-
@ Claus,
The change of pom.xml is only in the camel-bindy module :)
BTW, I will remove that dependency.
> 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-1379) Mina configuration is shared between endpoints
[ https://issues.apache.org/activemq/browse/CAMEL-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49967#action_49967 ] Willem Jiang commented on CAMEL-1379: - @ Claus I'm working on the back porting to 1.x branch now and will add the unit test for it. > Mina configuration is shared between endpoints > -- > > Key: CAMEL-1379 > URL: https://issues.apache.org/activemq/browse/CAMEL-1379 > Project: Apache Camel > Issue Type: Bug > Components: camel-mina >Affects Versions: 1.5.0 > Environment: All >Reporter: Christopher Hunt >Assignee: Willem Jiang > > Establishing a MINA endpoint with a custom codec, and then establishing > another without a custom codec is a problem. The second endpoint inherits the > first endpoint's codec. > My recommendation is to not share configuration data between endpoint > creation. I recommend that the MINA component instantiate a new configuration > for each new endpoint instead of copying the previous configuration. > As a workaround the user can specify "codec" as a URI parameter with no value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAMEL-1380) Aggregator - completedPredicate should be renamed to completionPredicate to be in line with wording
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.
