[jira] Closed: (CAMEL-2805) It is impossible to put # sign in SQL statement in camel-sql

[ https://issues.apache.org/activemq/browse/CAMEL-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz closed CAMEL-2805. Fix Version/s: 2.4.0 Resolution: Fixed Change introducing {{placeholder

[jira] Created: (CAMEL-2805) It is impossible to put # sign in SQL statement in camel-sql

Affects Versions: 2.3.0 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz {{SqlProducer}} implementation turns all {{#}} characters into {{?}} making it impossible to have {{#}} in the SQL statement. -- This message is automatically generated by JIRA. - You can reply

[jira] Commented: (CAMEL-2510) Mixing jetty/http in a route screws up the URI used by HttpClient

[ https://issues.apache.org/activemq/browse/CAMEL-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=57996#action_57996 ] Roman Kalukiewicz commented on CAMEL-2510: -- I believe I was misunderstood :)

[jira] Commented: (CAMEL-2510) Mixing jetty/http in a route screws up the URI used by HttpClient

[ https://issues.apache.org/activemq/browse/CAMEL-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=57953#action_57953 ] Roman Kalukiewicz commented on CAMEL-2510: -- Should we really have such assertio

[jira] Commented: (CAMEL-2287) Using filter before split causes filtered messages to not be aggregated as they where marked as filtered

[ https://issues.apache.org/activemq/browse/CAMEL-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56422#action_56422 ] Roman Kalukiewicz commented on CAMEL-2287: -- There is also a test that coul

Re: To Roman - About TryProcessor

Hello Claus, It looks that the source of those lines is http://issues.apache.org/activemq/browse/CAMEL-191 so I'm not the best person to ask ;) But I would say, that the copy is not really needed here as catchClause.process() is invoked in the same thread. I would first remove the copy() operat

[jira] Resolved: (CAMEL-2077) Ignore message body in sql endpoint if query doesn't have any parameters

[ https://issues.apache.org/activemq/browse/CAMEL-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-2077. -- Resolution: Fixed Commited to r826630 > Ignore message body in sql endpoint

[jira] Created: (CAMEL-2077) Ignore message body if query doesn't have any parameters

ement Affects Versions: 2.0.0 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Priority: Trivial Fix For: 2.1.0 When sql endpoint is simple query without any parameters it would be good to simply ignore any body of the message it receives. The

[jira] Updated: (CAMEL-2077) Ignore message body in sql endpoint if query doesn't have any parameters

[ https://issues.apache.org/activemq/browse/CAMEL-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz updated CAMEL-2077: - Summary: Ignore message body in sql endpoint if query doesn't have any param

Re: [DISCUSS] - Camel 2.0 - Case insensitive headers on Camel Message

2009/8/10 Claus Ibsen : > Its definitely not strange. In fact the old behavior is more strange, > as you end up having duplicate headers by mistake. > > Imagine integrating to a remote system you have no control over and if > you are lucky using JMS. Then you have been told that they will add a > J

Re: [DISCUSS] - Camel 2.0 - Case insensitive headers on Camel Message

2009/8/10 Claus Ibsen : > On Mon, Aug 10, 2009 at 2:02 PM, James Strachan > wrote: >> 2009/8/10 Roman Kalukiewicz : >>> Just few general comments on the topic here: >>> >>> 1) My impression is that we are trying to solve problem that doesn't >

Re: [DISCUSS] - Camel 2.0 - Case insensitive headers on Camel Message

Just few general comments on the topic here: 1) My impression is that we are trying to solve problem that doesn't exist. No one would expect that getting "foo" header should retrieve what was put under "FOO" key. If we want to have guarantee that it works properly people should use constants for i

[jira] Commented: (CAMEL-1882) Aggregator fails permanently if exception thrown from aggregation strategy

[ https://issues.apache.org/activemq/browse/CAMEL-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53500#action_53500 ] Roman Kalukiewicz commented on CAMEL-1882: -- The problem also exists if exceptio

[jira] Resolved: (CAMEL-1883) EXCEPTION_CAUGHT header should be set to exception caught

[ https://issues.apache.org/activemq/browse/CAMEL-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-1883. -- Resolution: Fixed Fixed in r801596 > EXCEPTION_CAUGHT header should be set

[jira] Created: (CAMEL-1883) EXCEPTION_CAUGHT header should be set to exception caught

Components: camel-core Affects Versions: 2.0-M3 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Fix For: 2.0.0 Currently whatever exception is caught in doCatch there is a EXCEPTION_CAUGHT header set to the exception that was set on the exchange

What should be in EXCEPTION_CAUGHT header in doTry()?

Hello Camel Developers! I have rather fundamental question already stated in the topic of this email. In typical scenario the answer is obvious but what about traversing exception causes? .doTry() .throw(new RuntimeCamelException(new CamelException())) .doCatch(CamelException) // What is here in

Re: svn commit: r801545 - in /camel/trunk/camel-core/src: main/java/org/apache/camel/processor/BatchProcessor.java test/java/org/apache/camel/processor/aggregator/AggregatorExceptionInPredicateTest.j

Hmm.. the test doesn't pass if I did it and expected to have error handler invoked. It is because exchange e is discarded really - it is not added to the aggregated one (as add() failed) and it is a new exchange anyway (a copy) that was asynchronously pulled from BatchProcessor's internal blocking

[jira] Resolved: (CAMEL-1882) Aggregator fails permanently if exception thrown from aggregation strategy

[ https://issues.apache.org/activemq/browse/CAMEL-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-1882. -- Resolution: Fixed Fix in r801545 The fix could be improved as errors are not

[jira] Created: (CAMEL-1882) Aggregator fails permanently if exception thrown from aggregation strategy

Issue Type: Bug Components: camel-core Affects Versions: 2.0-M3 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Priority: Critical Fix For: 2.0.0 {{BatchSender}} thread in {{BatchProcessor}} doesn't expect any

Re: [DISCUSS] Semantics of IN and OUT (was: Faults and Exceptions in Camel)

2009/7/14 James Strachan : > 2009/7/13 Claus Ibsen : >>> >>> Reading between the lines; are you really just trying to make folks >>> use (what is currently called) "getOut()" and never try mutate what is >>> currently called getIn()? >>> >>> i.e. so by default the "OUT" property is defaulted to a c

Re: [DISCUSS] Semantics of IN and OUT (was: Faults and Exceptions in Camel)

2009/7/13 Claus Ibsen : > On Mon, Jul 13, 2009 at 5:50 PM, James Strachan > wrote: >> I'm confused. So rather than calling Exchange.getIn() to get the IN, >> you'd have to do Exchange.getUnitOfWork().somethingOrOther() to get >> the last IN? I don't see that as any simpler; making one of the 2 >>

Re: [DISCUSS] Faults and Exceptions in Camel

2009/7/10 James Strachan : > 2009/7/10 Roman Kalukiewicz : >> 2009/7/10 Claus Ibsen : >>> Now that we have opened the box with IN OUT FAULT api changes I would >>> like to point out issues related to OUT >>> >>> Given this code: >>> >&

Re: [DISCUSS] Faults and Exceptions in Camel

2009/7/10 Claus Ibsen : > Now that we have opened the box with IN OUT FAULT api changes I would > like to point out issues related to OUT > > Given this code: > >        Exchange out = template.send("direct:start", new Processor() { >            public void process(Exchange exchange) throws Excepti

Re: [DISCUSS] Faults and Exceptions in Camel

2009/7/9 Claus Ibsen : > I think the names should be > > boolean isFault() > void setFault() > > Yeah I do not think people should call setFault(false) > or later want to change an existing OUT message from fault to out or vice > versa. > > But is it confusing with a setter that dont accept parame

Re: [DISCUSSION / VOTE] - remove @author tags in code

Usually @author tag shows the class creator - not the actual maintainer of the class. Of course one person can have both roles, but in general I believe it is useless for Camel. My +1 Roman 2009/7/7 Claus Ibsen : > Hi > > I want to propose that we remove the @author tags in the source code > for

[jira] Resolved: (CAMEL-1745) Validator component to use SaxSource internally

[ https://issues.apache.org/activemq/browse/CAMEL-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-1745. -- Resolution: Fixed r787595. > Validator component to use SaxSource interna

[jira] Created: (CAMEL-1745) Validator component to use SaxSource internally

: camel-core Affects Versions: 2.0-M2 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Priority: Minor Fix For: 2.0.0 {{ValidatingProcessor}} uses DOMSource internally while SaxSource could perform better. -- This message is automatically

[jira] Resolved: (CAMEL-1723) Allow to set TTL on InOut JMS messages that is different than requestTimeout

[ https://issues.apache.org/activemq/browse/CAMEL-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-1723. -- Resolution: Fixed > Allow to set TTL on InOut JMS messages that is different t

[jira] Created: (CAMEL-1723) Allow to set TTL on InOut JMS messages that is different than requestTimeout

Issue Type: Improvement Components: camel-jms Affects Versions: 2.0-M2 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Priority: Minor Fix For: 2.0.0 {{createInOutTemplate()}} method in {{JmsConfiguration}} sets Time

Re: [DISCUSS - Camel 2.0 - API] - Exchange as final, also eg to discourage custom Exchange implementations

2009/5/14 Hadrian Zbarcea : > I personally don't see a reason for a specialized Exchange.  We already *do* > have specialized Messages and I think we should keep that (others have a > different opinion). > > CAMEL-1078, is implemented for the most part, I'll try to finish the > remaining stuff, for

[jira] Commented: (CAMEL-1078) Do not copy Exchanges at each step to improve performance

[ https://issues.apache.org/activemq/browse/CAMEL-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51690#action_51690 ] Roman Kalukiewicz commented on CAMEL-1078: -- So let me add my thoughts on it

Re: Facing problems while using Set Header camel Processor

Hello Sailaja, There is another question - do you send your test message as InOnly or InOut? In JMS world if you set JMSReplyTo property to some value Camel will work as InOut flow, so sending the message to Q1 ("jms:queue:TestMF1") will cause Camel to wait for the response and will override all h

[jira] Commented: (CAMEL-1563) Message - getOut, getFault should not create empty message if none exists

[ https://issues.apache.org/activemq/browse/CAMEL-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51421#action_51421 ] Roman Kalukiewicz commented on CAMEL-1563: -- Maybe I should just give an exampl

Re: [DISCUSS] Release Camel 2.0-M2 and 1.6.1

+1 2009/4/21 Hadrian Zbarcea : > Hi, > > I think quite a bit of progress has been made in the trunk and more patches > applied on the 1.x branch.  There is still some more work to be done on 2.0, > but I think what we have is a great candidate for a M2 release.  The time is > also right for a Came

Re: [DISCUSS] - Default error handler in Camel 2.0, what should we do?

I would definitely support #1. #3 is not so good as a default one because it can cause some side effects like when you use in-out JMS endpoint. If nothing listens to the queue, then you will end up with 6 messages in request queue instead of one (assuming you don't use transactions). BTW Last tim

[jira] Commented: (CAMEL-1320) Create GZip Data Format

[ https://issues.apache.org/activemq/browse/CAMEL-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50694#action_50694 ] Roman Kalukiewicz commented on CAMEL-1320: -- Both things done. Documentation t

[jira] Resolved: (CAMEL-1320) Create GZip Data Format

[ https://issues.apache.org/activemq/browse/CAMEL-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-1320. -- Resolution: Fixed Fix Version/s: 2.1.0 Created gzip data format > Cre

[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

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

[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&qu

[jira] Created: (CAMEL-1356) TryProcessor sets "caught.exception" header to in message, while there can be out already

CAMEL-1356 Project: Apache Camel Issue Type: Bug Components: camel-core Affects Versions: 1.6.0 Reporter: Roman Kalukiewicz Priority: Critical Error exists in {{org.apache.camel.processor.TryProcessor.handleException(Exchange, Throwable)}

[jira] Commented: (CAMEL-1320) Create GZip Data Format

[ https://issues.apache.org/activemq/browse/CAMEL-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49435#action_49435 ] Roman Kalukiewicz commented on CAMEL-1320: -- It is very similar to zip data fo

[jira] Resolved: (CAMEL-1297) Seda component should configure its executor

[ https://issues.apache.org/activemq/browse/CAMEL-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-1297. -- Resolution: Fixed concurrentConsumers parameter can be configured. There is no way

[jira] Created: (CAMEL-1320) Create GZip Data Format

Create GZip Data Format --- Key: CAMEL-1320 URL: https://issues.apache.org/activemq/browse/CAMEL-1320 Project: Apache Camel Issue Type: New Feature Components: camel-core Reporter: Roman Kalukiewicz

Re: Components setting data on OUT

2009/1/27 Andi Abes : > Having finally caught up with the discussion about header/property > copying and propagation, I thought it might be interesting to circle > back to the original question Claus posed (slightly reworded) - what is > the purpose of the out message? > > As a "flame generator" qu

[jira] Created: (CAMEL-1297) Seda component should configure its executor

-core Affects Versions: 1.5.0 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Fix For: 2.0.0 Currently SEDA endpoint processes only using 1 thread so it is impossible to easily configure few concurrent processings on 1 seda endpoint. I believe SEDA

Re: XML vs a dynamic DSL

2009/1/27 Ramon Buckland : > Because of the nature of moving paths (and shifting systems from dev to UAT > and UAT to production) we have found using XML is good for it's flexibile > change capabilities. > > However, I have as usual the XML has pain, that the XML's config becomes > cumbersome (we h

Re: Components setting data on OUT

2009/1/26 Claus Ibsen : > On Mon, Jan 26, 2009 at 3:37 PM, Roman Kalukiewicz > wrote: >> Why don't we talk about exchange properties here? My feeling here is >> that properties should be used as user-headers, while headers are >> always protocol headers. In fact it w

Re: Components setting data on OUT

Why don't we talk about exchange properties here? My feeling here is that properties should be used as user-headers, while headers are always protocol headers. In fact it works this way right now: If I want to keep some value through the whole flow I put it into properties. By current convention i

[jira] Resolved: (CAMEL-1283) SQL component doesn't handle wrong number of parameters

[ https://issues.apache.org/activemq/browse/CAMEL-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kalukiewicz resolved CAMEL-1283. -- Resolution: Fixed Patch commited > SQL component doesn't handle wrong n

[jira] Work started: (CAMEL-1283) SQL component doesn't handle wrong number of parameters

[ https://issues.apache.org/activemq/browse/CAMEL-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-1283 started by Roman Kalukiewicz. > SQL component doesn't handle wrong number of pa

[jira] Created: (CAMEL-1283) SQL component doesn't handle wrong number of parameters

fects Versions: 1.5.0 Reporter: Roman Kalukiewicz Assignee: Roman Kalukiewicz Fix For: 2.0.0 NPE thrown when null body sent to to SQL endpoint. When to many parameters are set then exception is thrown but nothing wrong happens when to less parameters are set