Re: Possible bug in netty-http - characters in body get unescaped?

[Jan Bednář]

Hello,
This is not about netty, but about Simple language. Simple language is 
not intended for static content. Camel does parsing of whole file while 
resolving simple placeholders in file content.

For this kind of usage you should use Constant language:
    
resource:classpath:jquery.js
    

Dne 5.6.2019 v 9:05 martin.scheff...@t-systems.com napsal(a):

Hi all,

I have this route to serve a static javascript file:


 http://0.0.0.0:8081/jquery.js"/>
 
 text/javascript
 
 
 resource:classpath:jquery.js
 


The file is served when I open it in the browser, but it is not identical to 
the file on disk. There is a string in the jquery.js file that goes something 
like this:

'\\t\\r\\n'
Or in words, [backslash backslash t backslash backslash r backslash backslash n]

The file that arrives in the browser does not contain these characters, but 
instead an actual line break is in that position.
You can find the jquery file here:
https://code.jquery.com/jquery-3.4.1.min.js

Is this a bug or am I missing some parameter for my route?

Thanks for your help!

Cheers,
Martin

Re: camel-ftp: meaning of option "UseUserKnownHostsFile" in combination with "knownHostsUri"

[Alex Dettinger]

Hi Peter,

  When CAMEL-8202 has been fixed, the isUseUserKnownHostsFile might have
been added to preserve the default behaviour across the camel 2.x line.
But then, the default value should have been false and you would not have
been impacted.

  At the end of the day, setting this option to false is needed as a
workaround in camel 2.x.
  However, I wonder if your idea could deserve creating a ticket against
camel-3.x.

Cheers,
Alex

Re: JMSReplyTo improperly utilised by camel to send an incomplete message

[Quinn Stevenson]

Since the route works as expected when you remove the split, I’d try moving all 
the split/aggregate logic into a direct route and call that from the main route 
and see if that works.


> On Jun 6, 2019, at 6:40 AM, Quinn Stevenson  
> wrote:
> 
> Mariusz I still have issues with the mailing list - he said:
> 
> Hi,
> 
> When I specify the consumer as "disableReplyTo=false" and remove the to("") 
> at the end, then after replacing split() with process(mockSplitter) and 
> aggregate() with process(mockAggregator), this works. The mocked message ends 
> up on the receiver topic (as expected).
> 
> For reference: mockSplitter is just a Processor that forwards the proper 
> message type (its content is mocked up) and mockAggregator is a Processor 
> that does the similar thing.
> 
> So the question is: what is the problem with the split() in my route? Or is 
> it something with unmarshal() or json() calls? Am I using those improperly?
> 
> Also, to add some more insight: in my code (in the whole processing on the 
> route), I'm only using exchage.in and I never touch exchange.out (so 
> throughout the processing, each exchange.out appears as null, as it was never 
> accessed). Does that matter?
> 
> Thanks and regards!
> 
> 
>> On Jun 5, 2019, at 6:54 AM, Quinn Stevenson > > wrote:
>> 
>> Mariusz sent the following to me directly (he’s having trouble with the 
>> mailing list).
>> 
>> Hi,
>> 
>> First of all, you seem to have mixed the terms up a bit. "true" and "false" 
>> work the other way than you described, aren't they?
>> 
>> Also: did you mean setting those on the consumer ("from") or producer ("to") 
>> side?
>> 
>> And lastly: camel does not send the reply at the end of the route (hence my 
>> OP!), it sends it in the middle.
>> 
>> Just to recap - as this might be important - my route works as follows:
>> 1) it processes the requests as MyRequest object,
>> 2) then splits them into smaller Messages,
>> 3) sends them to a REST service,
>> 4) unmarshalls as MyResponse objects,
>> 5) aggregates into a bulk object,
>> 6) then processes it and turns into a text message at the end of the route
>> 
>> Camel uses JMSReplyTo destination and send an object of type MyRequest 
>> (between steps 1 and 2), which is clearly not the end of my route.
>> What is wrong here?
>> 
>> 
>> My responses are:
>> 
>> I did switch the true and false settings for disableReplyTo - my bad.
>> 
>> I would assume you’re looking for the JMS request/response functionality 
>> from the consumer (the from), and you’d like the “aggregated bulk object” 
>> from step 5 above sent as the response to the JMSReplyTo queue.   If it was 
>> working the way I remembered, you wouldn’t need the to(jms…) at the end at 
>> all.  I’m wondering if the sub-routes created but the split are effecting 
>> the functionality?  Can you try a simple test with out the split and see if 
>> it behaves as expected?
>> 
>> 
>> 
>>> On Jun 4, 2019, at 8:32 AM, Quinn Stevenson >> > wrote:
>>> 
>>> It’s been a while since I’ve implemented a route that implements JMS 
>>> request-response, but if I remember correctly, you need to choose whether 
>>> Camel/Spring will handle the reply or you will.
>>> 
>>> If you set disableReplyTo=true, Camel/Spring will send the reply using 
>>> whatever is in the exchange at the end of the route (so you don’t need the 
>>> “to” at the end of the route).  If you set disableReplyTo=false, then 
>>> you’re responsible for taking the appropriate action with the message.
>>> 
>>> HTH
>>> 
>>> 
 On Jun 4, 2019, at 3:18 AM, Mariusz Kosecki >>> > wrote:
 
 Hello,
 My route is as follows:
 
 from("jms:topic:T.INPUT?disableReplyTo=false")
 .process(requestProcessor)
 .unmarshal().json(JsonLibrary.Jackson, MyRequest.class)
 .split(messageSplitter)
 .process(restProcessor)
 .unmarshal().json(JsonLibrary.Jackson, MyResponse.class)
 .aggregate(messagesAggregator)
 .process(responseProcessor)
 .to("jms:topic:recipientTopic");
 
 If I set disableReplyTo=true and convert JMSReplyTo into
 CamelJmsDestinationName, I get the expected result: process the request and
 send the response to the output topic.
 But I cannot comprehend why would I need to disable reply to, when in fact
 I want to utilise it.
 Currently, when disableReplyTo is set to false, I will end up a gibberish
 message on the output topic, which cannot be parsed and throws an exception
 "ClassNotFoundException: (package name).MyRequest" - it seems that camel
 utilises JMSReplyTo between the first unmarshal() and split(), which is
 unwanted as the message processing is incomplete. Is this a bug? Is this
 explicitly documented somewhere? Am I doing something wrong? Are there too
 many steps in the route? Can anyone explain?
 
 Kind regards.
>>> 
>> 
> 

Re: JMSReplyTo improperly utilised by camel to send an incomplete message

[Quinn Stevenson]

Mariusz I still have issues with the mailing list - he said:

Hi,

When I specify the consumer as "disableReplyTo=false" and remove the to("") at 
the end, then after replacing split() with process(mockSplitter) and 
aggregate() with process(mockAggregator), this works. The mocked message ends 
up on the receiver topic (as expected).

For reference: mockSplitter is just a Processor that forwards the proper 
message type (its content is mocked up) and mockAggregator is a Processor that 
does the similar thing.

So the question is: what is the problem with the split() in my route? Or is it 
something with unmarshal() or json() calls? Am I using those improperly?

Also, to add some more insight: in my code (in the whole processing on the 
route), I'm only using exchage.in and I never touch exchange.out (so throughout 
the processing, each exchange.out appears as null, as it was never accessed). 
Does that matter?

Thanks and regards!


> On Jun 5, 2019, at 6:54 AM, Quinn Stevenson  
> wrote:
> 
> Mariusz sent the following to me directly (he’s having trouble with the 
> mailing list).
> 
> Hi,
> 
> First of all, you seem to have mixed the terms up a bit. "true" and "false" 
> work the other way than you described, aren't they?
> 
> Also: did you mean setting those on the consumer ("from") or producer ("to") 
> side?
> 
> And lastly: camel does not send the reply at the end of the route (hence my 
> OP!), it sends it in the middle.
> 
> Just to recap - as this might be important - my route works as follows:
> 1) it processes the requests as MyRequest object,
> 2) then splits them into smaller Messages,
> 3) sends them to a REST service,
> 4) unmarshalls as MyResponse objects,
> 5) aggregates into a bulk object,
> 6) then processes it and turns into a text message at the end of the route
> 
> Camel uses JMSReplyTo destination and send an object of type MyRequest 
> (between steps 1 and 2), which is clearly not the end of my route.
> What is wrong here?
> 
> 
> My responses are:
> 
> I did switch the true and false settings for disableReplyTo - my bad.
> 
> I would assume you’re looking for the JMS request/response functionality from 
> the consumer (the from), and you’d like the “aggregated bulk object” from 
> step 5 above sent as the response to the JMSReplyTo queue.   If it was 
> working the way I remembered, you wouldn’t need the to(jms…) at the end at 
> all.  I’m wondering if the sub-routes created but the split are effecting the 
> functionality?  Can you try a simple test with out the split and see if it 
> behaves as expected?
> 
> 
> 
>> On Jun 4, 2019, at 8:32 AM, Quinn Stevenson > > wrote:
>> 
>> It’s been a while since I’ve implemented a route that implements JMS 
>> request-response, but if I remember correctly, you need to choose whether 
>> Camel/Spring will handle the reply or you will.
>> 
>> If you set disableReplyTo=true, Camel/Spring will send the reply using 
>> whatever is in the exchange at the end of the route (so you don’t need the 
>> “to” at the end of the route).  If you set disableReplyTo=false, then you’re 
>> responsible for taking the appropriate action with the message.
>> 
>> HTH
>> 
>> 
>>> On Jun 4, 2019, at 3:18 AM, Mariusz Kosecki >> > wrote:
>>> 
>>> Hello,
>>> My route is as follows:
>>> 
>>> from("jms:topic:T.INPUT?disableReplyTo=false")
>>> .process(requestProcessor)
>>> .unmarshal().json(JsonLibrary.Jackson, MyRequest.class)
>>> .split(messageSplitter)
>>> .process(restProcessor)
>>> .unmarshal().json(JsonLibrary.Jackson, MyResponse.class)
>>> .aggregate(messagesAggregator)
>>> .process(responseProcessor)
>>> .to("jms:topic:recipientTopic");
>>> 
>>> If I set disableReplyTo=true and convert JMSReplyTo into
>>> CamelJmsDestinationName, I get the expected result: process the request and
>>> send the response to the output topic.
>>> But I cannot comprehend why would I need to disable reply to, when in fact
>>> I want to utilise it.
>>> Currently, when disableReplyTo is set to false, I will end up a gibberish
>>> message on the output topic, which cannot be parsed and throws an exception
>>> "ClassNotFoundException: (package name).MyRequest" - it seems that camel
>>> utilises JMSReplyTo between the first unmarshal() and split(), which is
>>> unwanted as the message processing is incomplete. Is this a bug? Is this
>>> explicitly documented somewhere? Am I doing something wrong? Are there too
>>> many steps in the route? Can anyone explain?
>>> 
>>> Kind regards.
>> 
> 

camel-ftp: meaning of option "UseUserKnownHostsFile" in combination with "knownHostsUri"

[Marx, Peter]

Using Camel 2.23.2, I have provided a known_hosts file on classpath and refer 
to it in the route:

.to("sftp://user@sftpserver/out?knownHostsUri=known_hosts=privkey.pem=***;);

When running this, usage of knownHostsUri is confirmed, but after that it 
switches back to using my local user known_hosts file:
...
[06:06 13:47:08.648] [DEBUG] 
[org.apache.camel.component.file.remote.SftpOperations] - Using known hosts 
uri: known_hosts
[06:06 13:47:08.648] [INFO] 
[org.apache.camel.component.file.remote.SftpOperations] - Known host file not 
configured, using user known host file: C:\Users\marxp/.ssh/known_hosts
[06:06 13:47:08.648] [DEBUG] 
[org.apache.camel.component.file.remote.SftpOperations] - Using known hosts 
information from file: C:\Users\marxp/.ssh/known_hosts

The related code in SftpOperations.java is checking a second config setting. 
This is not only logged, but Camel is really using my user file and adding 
later the key (not shown here):
...

String knownHostsFile = sftpConfig.getKnownHostsFile();
if (knownHostsFile == null && sftpConfig.isUseUserKnownHostsFile()) {
knownHostsFile = System.getProperty("user.home") + "/.ssh/known_hosts";
LOG.info("Known host file not configured, using user known host file: {}", 
knownHostsFile);
...

I then added the "undocumented" option UseUserKnownHostsFile:


.to("sftp://user@sftpserver/out?knownHostsUri=known_hosts=false=privkey.pem=***;);


And now only the known_hosts file on classpath is used as expected:

...
[06:06 13:55:12.749] [DEBUG] 
[org.apache.camel.component.file.remote.SftpOperations] - Using private key uri 
: privkey.pem
[06:06 13:55:14.111] [DEBUG] 
[org.apache.camel.component.file.remote.SftpOperations] - Using known hosts 
uri: known_hosts
[06:06 13:55:14.119] [DEBUG] 
[org.apache.camel.component.file.remote.SftpOperations] - Using 
StrickHostKeyChecking: no
[06:06 13:55:14.280] [WARN] 
[org.apache.camel.component.file.remote.SftpOperations] - JSCH -> Permanently 
added 'sftpserver (RSA) to the list of known hosts.
...

Why do I have to add this option ? Shouldn't specifying knownHostsUri rule out 
files based stuff automatically ?

Bonus question: should the target server key be written into my prepared file ? 
 This does not happen in my target/classes/known_hosts

Peter


Knorr-Bremse Systeme für Schienenfahrzeuge GmbH
Sitz: München
Geschäftsführer: Dr. Jürgen Wilder (Vorsitzender), Mark Cleobury, Dr. Nicolas 
Lange, Dr. Peter Radina, Harald Schneider
Registergericht München, HR B 91 181

This transmission is intended solely for the addressee and contains 
confidential information.
If you are not the intended recipient, please immediately inform the sender and 
delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone 
unless agreed otherwise. To the extent permitted by law we shall in no way be 
liable for any damages, whatever their nature, arising out of transmission 
failures, viruses, external influence, delays and the like.

Re: select message via camel filter

[Andrea Cosentino]

You can find the updated documentation in github

https://github.com/apache/camel/blob/master/components/camel-jms/src/main/docs/jms-component.adoc

Il giorno gio 6 giu 2019 alle ore 09:21 James Carman <
ja...@carmanconsulting.com> ha scritto:

> Try using a JMS selector on the URI:
>
> https://camel.apache.org/jms.html
>
>
> On Thu, Jun 6, 2019 at 1:03 AM Wang Yan  wrote:
>
> > I used below example to select message.
> > although it can send matched message to toqueue
> > but not matched messages are also dequeued
> > What I want to achieve is only matched messages will be
> > selected and sent to toqueue .
> >
> > Any suggestion or hints how to do this with camel filter?
> >
> > from("activemq:queue:inputqueue?transacted=true")
> > .filter(header("foo").isEqualTo("bar"))
> > .to("activemq:queue:toqueue");
> >
>

Re: select message via camel filter

[James Carman]

Try using a JMS selector on the URI:

https://camel.apache.org/jms.html


On Thu, Jun 6, 2019 at 1:03 AM Wang Yan  wrote:

> I used below example to select message.
> although it can send matched message to toqueue
> but not matched messages are also dequeued
> What I want to achieve is only matched messages will be
> selected and sent to toqueue .
>
> Any suggestion or hints how to do this with camel filter?
>
> from("activemq:queue:inputqueue?transacted=true")
> .filter(header("foo").isEqualTo("bar"))
> .to("activemq:queue:toqueue");
>