HTTP producer NTLM auth behavior seems to depend on consumer
Hi all, I've a route that calls an endpoint with NTLM auth. It works pretty when calling the route on a HTTP consumer. http://www.osgi.org/xmlns/blueprint/v1.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd"; xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0";> http://camel.apache.org/schema/blueprint";> http://0.0.0.0:8182/NTLM"; /> GET http://host?bridgeEndpoint=true&authMethod=NTLM&authDomain=&authUsername=xxx&authPassword=xxx&throwExceptionOnFailure=false"; /> When I'm going to change the consumer from HTTP consumer to Timer consumer like http://www.osgi.org/xmlns/blueprint/v1.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd"; xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0";> http://camel.apache.org/schema/blueprint";> GET http://host?bridgeEndpoint=true&authMethod=NTLM&authDomain=&authUsername=xxx&authPassword=xxx&throwExceptionOnFailure=false"; /> than I'm getting an error 2020-04-23T22:36:31,980 | WARN | qtp711860658-153 | HttpAuthenticator | 164 - org.apache.httpcomponents.httpclient - 4.5.10 | NEGOTIATE authentication error: Invalid name provided (Mechanism level: KrbException: Cannot locate default realm) It's a bit weird. Same also when I'm changing to a File consumer. Any ideas about this? Thanks in advance - Gerald
Re: Simple language in 3.1.0
Hi
Thanks, fixing that doc page
On Thu, Apr 23, 2020 at 4:22 PM Remco Schoen wrote:
>
> At the URL I posted:
>
> https://camel.apache.org/components/latest/languages/simple-language.html
>
> And Google found it for me…
>
>
> Op 23 apr. 2020, om 16:20 heeft Claus Ibsen
> mailto:claus.ib...@gmail.com>> het volgende geschreven:
>
> On Thu, Apr 23, 2020 at 4:19 PM Remco Schoen
> mailto:r.sch...@topdesk.com>> wrote:
>
> Hi,
>
> I checked the docs for 2.x and there it says it is deprecated, thanks.
>
> But my next question would be, is the documentation still up-to-date:
>
> “The simple language uses ${body} placeholders for complex expressions where
> the expression contains constant literals. The $\{ } placeholders can be
> omitted if the expression is only the token itself.”
>
>
> That doc is out of date, where did you find it?
>
>
> I’m reading this as it is still allowed, but maybe this has to be removed or
> it means something different.
>
> Kind regards,
>
> Remco Schoen
>
> Op 23 apr. 2020, om 16:08 heeft Guillaume Nodet
> mailto:gno...@apache.org>> het volgende geschreven:
>
> The syntax without placeholders had been deprecated in the 2.x branch since
> a long time.
> You now need to use simple('${headers.entityMap.sourceTableName}')
>
> Le jeu. 23 avr. 2020 à 15:42, Remco Schoen
> mailto:r.sch...@topdesk.com>> a écrit :
>
> Hi,
>
> I have a question about the Simple language and the use of ${}.
>
> Before Camel 3 this worked in getting data from the object in the header:
> .setHeader('tableName').simple('headers.entityMap.sourceTableName’)
> .setHeader('fields').simple('headers.entityMap.sourceFields')
>
> In Camel 3.1.0 this no longer works and I get the string in my new headers.
>
> In the migration documentation I don’t see anything about a change here
> and according the documentation this still seems to be supported.
>
> https://camel.apache.org/components/latest/languages/simple-language.html
>
> “The simple language uses ${body} placeholders for complex expressions
> where the expression contains constant literals. The $\{ } placeholders can
> be omitted if the expression is only the token itself.”
>
> Should this still work in Camel 3?
>
> Kind regards,
>
> Remco Schoen
>
> P.S. I haven’t had time yet to research the upgrade to Camel 3.2.0, sorry.
>
>
>
> --
>
> Guillaume Nodet
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Simple language in 3.1.0
At the URL I posted:
https://camel.apache.org/components/latest/languages/simple-language.html
And Google found it for me…
Op 23 apr. 2020, om 16:20 heeft Claus Ibsen
mailto:claus.ib...@gmail.com>> het volgende geschreven:
On Thu, Apr 23, 2020 at 4:19 PM Remco Schoen
mailto:r.sch...@topdesk.com>> wrote:
Hi,
I checked the docs for 2.x and there it says it is deprecated, thanks.
But my next question would be, is the documentation still up-to-date:
“The simple language uses ${body} placeholders for complex expressions where
the expression contains constant literals. The $\{ } placeholders can be
omitted if the expression is only the token itself.”
That doc is out of date, where did you find it?
I’m reading this as it is still allowed, but maybe this has to be removed or it
means something different.
Kind regards,
Remco Schoen
Op 23 apr. 2020, om 16:08 heeft Guillaume Nodet
mailto:gno...@apache.org>> het volgende geschreven:
The syntax without placeholders had been deprecated in the 2.x branch since
a long time.
You now need to use simple('${headers.entityMap.sourceTableName}')
Le jeu. 23 avr. 2020 à 15:42, Remco Schoen
mailto:r.sch...@topdesk.com>> a écrit :
Hi,
I have a question about the Simple language and the use of ${}.
Before Camel 3 this worked in getting data from the object in the header:
.setHeader('tableName').simple('headers.entityMap.sourceTableName’)
.setHeader('fields').simple('headers.entityMap.sourceFields')
In Camel 3.1.0 this no longer works and I get the string in my new headers.
In the migration documentation I don’t see anything about a change here
and according the documentation this still seems to be supported.
https://camel.apache.org/components/latest/languages/simple-language.html
“The simple language uses ${body} placeholders for complex expressions
where the expression contains constant literals. The $\{ } placeholders can
be omitted if the expression is only the token itself.”
Should this still work in Camel 3?
Kind regards,
Remco Schoen
P.S. I haven’t had time yet to research the upgrade to Camel 3.2.0, sorry.
--
Guillaume Nodet
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Subscription left once a route is removed programmatically
I did several tests to try to understand the root cause of this weird behavior but I didn’t find any reason. Anyway it happens only for the first route I remove. And it happens again if I create and remove again the same route. In other word create route_1 create route_2 create route_3 remove route_1 leave only one subscription active (regardless of the concurrent consumers count set) remove route_2 completed fine (all consumers are removed and also the virtual queue created by the subscription) remove route_3 completed fine (all consumers are removed and also the virtual queue created by the subscription) Second test In other word create route_1 create route_2 create route_3 remove route_2 leave only one subscription active (regardless of the concurrent consumers count set) remove route_1 completed fine (all consumers are removed and also the virtual queue created by the subscription) remove route_3 completed fine (all consumers are removed and also the virtual queue created by the subscription) I tried to remove the route in different way. - remove the route definition as first step, and then the endpoints (checking if the route is correctly removed by the route definition remove) - remove the route and then the route definition and the endpoints - repeat the same steps invoking the route stop before but the result is the same Does someone have any idea about why it happens? Il giorno 31 mar 2020, alle ore 10:27, Modanese, Riccardo mailto:riccardo.modan...@eurotech.com.INVALID>> ha scritto: I have an ActiveMQ plugin to track subscriptions and other stuff. Moreover, if I re-create the route after a while, the route processes the messages received once it is supposed to be removed. The GC is done by a custom plugin since my use case doesn’t fit in any “regular” ActiveMQ GC. Anyway, if I force the destination deletion, my plugin is able to delete the queue. And when I re-create the route, the route doesn’t process any previous message. To give you some more detail, I’m experimenting with the REST routes using the http4 endpoint but, the endpoint itself, is plugged to the context with a different schema like: ... you can see the netstat output in attachment. > Il giorno 30 mar 2020, alle ore 16:19, Ralf Claussnitzer > mailto:ralf.claussnit...@slub-dresden.de>> > ha scritto: > > The route shutdown and removal appears to work. > > Where do you see this active subscription? > > Does it disappear when you GC the ActiveMQ component alltogether? > > Can you show the result of `netstat -atp` on the Broker machine? > > On 3/30/20 11:54 AM, Modanese, Riccardo wrote: >> Hi >> I switched the log to DEBUG level and I simplified the test leaving >> only one route (and reducing the concurrent consumers from 2 to 4). >> >> The issue still happens. >> >> ActiveMQ has a subscription: >> >> queue://Consumer.my-route-subs-id:EXACTLY_ONCE.VirtualTopic.my-subs.> >> >> with one consumer and no pending messages after the route is removed. >> >> >> You can see the extracted log in attachment. >> >> >> >> >> >> >> > Il giorno 30 mar 2020, alle ore 07:27, Ralf Claussnitzer >> > mailto:ralf.claussnit...@slub-dresden.de>> >> > ha scritto: >> > >> > Hi Riccardo, >> > >> > what is happening in DEBUG log when you call the remove? >> > >> > Maybe you are dealing with inflight exchanges here? >> > >> > Can you try to instead just stop the routes? >> > >> > -Ralf >> > >> > On 3/27/20 2:20 PM, Modanese, Riccardo wrote: >> >> Hi all, >> >> >> >> I'm experimenting with programmatically routes creation and removal >> >> (Camel version 2.17). >> >> The routes are created and removed at runtime through my custom >> >> RouteBuilder instance and are consuming from ActiveMQ 5 (with virtual >> >> topic enabled). >> >> Once a route is removed (*) all the subscriptions (for this specific >> >> route) to the broker are removed except for one. >> >> So one subscription to the broker still remains active. >> >> >> >> Unfortunately I have no simple test code to reproduce the behavior I'm >> >> seeing. >> >> >> >> Has someone any idea if I'm missing something or can point me to the >> >> right direction? >> >> >> >> Thank you. >> >> >> >> Riccardo >> >> >> >> >> >> (*) >> >> getContext().removeRouteDefinition(getContext().getRouteDefinition(routeId)); >>
Re: Simple language in 3.1.0
On Thu, Apr 23, 2020 at 4:19 PM Remco Schoen wrote:
>
> Hi,
>
> I checked the docs for 2.x and there it says it is deprecated, thanks.
>
> But my next question would be, is the documentation still up-to-date:
>
> “The simple language uses ${body} placeholders for complex expressions where
> the expression contains constant literals. The $\{ } placeholders can be
> omitted if the expression is only the token itself.”
>
That doc is out of date, where did you find it?
> I’m reading this as it is still allowed, but maybe this has to be removed or
> it means something different.
>
> Kind regards,
>
> Remco Schoen
>
> > Op 23 apr. 2020, om 16:08 heeft Guillaume Nodet het
> > volgende geschreven:
> >
> > The syntax without placeholders had been deprecated in the 2.x branch since
> > a long time.
> > You now need to use simple('${headers.entityMap.sourceTableName}')
> >
> > Le jeu. 23 avr. 2020 à 15:42, Remco Schoen a écrit :
> >
> >> Hi,
> >>
> >> I have a question about the Simple language and the use of ${}.
> >>
> >> Before Camel 3 this worked in getting data from the object in the header:
> >> .setHeader('tableName').simple('headers.entityMap.sourceTableName’)
> >> .setHeader('fields').simple('headers.entityMap.sourceFields')
> >>
> >> In Camel 3.1.0 this no longer works and I get the string in my new headers.
> >>
> >> In the migration documentation I don’t see anything about a change here
> >> and according the documentation this still seems to be supported.
> >>
> >> https://camel.apache.org/components/latest/languages/simple-language.html
> >>
> >> “The simple language uses ${body} placeholders for complex expressions
> >> where the expression contains constant literals. The $\{ } placeholders can
> >> be omitted if the expression is only the token itself.”
> >>
> >> Should this still work in Camel 3?
> >>
> >> Kind regards,
> >>
> >> Remco Schoen
> >>
> >> P.S. I haven’t had time yet to research the upgrade to Camel 3.2.0, sorry.
> >>
> >
> >
> > --
> >
> > Guillaume Nodet
>
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Simple language in 3.1.0
Hi,
I checked the docs for 2.x and there it says it is deprecated, thanks.
But my next question would be, is the documentation still up-to-date:
“The simple language uses ${body} placeholders for complex expressions where
the expression contains constant literals. The $\{ } placeholders can be
omitted if the expression is only the token itself.”
I’m reading this as it is still allowed, but maybe this has to be removed or it
means something different.
Kind regards,
Remco Schoen
> Op 23 apr. 2020, om 16:08 heeft Guillaume Nodet het
> volgende geschreven:
>
> The syntax without placeholders had been deprecated in the 2.x branch since
> a long time.
> You now need to use simple('${headers.entityMap.sourceTableName}')
>
> Le jeu. 23 avr. 2020 à 15:42, Remco Schoen a écrit :
>
>> Hi,
>>
>> I have a question about the Simple language and the use of ${}.
>>
>> Before Camel 3 this worked in getting data from the object in the header:
>> .setHeader('tableName').simple('headers.entityMap.sourceTableName’)
>> .setHeader('fields').simple('headers.entityMap.sourceFields')
>>
>> In Camel 3.1.0 this no longer works and I get the string in my new headers.
>>
>> In the migration documentation I don’t see anything about a change here
>> and according the documentation this still seems to be supported.
>>
>> https://camel.apache.org/components/latest/languages/simple-language.html
>>
>> “The simple language uses ${body} placeholders for complex expressions
>> where the expression contains constant literals. The $\{ } placeholders can
>> be omitted if the expression is only the token itself.”
>>
>> Should this still work in Camel 3?
>>
>> Kind regards,
>>
>> Remco Schoen
>>
>> P.S. I haven’t had time yet to research the upgrade to Camel 3.2.0, sorry.
>>
>
>
> --
>
> Guillaume Nodet
Re: Simple language in 3.1.0
The syntax without placeholders had been deprecated in the 2.x branch since
a long time.
You now need to use simple('${headers.entityMap.sourceTableName}')
Le jeu. 23 avr. 2020 à 15:42, Remco Schoen a écrit :
> Hi,
>
> I have a question about the Simple language and the use of ${}.
>
> Before Camel 3 this worked in getting data from the object in the header:
> .setHeader('tableName').simple('headers.entityMap.sourceTableName’)
> .setHeader('fields').simple('headers.entityMap.sourceFields')
>
> In Camel 3.1.0 this no longer works and I get the string in my new headers.
>
> In the migration documentation I don’t see anything about a change here
> and according the documentation this still seems to be supported.
>
> https://camel.apache.org/components/latest/languages/simple-language.html
>
> “The simple language uses ${body} placeholders for complex expressions
> where the expression contains constant literals. The $\{ } placeholders can
> be omitted if the expression is only the token itself.”
>
> Should this still work in Camel 3?
>
> Kind regards,
>
> Remco Schoen
>
> P.S. I haven’t had time yet to research the upgrade to Camel 3.2.0, sorry.
>
--
Guillaume Nodet
Error response from SalesforceHttpClient cutted - possible to extend?
Hi all,
I've enabled the DEBUG mode for an error investigation of the camel-salesforce
component.
The error finally is shown in the log as
2020-04-23T09:42:11,711 | DEBUG | SalesforceHttpClient@4e186e77-171 |
HttpReceiver | 223 - org.eclipse.jetty.util -
9.4.20.v20190813 | Response content HttpResponse[HTTP/1.1 500 Server
Error]@1900cfc5
DirectByteBufferR@1da39e09[p=788,l=848,c=16384,r=60]={HTTP/1.1 500
Serv...chunked\r\n\r\n3C\r\n<<<[{"error":"500::I...ssful":false}]\n>>>n;
charset=UTF-8\r...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
Unfortunately the interesting part has been cutted of
{"error":"500::I...ssful":false}
Is there a way to get the detailed message in Karaf log?
Thanks in advance
- Gerald
Simple language in 3.1.0
Hi,
I have a question about the Simple language and the use of ${}.
Before Camel 3 this worked in getting data from the object in the header:
.setHeader('tableName').simple('headers.entityMap.sourceTableName’)
.setHeader('fields').simple('headers.entityMap.sourceFields')
In Camel 3.1.0 this no longer works and I get the string in my new headers.
In the migration documentation I don’t see anything about a change here and
according the documentation this still seems to be supported.
https://camel.apache.org/components/latest/languages/simple-language.html
“The simple language uses ${body} placeholders for complex expressions where
the expression contains constant literals. The $\{ } placeholders can be
omitted if the expression is only the token itself.”
Should this still work in Camel 3?
Kind regards,
Remco Schoen
P.S. I haven’t had time yet to research the upgrade to Camel 3.2.0, sorry.
camel-salesforce - Subscription fails with a org.cometd.common.TransportException: {httpCode=500}
Hi all,
I've following route
http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
https://test.salesforce.com";>
http://camel.apache.org/schema/blueprint";
streamCache="true" useBreadcrumb="true">
The start always fails with (see below). Other Salesforce API calls with same
setup are working well. Any ideas?
2020-04-23T09:42:11,817 | DEBUG | SalesforceHttpClient@4e186e77-171 | 511072ca
| 57 - cometd-java-client - 4.0.4 | Messages failed
[{clientId=xxx, channel=/meta/subscribe, id=228,
subscription=/data/AccountChangeEvent}]
org.cometd.common.TransportException: {httpCode=500}
at
org.cometd.client.transport.LongPollingTransport$2.onComplete(LongPollingTransport.java:254)
[!/:4.0.4]
at
org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:198)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:190)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:444)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:390)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:316)
[!/:9.4.20.v20190813]
at org.eclipse.jetty.http.HttpParser.parseFields(HttpParser.java:1139)
[!/:9.4.20.v20190813]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1498)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:172)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:135)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:73)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:154)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
[!/:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:426)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:320)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:158)
[!/:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
[!/:9.4.20.v20190813]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782)
[!/:9.4.20.v20190813]
at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918)
[!/:9.4.20.v20190813]
at java.lang.Thread.run(Unknown Source) [?:?]
2020-04-23T09:42:11,819 | DEBUG | SalesforceHttpClient@4e186e77-171 | 511072ca
| 57 - cometd-java-client - 4.0.4 | Failing
{clientId=xxx, channel=/meta/subscribe, id=228,
subscription=/data/AccountChangeEvent}
2020-04-23T09:42:11,820 | DEBUG | SalesforceHttpClient@4e186e77-171 |
SubscriptionHelper | 130 - org.apache.camel.camel-salesforce -
3.0.0 | [CHANNEL:META_SUBSCRIBE]:
{failure={exception=org.cometd.common.TransportException: {httpCode=500},
message={clientId=xxx, channel=/meta/subscribe, id=228,
subscription=/data/AccountChangeEvent}, httpCode=500,
connectionType=long-polling}, channel=/meta/subscribe, id=228,
subscription=/data/Account
Re: DeadLetterChannelBuilder in combination w/ doTry/doCatch
Hi Mind about the DLQ is usually a drop point for the message content, and as you use a file endpoint, then you can only reply this by having a route that pickup those files and route back to what its supposed to do. The actual exception message should still be logged in the log, so you have a chance to find out why it failed. Also mind that this requires to be able to reply the message safely, eg the error may happen half way into a route, and then you replay the message from DLQ, and then it may re-process some parts it did before the error (idempotence). Since your example started from a JMS and a JMS broker has error handling and delivery, then have you though about using its feature for that, and not Camels. On Wed, Apr 22, 2020 at 2:59 PM Gerald Kallas wrote: > > Hi Claus, > > tx for the reply. > > I already thought about direct send to the DLQ. > > When I'm going to use a file consumer with a failure directory configured eg > > http://www.osgi.org/xmlns/blueprint/v1.0.0"; > > > > > > xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 > > > https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";> > > > > > > > > class="org.apache.camel.processor.errorhandler.RedeliveryPolicy"> > > > > > > > > > > > > > > > > > class="org.apache.camel.builder.DeadLetterChannelBuilder"> > > > > > > > > ref="redeliveryPolicyConfig"/> > > > > > > > > > > > > > > > > > > > > errorHandlerRef="deadLetterErrorHandler" /> > > > > > > > > > > > > https://someFailureEndpoint"; /> > > > > > > > > > > > > > > > java.lang.Exception > > > ... > > > > > > > > exceptionType="java.lang.Exception" message="Exception captured."/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel Endpoint DSL
Hi
You are using java so you can use the powers of java and for example
have a method that returns the Endpoint instance, and then have one
implementation for DEV and another for PROD.
And they can build this instance using endpoint-dsl or uri string or whatever.
You can also use dependency injection and have 2 different classes
that builds the endpoint and then if you package/builder your app with
some filtering (like spring boot profiles) then it can pick either
classes accordingly.
On Thu, Apr 23, 2020 at 10:06 AM Mikael Andersson Wigander
wrote:
>
> Hi
>
> How can I combine the endpoint DSL with dynamic property definitions such as:
>
> final String toStr = "{{shuttle.ftp.outgoing.url}}" +
> "&username={{shuttle.ftp.username}}" +
> "&password={{shuttle.ftp.password}}" +
> "&allowNullBody=false" +
> "&consumer.bridgeErrorHandler=true" +
> "&throwExceptionOnConnectFailed=true" +
> "&pollStrategy=#defaultPollStrategy";
>
> from("{{shuttle.outgoing.transactions}}")
> .routeId("Sending-SHUTTLE-FTP")
> .autoStartup("{{shuttle.ftp.outgoing.startup}}")
> .wireTap("seda:ping")
> .to(toStr)
> .log("XML file(s) sent")
> .end();
>
>
> What I’d like is to have the option to have our DEV environment setup using
> say FTP but in INTEGRATION and PROD it will be SFTP. Since the endpointDSL is
> somewhat “hardcoding” the endpoint I don’t really know how to do it
>
> Thx
>
> M
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel Endpoint DSL
Thx, that’s what I suspected!
M
> On 23 Apr 2020, at 11:26, Guillaume Nodet wrote:
>
> Le jeu. 23 avr. 2020 à 10:06, Mikael Andersson Wigander <
> mikael.grevs...@gmail.com> a écrit :
>
>> Hi
>>
>> How can I combine the endpoint DSL with dynamic property definitions such
>> as:
>>
>
> You can use property placeholders with the endpoint DSL, but the goal of
> the
> dsl is to provide some type safety for properties. In order to do that,
> you need to
> know the endpoint type beforehand. Soin your use case where the component
> is not know, you can't leverage the endpoint dsl much.
>
>
>>
>> final String toStr = "{{shuttle.ftp.outgoing.url}}" +
>>"&username={{shuttle.ftp.username}}" +
>>"&password={{shuttle.ftp.password}}" +
>>"&allowNullBody=false" +
>>"&consumer.bridgeErrorHandler=true" +
>>"&throwExceptionOnConnectFailed=true" +
>>"&pollStrategy=#defaultPollStrategy";
>>
>> from("{{shuttle.outgoing.transactions}}")
>>.routeId("Sending-SHUTTLE-FTP")
>>.autoStartup("{{shuttle.ftp.outgoing.startup}}")
>>.wireTap("seda:ping")
>>.to(toStr)
>>.log("XML file(s) sent")
>>.end();
>>
>>
>> What I’d like is to have the option to have our DEV environment setup
>> using say FTP but in INTEGRATION and PROD it will be SFTP. Since the
>> endpointDSL is somewhat “hardcoding” the endpoint I don’t really know how
>> to do it
>>
>> Thx
>>
>> M
>
>
>
> --
>
> Guillaume Nodet
Re: Camel Endpoint DSL
Le jeu. 23 avr. 2020 à 10:06, Mikael Andersson Wigander <
mikael.grevs...@gmail.com> a écrit :
> Hi
>
> How can I combine the endpoint DSL with dynamic property definitions such
> as:
>
You can use property placeholders with the endpoint DSL, but the goal of
the
dsl is to provide some type safety for properties. In order to do that,
you need to
know the endpoint type beforehand. Soin your use case where the component
is not know, you can't leverage the endpoint dsl much.
>
> final String toStr = "{{shuttle.ftp.outgoing.url}}" +
> "&username={{shuttle.ftp.username}}" +
> "&password={{shuttle.ftp.password}}" +
> "&allowNullBody=false" +
> "&consumer.bridgeErrorHandler=true" +
> "&throwExceptionOnConnectFailed=true" +
> "&pollStrategy=#defaultPollStrategy";
>
> from("{{shuttle.outgoing.transactions}}")
> .routeId("Sending-SHUTTLE-FTP")
> .autoStartup("{{shuttle.ftp.outgoing.startup}}")
> .wireTap("seda:ping")
> .to(toStr)
> .log("XML file(s) sent")
> .end();
>
>
> What I’d like is to have the option to have our DEV environment setup
> using say FTP but in INTEGRATION and PROD it will be SFTP. Since the
> endpointDSL is somewhat “hardcoding” the endpoint I don’t really know how
> to do it
>
> Thx
>
> M
--
Guillaume Nodet
RE: Camel Endpoint DSL
Hi Mikael
When I've had to do things like this I use recipientList. Maybe worth a try?
-Original Message-
From: Mikael Andersson Wigander
Sent: Thursday, 23 April 2020 10:06
To: users@camel.apache.org
Subject: Camel Endpoint DSL
Hi
How can I combine the endpoint DSL with dynamic property definitions such as:
final String toStr = "{{shuttle.ftp.outgoing.url}}" +
"&username={{shuttle.ftp.username}}" +
"&password={{shuttle.ftp.password}}" +
"&allowNullBody=false" +
"&consumer.bridgeErrorHandler=true" +
"&throwExceptionOnConnectFailed=true" +
"&pollStrategy=#defaultPollStrategy";
from("{{shuttle.outgoing.transactions}}")
.routeId("Sending-SHUTTLE-FTP")
.autoStartup("{{shuttle.ftp.outgoing.startup}}")
.wireTap("seda:ping")
.to(toStr)
.log("XML file(s) sent")
.end();
What I’d like is to have the option to have our DEV environment setup using say
FTP but in INTEGRATION and PROD it will be SFTP. Since the endpointDSL is
somewhat “hardcoding” the endpoint I don’t really know how to do it
Thx
M
Camel Endpoint DSL
Hi
How can I combine the endpoint DSL with dynamic property definitions such as:
final String toStr = "{{shuttle.ftp.outgoing.url}}" +
"&username={{shuttle.ftp.username}}" +
"&password={{shuttle.ftp.password}}" +
"&allowNullBody=false" +
"&consumer.bridgeErrorHandler=true" +
"&throwExceptionOnConnectFailed=true" +
"&pollStrategy=#defaultPollStrategy";
from("{{shuttle.outgoing.transactions}}")
.routeId("Sending-SHUTTLE-FTP")
.autoStartup("{{shuttle.ftp.outgoing.startup}}")
.wireTap("seda:ping")
.to(toStr)
.log("XML file(s) sent")
.end();
What I’d like is to have the option to have our DEV environment setup using say
FTP but in INTEGRATION and PROD it will be SFTP. Since the endpointDSL is
somewhat “hardcoding” the endpoint I don’t really know how to do it
Thx
M
