Camel headers are only used if you have configured the CXFRS Component with
simple binding style. If not using SimpleConsumer, then you need to
construct the headers in the JAX-RS Response, set in the body.
--
View this message in context:
http://camel.465427.n5.nabble.com/Setting-custom-http-h
code auto-format.)
To keep the long rant short, I had a crack at a /Groovier DSL/ for Camel.
https://github.com/sohrab-/camel-groovier
I appreciate some feedback to see if there is enough interest for such a
thing or not.
--
View this message in context:
http://camel.465427.n5.nabble.com/Came
Thanks Tomo. That actually makes sense.
So the notifications are bound to the exchange lifecycle, not what the route
is processing.
I think I may have also got a bit confused since I thought ordering did not
matter any more because of this JIRA item but now re-reading it and looking
at the actual
I've read the page on NotifyBuilder but I don't think I really understood how
it works. So I wrote below test case to verify it. The results confound me.
(The Groovy script is standalone and fully functioning so feel free to run
it locally.)
Code
===
@Grab(group='org.apache.camel', module = 'cam
Yeah it is hard one to replicate but once you do, it happens consistently.
I actually got to the bottom of this. So according to the OSGi spec, the
"entries" inside a bundle are returned in the order they were originally
attached:
https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html#
determines the order in the Set.
Why do I think this? Because the created test-bundle uses the absolute path
of blueprint XML for their names:
blueprint--Users-sohrab-workspaces-client-service-payment-card-v1-target-resources-main-OSGI-INF-blueprint-2-camel-context.xml
blueprint--Users-sohrab-
I should make a correction here. I just found out using "target" directory
resolves the issues in almost all scenarios (e.g. on our build server and
most development machines). But even with this fix, I am able reproduce the
issue on some development machines still.
*On those machines, the work-ar
I have found a weird/funny bug with CamelBlueprintTestSupport, I thought I
share. I briefly looked at the source code but cannot see any obvious
culprit so I thought I post it here if anyone feels like a challenge.
Basically when I git-clone a project in a directory that is at most 5 levels
deep f
This item was raised with the Red Hat guys where we were told that using
doesn't decrypt the messages inside Camel
Context (works only in Blueprint beans):
https://issues.jboss.org/browse/ENTESB-5482
So I am a little confuse when I look at this sample:
https://github.com/apache/camel/blob/maste
I am not sure what is the reasoning behind stripping '__c' from the enum
class names when generating DTOs in camel-salesforce:
https://github.com/apache/camel/blob/master/components/camel-salesforce/camel-salesforce-maven-plugin/src/main/java/org/apache/camel/maven/CamelSalesforceMojo.java#L698
B
in is implied, eg so you only use -out if you really need to
>> configure it differently.
>>
>
> Yeah that naming of yours makes definitley much more sense, thanks!
>
> Sohrab, please go ahead and raise a JIRA ticket pointing to this thread in
> Nabble.
>
> Babak
>
ystem.out.println(third != first); // true
> System.out.println(fourth != first); // true
>
> If interested, looking into the different implementations of Camel’s
> DataFormatResolver should clarify this to you, specially the
> DefaultDataFormatResolver one.
>
> Babak
&g
I was just looking through the latest code for
org.apache.camel.model.rest.RestBindingDefinition and I am not quite sure
how this works so I'd appreciate if someone can explain it to me.
createProcessor() method looks up both JSON data formats using the same
name:
DataFormat json = context.resol
13 matches
Mail list logo
