Re: camel-aws-xray doesn't play well with XRay segments created beforehand

[Roman Vottner]

Hi Tom,

I'm the original author of that component but I have to say that I'm no
longer working for the team that initially experimented with it. Since
then our technology stack furthermore changed and we ditched AWS XRay in
our monitoring efforts completely. My current position also has hardly
any use for Apache Camel, I am therefore not actively using it at the
moment and most likely can't provide any updates. As Camel though is
open source you can modify the code to your needs and provide a PR to
the Camel. I'm sure the devs are welcoming any contributions that
improve the codebase :)

AFAIR, XRay segments are thread-local in Java. In order to "copy over" a
segment to the current thread the component supports a header property
"XRAY_TRACE_ENTITY" which will put the given XRay (sub-)segment as trace
entity in the global recorder. This way the segment should be "attached"
to the local thread and reuse the existing XRay segment trace.

I hope that this header property is what you are looking for and sorry
for probably not being more helpful here.

Kind regards,

Roman

On 09.05.2023 14:30, Tom Muldoon wrote:

Hi,

We have recently begun efforts to adopt the camel-aws-xray library as part of a 
larger AWS Xray tracing strategy. Our application initiates an Xray Segment 
within a servlet filter before delegating to Camel which, in turn, sends an SQS 
message to a consumer. Ultimately, we would like a single trace to include the 
Segment created by the servlet filter and Subsegments thereafter created by 
camel-aws-xray (in both producer and consumer of SQS messages).

With that said, camel-aws-xray and its XRayTracer class specifically does not 
seem to support use cases in which the application creates a Segment beforehand 
(as we encounter a SegmentNotFoundException when the servlet filter ultimately 
attempts to end the segment it created because camel-aws-xray overrode the 
segment with its own). Are we missing something? I feel like we must be.

Thank you, Tom


Tom Muldoon
Senior Software Architect
Copyright Clearance Center
222 Rosewood Drive
Danvers, MA 01923
1.978.646.2796
tmuld...@copyright.com
www.copyright.com

Facebook * 
Twitter * 
LinkedIn

This message (including attachments) is confidential, unless marked otherwise. 
It is intended for the addressee(s) only. If you are not an intended recipient, 
please delete it without further distribution and reply to the sender that you 
have received the message in error.

Re: Passwords in Camel endpoint URIs and limitations of RAW syntax

[Roman Vottner]

Hi Florian,

if you're concerned about logging sensitive data, I'd recommend to
configure your logging framework to filter such sensitive information in
first place as the sensitive information might otherwise leak through
other means not in control of Camel itself, i.e. as logged directly from
within a bean.

I.e. in logback you could implement a CompositeConverter
(https://github.com/RovoMe/camel-rest-dsl-with-spring-security/blob/master/src/main/java/at/rovo/awsxray/utils/MaskingConverter.java)
where you perform masking of sensitive data yourself. In the logback
configuration you then need to register the custom implementation like
this
https://github.com/RovoMe/camel-rest-dsl-with-spring-security/blob/master/src/main/resources/logback.xml#L4
and use the conversionWord within your log pattern, i.e. %mask(%msg).

As this might be a costly operation on each log, it is probably
beneficial to define when to mask sensitive data by using markers. I.e.
in the linked implementation a CONFIDENTIAL marker is created which can
also be used in a Camel log
(https://github.com/RovoMe/camel-rest-dsl-with-spring-security/blob/master/src/main/java/at/rovo/awsxray/routes/HttpInvokerRoute.java#L61)
as well.

HTH,

Roman

On 04.06.2020 10:49, Florian Patzl wrote:

Hello Ralf,
thanks for your response. No, I didn't mention that in my description. :-)
URL encoding would be my preferred solution, too, but unfortunately that does not seem to 
prevent the problems with passwords containing ")&". Unless something about my 
encoding is wrong.

For example, given a password "pwd)=b", both with and without RAW(...) the 
result is wrong:

TRACE o.a.c.i.engine.AbstractCamelContext - Getting endpoint with raw uri: 
pop3://localhost:3110/?username=test2=RAW%28pwd%29%26a%3Db%29, normalized uri: 
pop3://localhost:3110/?a=b%29=RAW(pwd)=test2

TRACE o.a.c.i.engine.AbstractCamelContext - Getting endpoint with raw uri: 
pop3://localhost:3110/?username=test2=pwd%29%26a%3Db, normalized uri: 
pop3://localhost:3110/?a=b=pwd%29=test2

I'm currently testing on 3.3.0.

Best Regards,
Florian

From: Claussnitzer, Ralf 
Sent: Thursday, June 4, 2020 08:13
To: users@camel.apache.org 
Subject: Re: Passwords in Camel endpoint URIs and limitations of RAW syntax

Hi Florian,

I may have missed the answer to my questions in your detailed problem 
description. But how is this not solved by URL-Encoding?
There was once a bug with URL encodings in Camel. Does this bug still exist? 
What version of Camel are you using?

-Ralf

From: Florian Patzl 
Sent: Wednesday, June 3, 2020 2:49 PM
To: users@camel.apache.org
Subject: Passwords in Camel endpoint URIs and limitations of RAW syntax

Hello,
I'm trying to figure out the best way to handle passwords in Camel endpoint 
URIs in my application.
I know the topic has been cause for Stack Overflow posts, JIRA entries and 
mails but I'm still not sure I've got everything right.
Sorry for the big wall of text, but I think I should explain what exactly I've 
tried and found out on the topic.

The main problem is that the reserved URI characters '+' and '&' (plus and 
ampersand) cause parsing problems in Camel endpoint URIs.
'+' is replaced by a blank, and '&' is treated as the delimiter to the next 
parameter.
An example URI for the password "pwd2+2":
pop3://localhost:3110/?username=test2=pwd2%2B2

A relevant post is here:
https://stackoverflow.com/questions/11018987/camel-how-to-include-an-ampersand-as-data-in-a-uri-not-as-a-delimiter/34926623#34926623


Now, the solution in documentation is using the RAW(...) syntax:
https://camel.apache.org/manual/latest/faq/how-do-i-configure-endpoints.html#HowdoIconfigureendpoints-Configuringparametervaluesusingrawvalues
So for example:
pop3://localhost:3110/?username=test2=RAW(pwd2+2)

Using that feature means we can no longer treat Camel URIs as pure URIs in our 
application, because the '+' of the password must not be escaped for this to 
work.
But if there's no way around that, we can deal with that.

However, when trying the limits of the RAW(...) syntax, we noticed that it can not 
parse passwords that contain ')&'.
This was covered in the following JIRA issue, and since then there is support 
for an alternative syntax using curly braces: RAW{...}, that I didn't find in 
documentation:
https://issues.apache.org/jira/browse/CAMEL-12982
The last comment provides a pretty detailed summary of the options and limits.


The alternative RAW{...} syntax works fine, except for a minor flaw: It breaks 
URI sanitizing.
For example, Camel leaks the '&2' portion of the password 'pwd2&2' in log 
entries like:
pop3://localhost:3110/?password=xx&2%7D=test2

The same problem existed for the RAW(...) syntax:
https://issues.apache.org/jira/browse/CAMEL-11269
So the fix should be rather simple, I will check whether there's already an 
issue for that and might even be able to submit a PR for that.

But, more importantly: By 

Re: Camel-jetty http/2 support

[Roman Vottner]

Jetty 9.4 does support HTTPS/2: 
https://www.eclipse.org/jetty/documentation/9.4.x/http2.html
Undertow does support it in version 2 AFAIK: 
http://undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html

Roman Vottner

—

ecosio GmbH
Lange Gasse 30, 1080 Vienna, Austria/Europe
Mail: roman.vott...@ecosio.com <mailto:christoph@ecosio.com>
T: +43 1 996 2106-0 , F: +43 1 996 2106-99 

UID: ATU68241501, FBNR: FN 405017 p, Handelsgericht Wien
Geschäftsführer: Christoph Ebm, Philipp Liegl, Marco Zapletal
Web: http://ecosio.com <http://ecosio.com/>, Blog: http://ecosio.com/blog 
<http://ecosio.com/blog>, Newsletter <http://ecosio.com/de/newsletter/>

> Am 21.01.2019 um 16:37 schrieb Claus Ibsen :
> 
> Hi
> 
> I suggest to see if you can find details on Jetty about their HTTP2
> support and then see what it takes. Maybe some extra JARs on the
> classpath and what it takes to configure jetty server for that, and
> see what is possible to do in camel-jetty if we can get this
> supported.
> 
> There is also undertow as another http server and its maybe a
> component that are more modern than jetty and something you can also
> look at about its http2 support and if/what it takes for
> camel-undertow to support it.
> 
> And you are also welcome to log JIRA tickets for these enhancements.
> 
> On Tue, Jan 15, 2019 at 2:34 AM Adam Smith
>  wrote:
>> 
>> Dear Camel,
>> 
>> Do you support HTTP/2 with Camel-Jetty or plan too in the future? If anyone 
>> has already done so, would really appreciate if you could send me some 
>> information.
>> 
>> Many thanks
>> Adam
>> Adam Smith | Senior Pre-Sales Consultant | Interlink Software Services 
>> Limited | Office: +44 (0) 161 486 3213 | Mobile: 07860375785 | 
>> www.interlinksoftware.com
>> adam.sm...@interlinksoftware.com
>> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Jetty consumer responds with a 500 error java.io.IOException: Response header too large

[Roman Vottner]

Do you somehow store the received file into camel headers? Camel will 
return most headers to the invoker and usually HTTP headers > 8kb will 
produce that kind of exception.


You might want to introduce a customized HttpHeaderFilterStrategy 
similar to the sample below to avoid returning certain headers.


import org.apache.camel.Exchange;
import org.apache.camel.http.common.HttpHeaderFilterStrategy;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.lang.invoke.MethodHandles;
import java.util.Arrays;
import java.util.List;

public class CustomHeaderFilterStrategy extends HttpHeaderFilterStrategy {

  private final static Logger LOG = 
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
  private boolean debugLog = false;

  protected List queryParamsToFilter = Arrays.asList("appKey", "limit", "offset", 
"filter");
  protected List otherParamsToFilter =
  Arrays.asList("breadcrumbId", "User-Agent", "NewRelicID", 
"NewRelicTransaction",
"Transfer-Encoding", "Authorization", "Accept",
"HttpResponseContent", "TLS_PROTOCOL_VERSION", 
"TLS_CIPHER_SUITE");

  public CustomHeaderFilterStrategy() {

  }

  public CustomHeaderFilterStrategy(boolean debugLog) {
this.debugLog = debugLog;
  }

  // outgoing headers
  @Override
  public boolean applyFilterToCamelHeaders(String headerName, Object 
headerValue,
   Exchange exchange) {

// do not copy Camel specific headers from the Camel exchange to the out 
headers
if (super.applyFilterToCamelHeaders(headerName, headerValue, exchange)) {
  if (debugLog) {
LOG.debug("Filtered header {} through HTTP header filter", headerName);
  }
  return true;
}

// do not copy SAMPLE_* headers from the Camel exchange to the out headers
if (headerName.startsWith("SAMPLE_")) {
  if (debugLog) {
LOG.debug("Filtering header {}", headerName);
  }
  return true;
}
if (headerName.startsWith("JMS")) {
  if (debugLog) {
LOG.debug("Filtering header {}", headerName);
  }
  return true;
}
if (queryParamsToFilter.contains(headerName)) {
  if (debugLog) {
LOG.debug("Filtering header {}", headerName);
  }
  return true;
}
if (otherParamsToFilter.contains(headerName)) {
  if (debugLog) {
LOG.debug("Filtering header: {}", headerName);
  }
  return true;
}

if (debugLog) {
  LOG.debug("Outgoing header passed: {} - value: {}", headerName, 
headerValue);
}
return false;
  }

  // incoming headers
  @Override
  public boolean applyFilterToExternalHeaders(String headerName, Object 
headerValue,
  Exchange exchange) {
// allow all headers to be copied from the request to camel headers
return false;
  }
}

You can utilize this custom header filter by appending 
?headerFilterStrategy=#refNameOfFilterStrategy to the route specifying 
the Jetty consumer, where "refNameOfFilterStrategy" is the name you 
register the class above with Camel (or Spring).


This thread 
(https://stackoverflow.com/questions/17550471/camel-jetty-component-custom-header-filter-strategy) 
also states that you may customize the DefaultHttpBinding, though I'd 
try the primer solution first.


HTH,

Roman

Am 20.12.2017 um 09:42 schrieb Laurentiu Trica:

Camel version: 2.16.3

Thanks!

On Tue, Dec 19, 2017 at 6:27 PM, Andrea Cosentino <
ancosen1...@yahoo.com.invalid> wrote:


What version of camel are you using?

Inviato da Yahoo Mail su Android

   Il mar, 19 dic, 2017 alle 16:45, Laurentiu Trica ha scritto:   Hello,

I have a problem with the Jetty consumer. I receive a file with an attached
file (Multi-Part Form), but if the file is bigger than a few KB, I get the
bellow Stack trace. If the file is smaller, everything works fine.

The strange part is that for a size of 80KB I still receive the file in the
route, but the response to the HTTP client is:
HTTP/1.1 500 Server Error
Connection: close
Server: Jetty(9.2.14.v20151106)

If the file's size is, let's say, 2 MB, then the route doesn't get the file
anymore and the response to the client is the same.

I tried to set the request/response buffers to bigger values, but it didn't
help:
http://0.0.0.0:9086/Test?responseHeaderSize=32768000;
responseBufferSize=32768000=32768000&
requestHeaderSize=32768000
"/>

Any ideas? Can you please help?

*Stack trace:*
2017-12-19 16:33:02,802 | WARN  | tp466415455-3362 | ServletHandler
   | 119 - org.eclipse.jetty.util - 9.2.14.v20151106 | /Test
java.io.IOException: Response header too large
at
org.eclipse.jetty.http.HttpGenerator.generateResponse(
HttpGenerator.java:400)[107:org.eclipse.jetty.http:9.2.14.v20151106]
at
org.eclipse.jetty.server.HttpConnection$SendCallback.
process(HttpConnection.java:655)[116:org.eclipse.jetty.
server:9.2.14.v20151106]
at

Re: difference on seda versus threads usage

[Roman Vottner]

To my knowledge the latter one will create a new exchange for each seda invoked 
route and copy over the data from the origin exchange while the primer one will 
just create threads within an executor service (no new exchange creation) and 
thus use the same exchange. 

You might see a difference if you put stuff within your thread-logic onto the 
exchange. Seda provides a (somehow) thread-local usage of the exchange while 
threads maintains a more global usage of the exchange. In seda each thread 
should have its local state on the exchange without seeing/interfering the data 
from other threads while on using threads will probably replace exchange 
properties and similar stuff.

Hope my understanding is correct though ...

> Am 25.10.2017 um 01:35 schrieb Robson Vargas Farias 
> :
> 
> small correction on the bench code:
> 
> 
> 
> 
>  
> 
> 
> versus
> 
> 
>  uri="seda:in?concurrentConsumers=20"/>
>
> 
> 
> 2017-10-24 21:34 GMT-02:00 Robson Vargas Farias <
> robsonvargasfar...@gmail.com>:
> 
>> I'm trying to figure out the real world usage on both asynchronous
>> options... even trying to fit a way where I could mix ... but not sure
>> whether this makes sense...
>> 
>> so, the question is, what's the basic difference using one or another,
>> like:
>> 
>> 
>> 
>>  
>> 
>> 
>> versus
>> 
>> 
>>  >uri="seda:in=20"/>
>>
>> 
>> 
>> 
>> 

Re: Send messages to remote SSL/TLSv1.2 enabled rest endpoints?

[Roman Vottner]

Are you attempting an SSL connection with a self-signed certificate? I guess 
the server endpoints are working fine via https if accessed via a browser? 

You should follow this guide 
(https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html
 
)
 which suggests to add "-Djavax.net .debug=all" as startup 
argument to your server startup in order to enable debug tracing for SSL 
connections. If you see something like „null cert chain“ in the log on 
attempting to connect to the server and also something like „found key for : 
server chain [0] = [ … ]“ you should check what the server is expecting here. 
Probably the client keystone doesn’t contain the cert the server is expecting 
(further reading: 
https://stackoverflow.com/questions/4421536/java-ssl-clientside-authentication-with-self-signed-certificates
 
).
 As you provide the key- and truststore data via javax.net.ssl properties, keep 
in mind that these are only used if a default SSL context is used (as EJP 
mentioned in a comment) but not if one is constructed via getInstance().

> Am 23.10.2017 um 14:18 schrieb Steve973 [via Camel] 
> :
> 
> Hello.  I asked a similar question on Friday, but I do not think that I was 
> specific enough about what I am intending to do.  I am using camel 2.19.2, 
> and I am currently attempting to use the http4 component.  In my pom, I am 
> including camel-spring-boot-starter, camel-http4, and camel-gson 
> 
> I am writing a Spring Boot messaging service so that deployed services can 
> register to receive certain message types that other services would 
> publish.  Interested services would register for a message type with the 
> messaging service by providing a REST url that the message service can use 
> by posting the message to it. 
> 
> My route is currently configured as follows: 
> 
> from("vm:messageStart") 
> .routeId("messageStart") 
> .process(messageSubscriberListHeaderProcessor) 
> .marshal().json(JsonLibrary.Gson) 
> .recipientList(header("messageSubscriberList")) 
> .delimiter(",") 
> .parallelProcessing(); 
> 
> The processor gets a list of REST URLs from a repository that has that 
> information: 
> 
> @Override 
> public void process(Exchange exchange) throws Exception { 
> Message in = exchange.getIn(); 
> MyMessage message = in.getBody(MyMessage.class); 
> MessageType messageType = message.getMessageType(); 
> String messageSubscriberList = repository 
> .findOne(messageType) 
> .getSubscriberUris() 
> .stream() 
> .map(uri -> uri.replace("https:", "https4:")) 
> .map(uri -> uri.replace("http:", "http4:")) 
> .map(uri -> uri.concat("?useSystemProperties=true")) 
> .collect(Collectors.joining(",")); 
> in.setHeader("messageSubscriberList", messageSubscriberList) 
> } 
> 
> When I deploy the app to tomcat, tomcat has the system properties for all 
> of the relevant javax.net.ssl.-prefixed properties: trustStore, 
> trustStorePassword, trustStoreType, keyStore, keyStorePassword, 
> keyStorePasswordType.  When I try to use my "/publish" endpoint to send a 
> message to "vm:messageStart", and when it attempts to send the message to 
> the recipient list, I get the same error for each recipient: 
> "javax.net.ssl.SSLHandshakeException: Received fatal alert: 
> bad_certificate". 
> 
> Note that for the purposes of testing, I also have the messaging service 
> listening to the following rest endpoints: /rest/1, /rest/2, and /rest/3. 
> The subscriber list contains the urls: https://server_host:8443/rest/1 
> , 
> https://server_host:8443/rest/2 , and 
> https://server_host:8443/rest/3 .  So 
> it isn't a matter of one server being configured with one trust store and 
> another server being configured with a different trust store.  This is a 
> service trying to post data to its own endpoints. 
> 
> Does anyone have some idea about how I have configured this incorrectly? 
> Thanks in advance for any insight that anyone can provide. 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://camel.465427.n5.nabble.com/Send-messages-to-remote-SSL-TLSv1-2-enabled-rest-endpoints-tp5814765.html
>  
> 
> To unsubscribe from Camel - Users, click here 
> .
> NAML 
> 

Re: http4 component with spring boot to configure ssl parameters

[Roman Vottner]

Hi Steve,

you basically have to define some SSLContextParameters and add them to your 
HttpComponent as hopefully can be seen in the URL below

https://github.com/RovoMe/camel-rest-dsl-with-spring-security/blob/master/src/main/java/at/rovo/awsxray/config/HttpClientSpringConfig.java
 


Note that this project is just a playground to test out things and may thus 
change frequently. Don’t get distracted by the custom HttpComponent being 
created at the bottom, I currently work on an AWS XRay support in Camel 
(similar to OpenTracing) and thus need the HttpClientBuilder from AWS rather 
than the Apache Commons HttpClientBuilder.

A sample configuration of the SSLContextParameters which only defines a 
keystone (truststore is analog to this) can be seen here: 
https://github.com/RovoMe/camel-rest-dsl-with-spring-security/blob/master/src/main/java/at/rovo/awsxray/config/SSLContextConfig.java
 

 As this configuration is used for Jetty actually, wich does not support 
TLSv1/1.1 since version 9.3 anymore due to a lack of secure ciphers, the 
majority of lines in this configuration are used to add TLSv1/1.1 support, 
which will become obsolete hopefully once Camel 2.19.4 or 2.20.1 (?) will be 
released.

HTH,
Roman

> Am 20.10.2017 um 18:52 schrieb Steve973 [via Camel] 
> :
> 
> Hello.  I'm trying to figure out how to set up the http4 component with ssl 
> information (keystore, truststore) with Spring Boot.  I would like to have 
> a @Configuration class that configures the "https4" component, but I cannot 
> find examples.  Do any of you know of an example that I could look at? 
> 
> Thanks, 
> Steve 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://camel.465427.n5.nabble.com/http4-component-with-spring-boot-to-configure-ssl-parameters-tp5814739.html
>  
> 
> To unsubscribe from Camel - Users, click here 
> .
> NAML 
> 

Re: REST DSL process multipart/form-data binary file?

[Roman Vottner]

How do you send data to your application? Have you specified a 
Content-Disposition header for the respective parts?

We analysed a raw request via wireshark and it does look something like this:

GET /api/someResource HTTP/1.1
Host: www.somewhere.com <http://www.somewhere.com/>
…
Content-Type: multipart/form-data; 
boundary=d9c950f09cd11bba

--d9c950f09cd11bba
Content-Disposition: form-data; name="dat1"; filename=„SomeFile.zip"
Content-Type: application/octet-stream

…

--d9c950f09cd11bba
Content-Disposition: form-data; name="dat2"; filename=„SomeOtherFile.zip"
Content-Type: application/octet-stream

…


We use Camel 2.19.0 and the Undertow version Camel (camel-undertow-starter) 
and/or Spring-Boot (spring-boot-starter-undertow) includes their dependencies 
(undertow 1.4.13.FINAL). 


> Am 02.10.2017 um 04:25 schrieb Mark Webb [via Camel] 
> <ml+s465427n5814065...@n5.nabble.com>:
> 
> Thanks for the example.  I cannot get your code working though.  I get the 
> following: 
> 
> [qtp1422312468-17] HandleUpload   INFO  Upload received 
> [ qtp1422312468-17] HandleUpload   INFO  Exchange body: 
> org.apache.camel.converter.stream.InputStreamCache@1cf48789 
> [qtp1422312468-17] HandleUpload   INFO  Attachment size: 0 
> [qtp1422312468-17] HandleUpload   INFO  Attachment object 
> size: 0 
> [qtp1422312468-17] HandleUpload   WARN  No attachments 
> found! 
> 
> I am testing with the Postman app in the Chrome Browser and using Jetty. 
> I'm using Camel 2.16.2, since we're deploying in ServiceMix.   I tried 
> testing with Camel 2.19.3 and observed the same problem so I don't think a 
> newer version of Camel fixes things.  What environment are you running your 
> code inside? 
> 
> 
> 
> 
> 
> On Sat, Sep 30, 2017 at 9:13 PM, Roman Vottner <[hidden email] 
> > wrote: 
> 
> > Our Camel REST DSL configuration looks like this: 
> > 
> > onException(Exception.class) 
> > .handled(true) 
> > .logExhausted(false) 
> > .log(LoggingLevel.ERROR, ">> In default/message exception handler. 
> > ${exception}, message: ${exception.message}, stacktrace: 
> > ${exception.stacktrace}") 
> > .onRedelivery((Exchange exchange) -> LOG.debug(">> Default 
> > exception handler")) 
> > .bean(PrepareErrorResponse.class).id("ErrorResponse") 
> > .end(); 
> > 
> > restConfiguration() 
> > .component("undertow") 
> > .port("{{server.port}}") 
> > .contextPath("/api") 
> > .endpointProperty("matchOnUriPrefix", "true") 
> > .endpointProperty("sendServerVersion", "false") 
> > .endpointProperty("chunked", "true"); 
> > 
> > where the actual route handling the multipart-request does look something 
> > along the line: 
> > 
> > rest("/someEndpoint") 
> > .post("/{id}") 
> > .consumes(MediaType.MULTIPART_FORM_DATA_VALUE) 
> > .route().routeId("upload-multipart-route") 
> >   // Spring Security authentication check via Authorization header 
> >   .bean(SpringSecurityContextLoader.class) 
> >   .policy(authorizationPolicy) 
> >   .log("Uploading to resource id ${header.id}") 
> >   .log(LoggingLevel.INFO, LOG, CONFIDENTIAL,"Headers: ${headers}") 
> >   .bean(HandleUpload.class) 
> >   .process((Exchange exchange) -> { 
> > exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 200); 
> > exchange.getIn().setHeader(Exchange.CONTENT_TYPE, 
> > MediaType.APPLICATION_JSON_UTF8_VALUE); 
> > ... 
> >   }) 
> > .endRest(); 
> > 
> > and the HandleUpload class looking something like this: 
> > 
> > public class HandleUpload { 
> > 
> >   private static final Logger LOG = LoggerFactory.getLogger(Method 
> > Handles.lookup().lookupClass()); 
> > 
> >   @Autowired 
> >   private SomeRepository someRepository; 
> > 
> >   @Handler 
> >   public void processUpload(@Attachments Map<String, DataHandler> 
> > attachments, 
> > @Header("Content-Type") String contentType, 
> > @Header("id") String id, 
> > Excha

Re: REST DSL process multipart/form-data binary file?

[Roman Vottner]

Our Camel REST DSL configuration looks like this:

onException(Exception.class)
.handled(true)
.logExhausted(false)
.log(LoggingLevel.ERROR, ">> In default/message exception 
handler. ${exception}, message: ${exception.message}, stacktrace: 
${exception.stacktrace}")
.onRedelivery((Exchange exchange) -> LOG.debug(">> Default 
exception handler"))

.bean(PrepareErrorResponse.class).id("ErrorResponse")
.end();

restConfiguration()
.component("undertow")
.port("{{server.port}}")
.contextPath("/api")
.endpointProperty("matchOnUriPrefix", "true")
.endpointProperty("sendServerVersion", "false")
.endpointProperty("chunked", "true");

where the actual route handling the multipart-request does look 
something along the line:


rest("/someEndpoint")
.post("/{id}")
.consumes(MediaType.MULTIPART_FORM_DATA_VALUE)
.route().routeId("upload-multipart-route")
  // Spring Security authentication check via Authorization header
  .bean(SpringSecurityContextLoader.class)
  .policy(authorizationPolicy)
  .log("Uploading to resource id ${header.id}")
  .log(LoggingLevel.INFO, LOG, CONFIDENTIAL,"Headers: ${headers}")
  .bean(HandleUpload.class)
  .process((Exchange exchange) -> {
exchange.getIn().setHeader(Exchange.HTTP_RESPONSE_CODE, 200);
exchange.getIn().setHeader(Exchange.CONTENT_TYPE, 
MediaType.APPLICATION_JSON_UTF8_VALUE);

...
  })
.endRest();

and the HandleUpload class looking something like this:

public class HandleUpload {

  private static final Logger LOG = 
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());


  @Autowired
  private SomeRepository someRepository;

  @Handler
  public void processUpload(@Attachments Map 
attachments,

@Header("Content-Type") String contentType,
@Header("id") String id,
Exchange exchange)
  throws Exception {
LOG.info("Upload received");

LOG.info("Exchange body: " + exchange.getIn().getBody());
LOG.info("Attachment size: " + (attachments == null ? 0 : 
attachments.size()));
LOG.info("Attachment object size: " + 
(exchange.getIn().getAttachmentObjects() == null ? 0

: exchange.getIn().getAttachmentObjects().size()));
if (exchange.getIn().getAttachmentNames() != null) {
  for (String name : exchange.getIn().getAttachmentNames()) {
LOG.info("Attachment name: " + name);
  }
}

if (contentType == null || 
!contentType.startsWith(MediaType.MULTIPART_FORM_DATA_VALUE)) {

  LOG.warn("Unsupported media type!");
  throw new UnSupportedUploadMediaTypeException("Content-Type has 
to be 'multipart/form-data'");

}

if (attachments.size() == 0) {
  LOG.warn("No attachments found!");
} else {
  for (String key : attachments.keys()) {
LOG.info("Filename: " + key);

String uploadKey = id + "_" + new 
Date().toInstant().toEpochMilli() + "_" +

attachments.get(key).getDataSource().getName();

// stream data directly to a file to save memory footprint
File targetFile = new File(uploadKey);
try (OutputStream outStream = new FileOutputStream(targetFile, 
false)) {

attachments.get(key).writeTo(outStream);
}

...
  }
}

...
  }
}

Although we currently test Undertow, switching it with Jetty shouldn't 
be an issue.


HTH,
roman


Am 01.10.2017 um 02:18 schrieb Mark:

I understand that, problem is that I can't figure out how to configure the
Camel Route to properly receive/parse the data.  If I was receiving
JSON/KML, this would be easy using the functionality in Camel.  Binary
files seem to be totally different.


On Sat, Sep 30, 2017 at 8:13 PM, Mark Nuttall  wrote:


it is just a file. any example of processing a file should work.  you will
be able to save it somewhere and then you will have to call some processor
to read/process it.

On Fri, Sep 29, 2017 at 7:47 PM, Mark  wrote:


I'm trying to figure out how to process a binary file that is sent to my
Camel REST service via POST.  I have not found any good examples on how
this can be done using Camel.  Does anyone have any experiences they

could

share or links to more documentation?

I'm currently using the jetty component for the restconfiguration.

Thanks,
Mark

Add ServletFilter to invoked Jetty component

[Roman Vottner]

I’ve pushed a sample test application onto github 
(https://github.com/RovoMe/camel-rest-dsl-with-spring-security 
) where I want 
to integrate AWS XRay servlet filter for any inbound or outbound traffic. 
Spring Security offers the WebSecurityConfigurerAdapter as web.xml replacement 
where you can define security policies on certain endpoints using the 
configure(HttpSecurity) method. This also allows to add custom servlet filters 
via addFilterBefore or addFilterAfter.

However, the current approach Camel uses ist to declare security on routes via 
SpringSecurityAuthrizationPolicy, which also requires a bean prior to the 
declared policy which actually sets the Authentication object in the headers 
(i.e. 
https://github.com/RovoMe/camel-rest-dsl-with-spring-security/blob/master/src/main/java/at/rovo/awsxray/routes/api/SampleFileRoute.java#L42-L43
 
).
 This approach does not use a web.xml (or its Java based configuration) and 
thus does not invoke any of the filters defined in the 
web.xml/WebSecurityConfigurerAdapter if a Jetty endpoint exposed via the REST 
DSL is invoked, even though the beans and filters are initialised at startup.

Is there a way to add a custom servlet filters to Camel routes exposed via REST 
DSL/Jetty or define the security policies via the Spring Security approach 
similar to 
https://github.com/RovoMe/camel-rest-dsl-with-spring-security/blob/master/src/main/java/at/rovo/awsxray/config/SpringSecurityConfig.java#L67-L72
 

 directly?

Re: A lot of spam

[Roman Vottner]

So what to use instead? Github issues? Stackoverflow posts?

Shouldn’t this be communicated to users and eventually also lead to a shutdown 
of Camel’s nabble mailing list?


> Am 21.08.2017 um 23:51 schrieb Claus Ibsen :
> 
> Yes we have given up on nabble - do not use it.
> 
> On Mon, Aug 21, 2017 at 1:13 PM, souciance
>  wrote:
>> Hello,
>> 
>> I do receive quit a bit of spam mail from Camel nabble. Is it just me or
>> does everyone else receive nabble mail promoting marriage in India?
>> 
>> Best
>> Souciance
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://camel.465427.n5.nabble.com/A-lot-of-spam-tp5811575.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: 2.19.0 Jetty:Https javax.net.ssl.SSLHandshakeException: no cipher suites in common

[Roman Vottner]

Hi,

Camel 2.19.0 upgraded its Jetty9 version to 9.3.x which only supports TLSv1.2 
out of the box. As all ciphers used for TLSv1 (and TLSv1.1) are considered 
unsafe they get blocked by Jetty9 now and hence no ciphers are available in 
case of TLSv1 or TLSv1.1. connection attempts. (See 
https://github.com/eclipse/jetty.project/issues/860 for more information).

According to the Jetty SSL configuration documentation 
(https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html) this 
can be prevented on setting a custom excludeCipherSuites policy. However, Camel 
seems to not push this settings to the SslContextFactory. I.e. we specify 

FilterParameters filter = new FilterParameters();
filter.getInclude().add(".*");
List exclusions = filter.getExclude();
exclusions.add("^.*_(MD5|SHA1)$");
scp.setCipherSuitesFilter(filter);

inside our SSLContextParameters setup, though through debugging we learned that 
the SslContextFactory still has the default exclusion pattern 
„^.*_(MD5|SHA|SHA1)$“ which prevents using TLSv1 or TLSv1.1 compatible ciphers 
and therefore prevents connections from these protocols.

We currently subclassed JettyHttpComponent and specified the exclusion cipher 
suites manually, which solves the TLSv1/1.1 connection issue:

  /**
   * A custom jetty http component which explicitly sets the 
excludedCipherSuites during creation of the jetty connector.
   *
   * Why? It seems camel does not push included/excluded cipherSuites from 
{@link SSLContextParameters} to the 
   * {@link SslContextFactory} nor does push explicitly listed cipher suites 
(i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to 
   * the Jetty SSL context factory.
   *
   * @see https://github.com/ecosio/issues/issues/1810
   */
  public static class HackedJettyHttpComponent extends JettyHttpComponent9 {

@Override
protected AbstractConnector createConnectorJettyInternal(Server server, 
JettyHttpEndpoint endpoint,
 SslContextFactory 
sslcf) {

  sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
  return super.createConnectorJettyInternal(server, endpoint, sslcf);
}
  }

Once we added this custom JettyHttpComponent we were able to connect via TLSv1 
or TLSv1.1 again. (i.e. curl -v -XGET —tlsv1.0 
https://localhost:443/api/v1/someResource). Also sslscan localhost:443 listed 
all available cipher suites.

So, basically this seems to be a bug in the JettyHttpComponent not copying the 
defined filters or parameters properly to the SslContextFactory.

HTH,
Roman


> Am 23.05.2017 um 00:14 schrieb Thomas Freihalter 
> :
> 
> Hello 
> I am using Camel 2.19.0 (on Karaf 4.1.1 with Jetty9)
> 
> My route is
>  uri="jetty:https://0.0.0.0:4711?matchOnUriPrefix=truesslContextParametersRef=sslContextParameters"/>
> .
> 
> When I try to access the URL with my browser I get:
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> 
> I found this Bug-Report:
> https://issues.apache.org/jira/browse/CAMEL-10628
> 
> Is this Bug still not fixed?
> Does a workaround for 2.19.0 exists?
> (2.17.3 with jetty8 works okay)
> 
> Regards
> Thomas
> 
> 
> 
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/2-19-0-Jetty-Https-javax-net-ssl-SSLHandshakeException-no-cipher-suites-in-common-tp5800043.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Testing rainy-cases of consumers consuming in an own thread

[Roman Vottner]

We have a custom Camel component named CamelRedisSeda which basically is an 
extension of UriEndpointComponent, which pops items from or pushes items to a 
Redis queue. For testing both Redis client and the connection are mocked and 
use a blocking queue in the back as Redis queue replacement.

I test the consumer of the component using the ConsumerTemplate like this:

@Test
public void testRedisSedaConsumerForMultipleAvailableMessages() throws 
Exception {

  String queueName = "redis-seda:q1";
  RedisConnection con =
  redisClient.connect(new ObjectCodec());
  con.rpush(queueName,
new RedisSedaPayload("test"),
new RedisSedaPayload("test2"),
new RedisSedaPayload("test3"));

  ConsumerTemplate consumerTemplate = consumer();
  String body = 
consumerTemplate.receiveBody("redis-seda://q1?redisClient=#redisClient", 500, 
String.class);
  String body2 = 
consumerTemplate.receiveBody("redis-seda://q1?redisClient=#redisClient", 500, 
String.class);
  String body3 = 
consumerTemplate.receiveBody("redis-seda://q1?redisClient=#redisClient", 500, 
String.class);
  String body4 = 
consumerTemplate.receiveBody("redis-seda://q1?redisClient=#redisClient", 500, 
String.class);

  assertThat(body, is(equalTo("test")));
  assertThat(body2, is(equalTo("test2")));
  assertThat(body3, is(equalTo("test3")));
  assertThat(body4, is(nullValue()));
}

which works quite well. Though, we noticed while patching one of our servers 
recently, which also required a restart, that one of our messages got lost 
during the restart. To test this behavior I wanted to create a test case which 
fills the mocked queue with plenty of messages and shut down the camel context 
while the consumer pops messages from the queue.

Basically the test first creates 1000 entries which the consumer should create. 
I then create a worker thread which stops the context (and the consumer) after 
the 5th message was processed. Each pop is currently mocked with a slight sleep 
delay so that the whole tests needs a couple of seconds and the shutdown thread 
has a chance to perform its task.

  @Test
  public void testCamelShutdownWhileConsumingMessages() throws Exception {
int maxItems = 1000;
String queueName = "redis-seda:q1";
RedisConnection con =
redisClient.connect(new ObjectCodec());
for (int i=1; i

Log raw requests and responses received via a Jetty endpoint

[Roman Vottner]

We run a couple of Jetty servers through Camel and are curious if Camel 
provides any built-in facilities to log the raw HTTP request and also the 
response. We’d like an output similar to the one of an Apache HTTP Client (log 
messages for org.apache.http.wire) where an output may look like this:

2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "POST /api/v1/someEndpoint 
HTTP/1.1[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "Content-Type: 
application/json[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "Content-Length: 
1030[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "Host: 
localhost:8393[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "Connection: 
Keep-Alive[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "User-Agent: 
Apache-HttpClient/4.4 (Java 1.5 minimum; Java/1.8.0_66)[\r][\n]" [o.a.h.wire] 
[Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "Accept-Encoding: 
gzip,deflate[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "Authorization: ...[\r][\n]" 
[o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "[\r][\n]" [o.a.h.wire] 
[Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 >> "{"message“:“..."}" 
[o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "HTTP/1.1 200 OK[\r][\n]" 
[o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "Content-Type: 
application/json; charset=utf-8[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "Transfer-Encoding: 
chunked[\r][\n]" [o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "[\r][\n]" [o.a.h.wire] 
[Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "34[\r][\n]" [o.a.h.wire] 
[Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "{"messageId“:“..."}" 
[o.a.h.wire] [Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "[\r][\n]" [o.a.h.wire] 
[Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "0[\r][\n]" [o.a.h.wire] 
[Console] 
2016-04-14 14:57:27 - [DEBUG] - http-outgoing-1 << "[\r][\n]" [o.a.h.wire] 
[Console] 

We use SLF4J/Logback for logging and stumbled over the logback-access library 
(http://logback.qos.ch/access.html#teeFilter) which seem to provide the 
functionality we are looking for already though I am not really able to get the 
TeeFilter (ServletFilter) for a JettyComponent(9) to work. We do not have any 
web.xml configs or the like as we use Camels Rest DSL over Jetty. 

Our configuration does look like this:

Spring Config:
--

@Configuration
public class ServicesSpringConfig extends CamelConfiguration {

  @Override
  protected void setupCamelContext(CamelContext camelContext) throws Exception {
...
camelContext.addComponent("jetty", jettyHttpComponent());
  }

  @private JettyHttpComponent jettyHttpComponent() throws URISyntaxException {
JettyHttpComponent jetty = new JettyHttpComponent9();
jetty.setSslContextParameters(sslContextParameters());
jetty.setErrorHandler(new SuppressJettyInfoErrorHandler());
return jetty;
  }

  @Bean(name = "jettyRawRequestResponseLogger")
  public TeeFilter jettyRawRequestResponseLogger() {
return new TeeFilter();
  }
}

Rest DSL:
-

restConfiguration()
.component("jetty")
.scheme("https")
.host("0.0.0.0")
.port("{{rest.port}}")
.contextPath("/api/v1")
.endpointProperty("matchOnUriPrefix", "true")
.endpointProperty("sendServerVersion", "false")
// we do want to make use of the streaming API which sends out the response 
in small chunks
// instead of all at once. This, however, will replace the Content-Length 
header field with
// a Transfer-Encoding: chunked header field. A chunk length of 0 indicates 
the end of the
// stream
.endpointProperty("chunked", "true")
.endpointProperty("headerFilterStrategy", „#customHeaderFilter")
.endpointProperty("filterRef", "#jettyRawRequestResponseLogger“);

How do I have to add the TeeFilter servlet filter to the Jetty component in 
order to log in- and outgoing messages as filterRef does not work in my case? 

Thanks for any help you can provide

Validation on build time of camel component fails when component has some getter/setters

[Roman Vottner]

Hi there,

we use Camel 2.16.0 and are currently developing a Camel component and on 
trying to build an artifact using „mvn clean install“ or „mvn clean package“ 
the build fails due to: Missing component documentation for the following 
options: … as the component class defines a getter and setter for a property 
with @UriEndpoint and other documentation enabled in Endpoint and Configuration 
classes. If the getter/setter is removed from the component class and the value 
assignment moved to a customized constructor the build succeeds. Putting a 
@UriParam (or similar) annotation on the component property does not solve the 
problem and specifying an @Uri… annotation on the getter/setter does not work 
either as they are restricted to fields or classes.

Is validation considered working as intended as components should not define 
getter/setter and therefore properties or is this a bug?

Re: Rest DSL with jetty and SSL

[Roman Vottner]

I've had similar problems
(http://camel.465427.n5.nabble.com/Rest-DSL-how-to-configure-SSL-Basic-Auth-for-Jetty-component-td5758003.html)
and therefore created a github project
(https://github.com/RovoMe/CamelMultipleJettyComponents/tree/rest-dsl) to
test Camel's REST-DSL with SSL/Basic Auth configured for a Jetty Server. 

There are currently a couple of issues to keep in mind:

1) On specifying a security handler (for basic auth), this handler must be
added only once to a route! This has a short mentioning in the component
docs - but may be skiped easily! This was somehow no issue before Camel
2.14.0.
(http://camel.465427.n5.nabble.com/Issue-using-multiple-services-broadcast-via-JettyComponent-td5757958.html)
2) Setting a security handler via .componentProperty(handler,
springBeanNameOfSecurityHandler) ignores the handler and therefore wont
even ask for the user credentials.
3) Having multiple HTTP operations defined within the same route and a
security handler defined via .endpointProperty(handlers,
springBeanNameOfSecurityHandler) will try to initialize the handler for
each HTTP operation and therefore yield the problem described in 1)
4) I still have no clue on how to directly add a handler to the
JettyHttpComponent to avoid these multiple additions problem (which
furthermore does raise some unclear exception)

The example project linked above contains 3 route-classes: the first two
route classes simply define a Jetty endpoint via the services.properties
where the first route declares a basic authentication handler for Jetty
which is simply added via ...handlers=#jettyAuthHandler... to the
endpoint. As this handler is only allowed to be added once for the same port
the other routes must not add this handler. 

Route3 defines a REST route using Camels REST-DSL. Post and Delete
operations are currently disabled as they only work if the handlers endpoint
property configuration in Route3 is removed. You can though achieve global
basic auth handling by activating route1 (but still disable the endpoint
property specifications for handlers in Route3)

Currently the first two routes are disabled. To enable them simply remove
the comment declaration from ServicesSpringConfig. On enabling route1 make
sure to comment out the .endpointProperty(handlers, jettyAuthHandler)
specification in Route3.

This project still lacks proper unit-tests, but you can test the behavior if
you simply run ServicesApp as a console application and point your browser
to https://localhost:8383/api/v1/serviceN where N should be replace by 1, 2
or 3 depending on which services you have enabled. If you have enabled the
basic auth handler you should be asked for user credentials (user=admin;
pw=secret)

Hope this helps and Claus or Willem can have a look at those issues



--
View this message in context: 
http://camel.465427.n5.nabble.com/Rest-DSL-with-jetty-and-SSL-tp5767572p5767688.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Rest DSL - how to configure SSL/Basic Auth for jetty component?

[Roman Vottner]

Thank you Claus for your input so far. I’ve updated the branch according to 
your suggestions 
(https://github.com/RovoMe/CamelMultipleJettyComponents/tree/rest-dsl) and 
solved the SSL issue therefore. However, on trying to include basic auth using 
the custom basic auth security handler I run into a StackOverflowException 
again (similar to the problem reported on 5. november, „StackOverflowError on 
configuring JettyHttpComponents with handlers for the same port“).

The configuration of the basic auth handler is not that different from your 
unit-test 
(https://svn.apache.org/repos/asf/camel/trunk/components/camel-jetty/src/test/java/org/apache/camel/component/jetty/HttpBasicAuthTest.java).
 Instead of registering the handler via a JNDI registry, Spring takes care of 
it. The service is also able to find the handler but fails after the handler 
finished his work. I had furthermore no success in finding a proper method in 
JettyHttpComponent to specify the handlers itself to avoid specifications of 
multiple handlers (although they all should be the same) for endpoints 
listening on the same port.

If I comment out the 
.endpointProperty(handlers,  jettyAuthHandler“)
statement inside the restConfiguration() segment of Route4 and use a further 
route (route1 in the sample scenario), which defines a jetty server using the 
following URL:

rest.ssl.service1.path=jetty:https://localhost:8383/api/v1/service1?sslContextParameters=#sslContextParametershandlers=#jettyAuthHandlermatchOnUriPrefix=true
both services are able to use SSL and basic authentication. This issue seems to 
be very similar to the issue reported here 
(https://github.com/fabric8io/fabric8/issues/2094).

I haven’t written proper unit-tests yet, but executing ServicesApp should start 
up the whole application and pointing your browser to 
https://localhost:8383/api/v1/service4 and using „admin“ as user as well as 
„secret“ as password should reproduce the following error:

2014-11-11 17:47:45 - [DEBUG] - received login request for user: 'admin' with 
credentials: 'secret'! [] 
[a.r.c.t.a.JettyBasicAuthAuthorizationHandler] [qtp139076452-36] 
2014-11-11 17:47:45 - [DEBUG] - UserKey secret of User admin was successfully 
authenticated [] [a.r.c.t.a.JettyBasicAuthAuthorizationHandler] 
[qtp139076452-36] 
2014-11-11 17:47:45 - [WARN ] - /api/v1/service4 [] 
[o.e.j.s.AbstractHttpConnection] [qtp139076452-36] 
java.lang.StackOverflowError: null
at java.util.HashMap$KeyIterator.init(HashMap.java:954) ~[na:1.7.0_60]
at java.util.HashMap.newKeyIterator(HashMap.java:968) ~[na:1.7.0_60]
at java.util.HashMap$KeySet.iterator(HashMap.java:1002) ~[na:1.7.0_60]
at java.util.HashSet.iterator(HashSet.java:170) ~[na:1.7.0_60]
at 
java.util.Collections$UnmodifiableCollection$1.init(Collections.java:1064) 
~[na:1.7.0_60]
at 
java.util.Collections$UnmodifiableCollection.iterator(Collections.java:1063) 
~[na:1.7.0_60]
at 
org.eclipse.jetty.security.ConstraintSecurityHandler.prepareConstraintInfo(ConstraintSecurityHandler.java:656)
 ~[jetty-security-8.1.16.v20140903.jar:8.1.16.v20140903]
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:458) 
~[jetty-security-8.1.16.v20140903.jar:8.1.16.v20140903]
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522) 
~[jetty-security-8.1.16.v20140903.jar:8.1.16.v20140903]
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522) 
~[jetty-security-8.1.16.v20140903.jar:8.1.16.v20140903]
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522) 
~[jetty-security-8.1.16.v20140903.jar:8.1.16.v20140903]
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522) 
~[jetty-security-8.1.16.v20140903.jar:8.1.16.v20140903]
...

Kind regards,

Roman

Am 05.11.2014 um 11:37 schrieb Claus Ibsen claus.ib...@gmail.com:

 Hi
 
 You can configure the jetty component regularly without the rest dsl,
 and just refer to jetty as the component. Then the Rest DSL uses the
 jetty with the security settings you have configured on it.
 
 And I think we have fixed the double ? in the uri in the upcoming
 2.14.1 release.
 
 On Wed, Nov 5, 2014 at 10:53 AM, Roman Vottner r...@gmx.at wrote:
 This is a repost of the nabble forum entry as my account was obviously not 
 correctly verified at the time when I posted this issue (post has NOT been 
 accepted …).
 
 In order to test the new REST feature in 2.14.0 I created a simple route 
 class:
 
 public class RestTestRoute extends RouteBuilder {
 
   @Override
   public void configure() throws Exception {
 
   restConfiguration()
   .component(jetty)
   .port(8383)
   .scheme(https)
   .contextPath(/api/v1)
   .endpointProperty(sslKeystore, /security/serverKey.jks)
   .endpointProperty(sslPassword

Rest DSL - how to configure SSL/Basic Auth for jetty component?

[Roman Vottner]

This is a repost of the nabble forum entry as my account was obviously not 
correctly verified at the time when I posted this issue (post has NOT been 
accepted …). 

In order to test the new REST feature in 2.14.0 I created a simple route class: 

public class RestTestRoute extends RouteBuilder { 

   @Override 
   public void configure() throws Exception { 

   restConfiguration() 
   .component(jetty) 
   .port(8383) 
   .scheme(https) 
   .contextPath(/api/v1) 
   .endpointProperty(sslKeystore, /security/serverKey.jks) 
   .endpointProperty(sslPassword, keystorePW) 
   .endpointProperty(sslKeyPassword, jettyPW) 
   // .componentProperty(sslContextParameters, 
#sslContextParameters) 
   .componentProperty(handlers, #jettyAuthHandler); 

   rest(/service4) 
   .get().route().log(Service4 GET request received).endRest() 
   .post().route().log(Service4 POST request received).endRest() 
   .delete().route().log(Service4 DELETE request received).endRest(); 
   } 
} 

However, special-characters like / or : get replaced by %2F and %3A 
which cause a UnknownFormatConversionException: Conversion = 'F' in the primer 
case and a MissingFormatArgumentException: Format specifier '3A' in the latter 
case. As endpoint- or componentProperty only allows for string value 
declarations, I also tried to set Spring beans as used with a leading # before 
but without any success. 

If I leave out the sslKeystore stuff the example fails with a 
FileNotFoundException as it can't locate the keystore in my home-directory - 
which I have none. Though, I'd like to use the JKS located in the 
security-subfolder of my project. The documentation lacks a full example which 
showcases a bit more complex scenario. 

From debugging, I also figured out that the contextPath is not added on top of 
the jetty:... generated URL - is this only valid in servlet scenarios? 
Moreover, I'm a bit confused about the generated URL in JettyHttpComponent as 
it contains two '?' symbols: 

jetty:%s://%s:%s/%s?httpMethodRestrict=%s?sslPassword=keystorePWsslKeyPassword=jettyPWsslKeystore=%2Fsecurity%2FserverKey.jks

A simple test-project setup can be gathered in rest-dsl branch on github: 
https://github.com/RovoMe/CamelMultipleJettyComponents/tree/rest-dsl

Kind regards,

Roman

StackOverflowError on configuring JettyHttpComponents with handlers for the same port

[Roman Vottner]

We upgraded from Camel 2.13.0 to 2.14.0 a couple of days ago and noticed some 
problems during the upgrade. While we managed to fix certain issues with CXF 
based services in Camel (extending spring configurations didn’t work for us in 
2.14.0 but using @Import({…}) does achieve the same), we noticed that on having 
multiple routes that define „RESTful services“ via Camels JettyComponent 
initialization fails with a StackOverflowException.

Each route injects the component-string from a property file which is 
furthermore used inside the from(…) statement inside the route. In Camel 2.13.0 
this was working fine (which can be seen in a github project: 
https://github.com/RovoMe/CamelMultipleJettyComponents) but Camel 2.14.0 
(https://github.com/RovoMe/CamelMultipleJettyComponents/tree/version-upgrade) 
produces a StackOverflowError as mentioned earlier. If enableMultipartFilter is 
set to false (as parameter for the configuration-string) the error is delayed 
to invocation time instead of setup time.

The (updated?) documentation states Important: You can not use different 
handlers with different Jetty endpoints using the same port number. The 
handlers is associated to the port number. If you need different handlers, then 
use different port numbers.„  So on removing handler=#jettyAuthHandler from all 
but the first route 
(https://github.com/RovoMe/CamelMultipleJettyComponents/tree/version-upgrade-fix)
 the services are working again. So is the injected jetty basic auth handler a 
different handler for every service? In that case, there should be a more 
expressive exception rather than a StackOverflowError IMO.

Kind regards,

Roman