Re: issue with property in REST DSL in blueprint context - Camel 2.19.1

[claud...@gmail.com]

Yes, quite the upgrade... but everything else seems to be working fine 
so far. ;)


I raised a ticket: https://issues.apache.org/jira/browse/CAMEL-11636

Thx!

On 04.08.17 13:39, Claus Ibsen wrote:

Hi

Yeah a change from 2.16.x to 2.19.x is a little bit big upgrade.
However this sounds like a little bug.

You are welcome to log a JIRA and we can look at getting this fixed
for upcoming releases.

On Fri, Aug 4, 2017 at 11:24 AM, claud...@gmail.com  wrote:

Hi,

I'm trying to update from Camel 2.16.3 to 2.19.1 and experience issues using
properties in the REST DSL in blueprint context.

I have the following config:

 
 
 
 
 

For the param "limit" the property "{{vel.rest.default.rowlimit}}" used in
attribute defaultValue seems not to get replaced as I receive the following
exception:

java.lang.NumberFormatException: For input string:
"{{vel.rest.default.rowlimit}}"


I googled for known issues but didn't find anything. Has anything changed
related to using properties in REST DSL? It previously worked (2.16.3) and
in other places e.g. in the route the syntax "{{propertyName}}" works...

Cheers
Claudia

Stream closed exception when using camel as http proxy with tomcat servlet

[Paul Käufl]

Hello,

following the example provided in
http://camel.apache.org/how-to-use-camel-as-a-http-proxy-between-a-client-and-server.html,
we are using a route definition as follows to proxy an http endpoint via
a servlet running in Tomcat 8.5.16:

from("servlet:///?matchOnUriPrefix=true")

.to("http4://localhost:8080/respondsWith304?bridgeEndpoint=true=false");

Whenever the http endpoint responds with a status code 304 or - more
specifically - with one of the status codes listed in
org.apache.http.protocol.HttpRequestExecutor#canResponseHaveBody,
a "java.io.IOException: Stream closed" is logged and the servlet replies
with HTTP Status 500 – Internal Server Error.

I've assembled a (rather) minimal working example to reproduce the
issue: https://github.com/kaeufl/camel-http-proxy-stream-closed-issue

We're experiencing the issue with both the latest camel release 2.19.2
as well as the current master branch.

We can workaround the issue by
 (a) either disabling stream caching for the servlet component
explicitly, by writing:
from("servlet:///?matchOnUriPrefix=true=true")
 (b) or by converting the request(!) body to String in the route:
from("servlet:///?matchOnUriPrefix=true").convertBodyTo(String.class)

As far as I understand (and my understanding of camel is still very
limited), there are two problems with this:

1) Shouldn't stream caching be disabled by default? At least that's what
I understood from http://camel.apache.org/stream-caching.html

The method
org.apache.camel.http.common.HttpHelper#readRequestBodyFromServletRequest
oddly calls the method readResponseBodyFromInputStream() which does NOT
seem to take the global stream caching setting into account...

2) The actual issue seems to be a null response body in the HttpMessage
contained in the exchange after
org.apache.camel.component.http4.HttpProducer#populateResponse.

Due to the response body being set to null, it is later tried to re-read
the request (!) body in
org.apache.camel.http.common.DefaultHttpBinding#doWriteResponse, line 391.

If someone can confirm that this is indeed a bug, I'd be happy to open
an issue. It is yet a little unclear to me, however, where the root of
the problem actually lies.

Also I couldn't figure out how to write a camel integration test that
makes use of the servlet component. I'd really appreciate if someone
could point me at an example.

Also note that we couldn't reproduce the behaviour with jetty as a
servlet container.

Kind regards and thanks for your help,
Paul

-- 
Paul Käufl * paul.kae...@tngtech.com * +49-1520-7182305
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Müller
Sitz: Unterföhring * Amtsgericht München * HRB 135082

Camel - The name and slogans ...

[Oliver Doepner]

Hi,

I just read http://camel.apache.org/why-the-name-camel.html

I like the slogans and then this groaner popped into my head:

"Everything tastes sweeter when it Camel-ized."

(as in caramelized: https://en.wikipedia.org/wiki/Caramelization)

Let me know if you feel this email is spam and I will control myself better
next time I have silly ideas like this. :)

Cheers
Oliver

-- 
Oliver Doepner
Halifax, Nova Scotia
http://oliver.doepner.net/
Buchstabensalat : ßäöüÄÖÜ

Re: Full example of configuring endpoints in pure Java (without uri strings)

[Oliver Doepner]

Hello Claus,

Thanks a lot for your helpful response.

Currently I just set the CamelContext on the endpoints right after I create
them and that seems to take care of the wiring between endpoint and
component.

Regarding the code example I included in my previous email to this list, I
had to make a small change to make it work:

Instead of main.addRouteBuilder(...), I now use context.addRoutes(...).
I also had to wrap those calls in a try-catch, which is fine, I guess.

So something like:

try {

context.addRoutes(new MyRouteBuilder(...));
context.addRoutes(new MyOtherRouteBuilder(...));

// Some Camel 2.x APIs still use "throws Exception". Apparently this might
change in Camel 3.x and beyond:
//
http://camel.apache.org/camel-30-ideas.html#Camel3.0-Ideas-AvoidthrowsExceptiononenduserAPI
} catch (Exception e) {
throw new IllegalStateException(e);
}



On Fri, Aug 4, 2017 at 8:42 AM, Claus Ibsen  wrote:

> Hi
>
> Yeah you can run Camel standalone with that main class or do it by
> yourself.
>
> One comment is that when you create the CxfEndpoint then you need to
> set the CxfComponent on this instance as well.
>
> Ideally you create the endpoints via the uri syntax, or via the component.
>
> For some camel components then they rely on the component for the
> endpoints,producers,consumers etc such as JMS, Jetty, and possible
> CXF.
>
> So a good rule of thumb is to create endpoints via their components.
> Afterwards you can tweak then via their getter/setters.
>
> In the future we will have some tooling to auto generate a builder
> style Java DSL for the endpoints so you can configure them in a type
> safe manner via java code. That is on the roadmap for 3.x.
>
> On Wed, Aug 2, 2017 at 6:47 PM, Oliver Doepner  wrote:
> > Hello,
> >
> > I am trying to use Camel using the pure Java approach (Java DSL, no DI
> > framework, no URI Strings).
> >
> > My approach so far is like the simplistic sample below, but I am not sure
> > if it uses proper practices.
> >
> > Can you please let me know if/what problems you see with this approach?
> > Is there maybe documentation somewhere with a full "pure Java" example?
> >
> > Thank you
> > Oliver
> >
> >
> > import org.apache.camel.CamelContext;
> > import org.apache.camel.Exchange;
> > import org.apache.camel.Processor;
> > import org.apache.camel.builder.RouteBuilder;
> > import org.apache.camel.component.cxf.CxfComponent;
> > import org.apache.camel.component.cxf.CxfEndpoint;
> > import org.apache.camel.main.Main;
> > import org.apache.camel.main.MainListenerSupport;
> >
> > public class CamelExample {
> >
> > public static void main(String... args) throws Exception {
> >
> > final Main main = new Main();
> >
> > main.addMainListener(new MainListenerSupport() {
> > @Override
> > public void configure(CamelContext context) {
> > context.addComponent("cxf", new CxfComponent());
> >
> > final CxfEndpoint webService = new CxfEndpoint();
> > webService.setCamelContext(context);
> > webService.setAddress("http://service/entity;);
> > webService.setServiceClass(MyService.class);
> > webService.setDefaultOperationName("test");
> > // etc
> >
> > Processor requestPreparation = new Processor() {
> > @Override
> > public void process(Exchange exchange) throws
> Exception
> > {
> > exchange.getIn().setBody(new MyServiceRequest());
> > }
> > };
> >
> > main.addRouteBuilder(
> > new RouteBuilder() {
> > @Override
> > public void configure() throws Exception {
> > from("direct:start")
> > .process(requestPreparation)
> > .to(webService);
> > }
> > }
> > );
> > }
> > });
> >
> > main.run();
> > }
> >
> > /* web service related classes stubbed out to keep example code
> simple
> > */
> >
> > private static final class MyService {};
> > private static final class MyServiceRequest {};
> >
> > }
> >
> >
> >
> > --
> > Oliver Doepner
> > Software Developer
> > IMP Solutions, Halifax, NS
> > Phone 1-902-482-1615
> >
> >
> >
> > --
> > Oliver Doepner
> > Halifax, Nova Scotia
> > http://oliver.doepner.net/
> > Buchstabensalat : ßäöüÄÖÜ
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>



-- 
Oliver Doepner
Halifax, Nova Scotia
http://oliver.doepner.net/
Buchstabensalat : ßäöüÄÖÜ

Re: Issue with camel-elasticsearch5 component

[Andrea Cosentino]

Here is the JIRA in SM
https://issues.apache.org/jira/browse/SM-3454

--
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix PMC Member
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Friday, August 4, 2017, 1:46:13 PM GMT+2, Claus Ibsen 
 wrote:


Try turning on dynamic import on those ES bundles via
dev:import-dynamic karaf command.

For the issue with the SMX bundle you can log that in the ServiceMix
JIRA ticket or in CAMEL. Then Andreas from the Camel/SMX team can take
a look, and get those packages to be imported|exported.


On Wed, Aug 2, 2017 at 8:17 AM, smanish  wrote:
> It is about camel-elasticsearch5 component.
> https://github.com/apache/camel/blob/master/platforms/karaf/features/src/main/resources/features.xml#L566-L580
>
> That basically use following bundles.
> 1 . Elasticsearch-Bundle
> http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.elasticsearch/5.4.3_1
>
> 2. Elasticsearch-Client Bundle
> https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.elasticsearch-client/5.4.3_1
>
> In order to work with elasticsearch 5 you need TransportClient as mentioned
> in
> https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/transport-client.html
> which is available in Elasticsearch bundle
>
> To get the TransportClient for first step you need to use
> PreBuiltTransportClient which is available in Elasticsearch-Client bundle.
>
> Now the problem is that Elasticsearch-Client which is expected to return
> TransportClient does not have it and also not importing it and gives class
> not found exception " Caused by: java.lang.ClassNotFoundException:
> org.elasticsearch.client.transport.TransportClient not found by
> org.apache.servicemix.bundles.elasticsearch-client [127]"
>
> So the question is how it is expected to work?
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Issue-with-camel-elasticsearch5-component-tp5809063.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: Issue with camel-elasticsearch5 component

[Claus Ibsen]

Try turning on dynamic import on those ES bundles via
dev:import-dynamic karaf command.

For the issue with the SMX bundle you can log that in the ServiceMix
JIRA ticket or in CAMEL. Then Andreas from the Camel/SMX team can take
a look, and get those packages to be imported|exported.


On Wed, Aug 2, 2017 at 8:17 AM, smanish  wrote:
> It is about camel-elasticsearch5 component.
> https://github.com/apache/camel/blob/master/platforms/karaf/features/src/main/resources/features.xml#L566-L580
>
> That basically use following bundles.
> 1 . Elasticsearch-Bundle
> http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.elasticsearch/5.4.3_1
>
> 2. Elasticsearch-Client Bundle
> https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.elasticsearch-client/5.4.3_1
>
> In order to work with elasticsearch 5 you need TransportClient as mentioned
> in
> https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/transport-client.html
> which is available in Elasticsearch bundle
>
> To get the TransportClient for first step you need to use
> PreBuiltTransportClient which is available in Elasticsearch-Client bundle.
>
> Now the problem is that Elasticsearch-Client which is expected to return
> TransportClient does not have it and also not importing it and gives class
> not found exception " Caused by: java.lang.ClassNotFoundException:
> org.elasticsearch.client.transport.TransportClient not found by
> org.apache.servicemix.bundles.elasticsearch-client [127]"
>
> So the question is how it is expected to work?
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Issue-with-camel-elasticsearch5-component-tp5809063.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: apache camel toD does not accept a property value of about 40 characters

[Claus Ibsen]

There is no limit to the length of options in Camel etc, so I would be
surprised if there is a bug in Camel in this regard. I suggest to dive
deeper. And also test this on newer versions of Camel etc if you can
reproduce on a supported branch. 2.17.x is EOL.

On Wed, Aug 2, 2017 at 4:21 PM, jephreycuma  wrote:
> Hi everyone,
> I calculated a message digest value using DigestUtils.sha1Hex(String value),
> which gave me a long string of about 40 characters (e.g
> dd543d3bcb28e577313f8b945f29a9be7a43c5fd).
> I needed to pass this messageDigest value to my internal camel component
> which in turn is supposed to write it to our DB. To achieve this, I used
>  ="message-history/somevalue/othervaluesmessageDigest=dd543d3bcb28e577313f8b945f29a9be7a43c5fd"
> /> of camel 2.17.5.
> This sent an empty value of messageDigest to my message-history component.
> However when I use
> 
> 
> message-history/somevalue/othervalues=dd543d3bcb28e577313f8b945f29a9be7a43c5fd
> 
> 
> it does send a value of messageDigest to my message-history component, and
> also when I make the value of messageDigest smaller say about 5 characters,
> the  camel toD does send the value of messageDigest.
> Could this be a bug in camel 2.17.5 on toD?
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/apache-camel-toD-does-not-accept-a-property-value-of-about-40-characters-tp5809139.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: Full example of configuring endpoints in pure Java (without uri strings)

[Claus Ibsen]

Hi

Yeah you can run Camel standalone with that main class or do it by yourself.

One comment is that when you create the CxfEndpoint then you need to
set the CxfComponent on this instance as well.

Ideally you create the endpoints via the uri syntax, or via the component.

For some camel components then they rely on the component for the
endpoints,producers,consumers etc such as JMS, Jetty, and possible
CXF.

So a good rule of thumb is to create endpoints via their components.
Afterwards you can tweak then via their getter/setters.

In the future we will have some tooling to auto generate a builder
style Java DSL for the endpoints so you can configure them in a type
safe manner via java code. That is on the roadmap for 3.x.

On Wed, Aug 2, 2017 at 6:47 PM, Oliver Doepner  wrote:
> Hello,
>
> I am trying to use Camel using the pure Java approach (Java DSL, no DI
> framework, no URI Strings).
>
> My approach so far is like the simplistic sample below, but I am not sure
> if it uses proper practices.
>
> Can you please let me know if/what problems you see with this approach?
> Is there maybe documentation somewhere with a full "pure Java" example?
>
> Thank you
> Oliver
>
>
> import org.apache.camel.CamelContext;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.component.cxf.CxfComponent;
> import org.apache.camel.component.cxf.CxfEndpoint;
> import org.apache.camel.main.Main;
> import org.apache.camel.main.MainListenerSupport;
>
> public class CamelExample {
>
> public static void main(String... args) throws Exception {
>
> final Main main = new Main();
>
> main.addMainListener(new MainListenerSupport() {
> @Override
> public void configure(CamelContext context) {
> context.addComponent("cxf", new CxfComponent());
>
> final CxfEndpoint webService = new CxfEndpoint();
> webService.setCamelContext(context);
> webService.setAddress("http://service/entity;);
> webService.setServiceClass(MyService.class);
> webService.setDefaultOperationName("test");
> // etc
>
> Processor requestPreparation = new Processor() {
> @Override
> public void process(Exchange exchange) throws Exception
> {
> exchange.getIn().setBody(new MyServiceRequest());
> }
> };
>
> main.addRouteBuilder(
> new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> from("direct:start")
> .process(requestPreparation)
> .to(webService);
> }
> }
> );
> }
> });
>
> main.run();
> }
>
> /* web service related classes stubbed out to keep example code simple
> */
>
> private static final class MyService {};
> private static final class MyServiceRequest {};
>
> }
>
>
>
> --
> Oliver Doepner
> Software Developer
> IMP Solutions, Halifax, NS
> Phone 1-902-482-1615
>
>
>
> --
> Oliver Doepner
> Halifax, Nova Scotia
> http://oliver.doepner.net/
> Buchstabensalat : ßäöüÄÖÜ



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: issue with property in REST DSL in blueprint context - Camel 2.19.1

[Claus Ibsen]

Hi

Yeah a change from 2.16.x to 2.19.x is a little bit big upgrade.
However this sounds like a little bug.

You are welcome to log a JIRA and we can look at getting this fixed
for upcoming releases.

On Fri, Aug 4, 2017 at 11:24 AM, claud...@gmail.com  wrote:
> Hi,
>
> I'm trying to update from Camel 2.16.3 to 2.19.1 and experience issues using
> properties in the REST DSL in blueprint context.
>
> I have the following config:
>
>  path="patient/{patient_id}/events?cutoff_timestamp={cutoff_timestamp}limit={limit}"
> produces="application/json" consumes="application/json">
> 
>  required="true" />
>  required="false" />
>  required="false" defaultValue="{{vel.rest.default.rowlimit}}" />
>
> For the param "limit" the property "{{vel.rest.default.rowlimit}}" used in
> attribute defaultValue seems not to get replaced as I receive the following
> exception:
>
>java.lang.NumberFormatException: For input string:
>"{{vel.rest.default.rowlimit}}"
>
>
> I googled for known issues but didn't find anything. Has anything changed
> related to using properties in REST DSL? It previously worked (2.16.3) and
> in other places e.g. in the route the syntax "{{propertyName}}" works...
>
> Cheers
> Claudia
>
>
>
>
>



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

issue with property in REST DSL in blueprint context - Camel 2.19.1

[claud...@gmail.com]

Hi,

I'm trying to update from Camel 2.16.3 to 2.19.1 and experience issues 
using properties in the REST DSL in blueprint context.


I have the following config:

path="patient/{patient_id}/events?cutoff_timestamp={cutoff_timestamp}limit={limit}" 
produces="application/json" consumes="application/json">


required="true" />
dataType="long" required="false" />
required="false" defaultValue="{{vel.rest.default.rowlimit}}" />


For the param "limit" the property "{{vel.rest.default.rowlimit}}" used 
in attribute defaultValue seems not to get replaced as I receive the 
following exception:


   java.lang.NumberFormatException: For input string:
   "{{vel.rest.default.rowlimit}}"


I googled for known issues but didn't find anything. Has anything 
changed related to using properties in REST DSL? It previously worked 
(2.16.3) and in other places e.g. in the route the syntax 
"{{propertyName}}" works...


Cheers
Claudia