Re: Message blocks route until all redelivery attempts are exhausted

[javfindly]

Whoever is facing this problem and cannot use async schedulling because the
endpoint is transacted, I've came up with a workaround, in my case I'm using
RabbitMQ as the from Endpoint:

This is my route configuration:

from(fromEndpoint) // AMQP INPUT QUEUE
.routeId(consumerRouteId)
.to(DIRECT_SEND_DESTINATION);

from(retryEndpoint) //AMQP RETRY QUEUE
.errorHandler(deadLetterChannel) // a Dead Letter Channel with
Redelivery configuration
.routeId(retryRouteid)
.setHeader(MESSAGE_RETRY_HEADER, constant(true))
.to(DIRECT_SEND_DESTINATION);

from(DIRECT_SEND_DESTINATION) // Direct endpoints that work as a
funnel between the Input and Retry queue
.doTry()
...
.process(sendToDestinationProcessor) //If this throws an
exception we will decide what to do in the catch
...
.doCatch(Exception.class)
.process(redeliveryExceptionRethrowProcessor)
.to(retryEndpoint) // Is the first time we hear about this
message, so we send (the original) to the retry queue
.end();

And the redeliveryExceptionRethrowProcessor will decide if it needs to
rethrow the exception or not based on a header that is present just in the
Retry Messages. Note that the retryEndpoint route has the errorHandler
configuration, so it will handle redelivery from that queue only, not from
the Input queue.
This way, redelivery attempts are not blocking anymore, and we don't use an
async scheduler where messages can be lost in case of an outage.

public class RedeliveryExceptionRethrowProcessor implements Processor {

private final String header;

public RedeliveryExceptionRethrowProcessor(String header) {
this.header = header;
}

@Override
public void process(Exchange exchange) throws Exception {
Boolean rethrowException = exchange.getIn().getHeader(header,
Boolean.class);
if (rethrowException != null && rethrowException) {
throw exchange.getProperty(Exchange.EXCEPTION_CAUGHT,
Exception.class);
}
exchange.setIn(exchange.getUnitOfWork().getOriginalInMessage());
}

}

//If we are not rethrowing the exception, is the first time we see this
message, so it's going to be sent to the retry queue.
//For it to work, we need to use the original message, so any changes in the
exchange while trying to process it would be ignored



--
View this message in context: 
http://camel.465427.n5.nabble.com/Message-blocks-route-until-all-redelivery-attempts-are-exhausted-tp472319p5784827.html
Sent from the Camel - Users mailing list archive at Nabble.com.

RestConfguration component works in Blueprint, OSGI but Not In UnitTest

[andrewhlk]

Hi,

I have created a blueprint definition with a REST web service component in
the src/main/resources/OSGI-INF/blueprint folder.

It works fine when deployed in the Karaf OSGI platform.


It was all good until I started to unit test the route. The junit complains
about bean not found RestConsumerFactory. From the git repo, I found out it
requires an concrete class that implements the interface
RestConsumerFactory. So, the blueprint definition needs to be updated to
include the new bean that implements RestConsumerFactory. In order to run
the unit test, I use
org.apache.camel.test.blueprint.component.rest.DummyRestConsumerFactory. 

But the question is - Do I need to implement my own concrete class, add the
bean in the blueprint definition and deployed to Karaf OSGI ? If yes, why is
it necessary since it is already working with the RestConsumerFactory
implementation?

TIA. I am new to the camel & the unit testing.

Andrew







--
View this message in context: 
http://camel.465427.n5.nabble.com/RestConfguration-component-works-in-Blueprint-OSGI-but-Not-In-UnitTest-tp5784826.html
Sent from the Camel - Users mailing list archive at Nabble.com.

SQL jdbc resultSet streaming with blueprint XML

[rajach1...@gmail.com]

Hi,

I am using SQL JDBC  with Camel blueprint XML.I am new of blue print XML. I
want to stream the JDBC resultSet database by
using blueprint XML. Could you please suggest the solution.

The below is the select statement and currently reading from database
readSize is "25000"



how to stream the high volume data from SQL JDBC database. 



--
View this message in context: 
http://camel.465427.n5.nabble.com/SQL-jdbc-resultSet-streaming-with-blueprint-XML-tp5784810.html
Sent from the Camel - Users mailing list archive at Nabble.com.

SQL jdbc resultSet streaming with blueprint XML

[rajach1...@gmail.com]

Hi,

I am using SQL JDBC  with Camel blueprint XML.I am new of blue print XML. I
want to stream the JDBC resultSet database by
using blueprint XML. Could you please suggest the solution.

The below is the select statement and currently reading from database
readSize is "25000"



how to stream the high volume data from SQL JDBC database. 



--
View this message in context: 
http://camel.465427.n5.nabble.com/SQL-jdbc-resultSet-streaming-with-blueprint-XML-tp5784809.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Unit test case for XML DSL context and routes

[Tadayoshi Sato]

Hi,

Have you checked CamelSpringTestSupport?
http://camel.apache.org/spring-testing.html

You can specify the Camel context XML under test by simply overriding the
createApplicationContext method:

protected AbstractXmlApplicationContext createApplicationContext() {
return new
ClassPathXmlApplicationContext("META-INF/spring/your-context.xml");
}

If you are using Blueprint XML then you can refer
to CamelBlueprintTestSupport.

On Tue, Jul 5, 2016 at 11:23 PM, Vanshul.Chawla 
wrote:

> Thanks.
>
> I have seen this link.
>
> I had some doubts. I have camelcontext.xml which gets message from MQ and
> transforms and sends to a webservice, gets a response and then transforms
> and send back to another queue.
> I can mock the end points and can assert based on conditions etc.
>
> How to tell my test case class that I am using which camelcontext.xml? ie
> how to bind test case and xml together?
>
> -Original Message-
> From: Steve Huston [mailto:shus...@riverace.com]
> Sent: Tuesday, July 05, 2016 9:17 AM
> To: users@camel.apache.org
> Subject: RE: Unit test case for XML DSL context and routes
>
> http://camel.apache.org/testing.html
>
> > -Original Message-
> > From: Vanshul.Chawla [mailto:vanshul.cha...@target.com]
> > Sent: Tuesday, July 05, 2016 10:08 AM
> > To: users@camel.apache.org
> > Subject: Unit test case for XML DSL context and routes
> >
> > Hello All,
> >
> > We have some Camel code which is written in XML DSL. We need to add
> > unit test cases for each context(multiple routes) . Could someone
> > please give a lead to how this can be achieved.
> >
> > Vanshul
>
>

Re: Error occurred during starting Camel because of cannot look up a processor from registry

[Tadayoshi Sato]

Hi Debraj,

Then why can you not define jsonRPCProcessor in camelContext.xml instead of
blueprint.xml?  If this processor depends on a specific producer template
("myTemplate") == Camel context, then I see no reasons this producer can be
shared across multiple Camel contexts.

On Tue, Jul 5, 2016 at 8:01 PM, Debraj Manna 
wrote:

> Yeah Tadayoshi. jsonRPCProcessor is using myTemplate as shown below:-
>
> 
> class="com.j1.orchestratorservice.basecomponent.processor.JSONRPCProcessor">
> 
> 
> 
> 
>  value-ref="createProductsWFInfo" />
> 
> 
> 
> 
>
>
> whereas myTemplate is defined in camelContext which in turn is using
> jsonRPCProcessor as shown below:-
>
> http://camel.apache.org/schema/blueprint";
> useMDCLogging="true">
> 
> 
> http://0.0.0.0:/orchestratorservice"; />
> 
> 
> 
> 
> uri="jetty:
> http://0.0.0.0:8889/fileuploadservice?enableMultipartFilter=true";
> />
> 
> 
> ...
> 
>
>
> I have tried to set the producer in my custom jsonRPCProcessor as mentioned
> in this link
> <
> http://camel.apache.org/how-do-i-write-a-custom-processor-which-sends-multiple-messages.html
> >.
> Can someone suggest me some other way of setting the producer in my custom
> jsonRPCProcessor so that it does not lead to any circular dependency?
>
> On Tue, Jul 5, 2016 at 8:21 AM, Tadayoshi Sato 
> wrote:
>
> > Hi,
> >
> > It looks like 'myTemplate' is defined in camelContext.xml, but the Camel
> > context then refers to 'jsonRPCProcessor' in blueprint.xml, which in
> turns
> > refers to 'myTemplate'. That should be the cyclic dependency in question.
> >
> > Hope this helps,
> >
> > Tadayoshi
> >
> > On Mon, Jul 4, 2016 at 10:27 PM, Debraj Manna 
> > wrote:
> >
> > > It seems the error is getting triggered because of some cyclic
> > dependency.
> > > But I am not able to figure out from the trace what is causing the
> cyclic
> > > dependency.
> > >
> > > On Jul 4, 2016 4:22 PM, "Debraj Manna" 
> wrote:
> > >
> > > > On placing a bundle (using camel) on Karaf I am seeing the below
> > > > exception. The below exception comes only when the bundle is started.
> > > After
> > > > that everything works fine. The exeception does not seem to effect
> our
> > > > functionality. The issue is coming on both camel 2.16.1 (deployed on
> > > servicemix
> > > > 6.1.0) and camel 2.16.3 (deployed on servicemix 7.0.0M2).
> > > >
> > > > My blueprint is split into three files. A simplified version of them
> > are
> > > > shown below:-
> > > >
> > > >
> > > >1. blueprint.xml placed here
> > > ><
> > > https://gist.github.com/debraj-manna/42294561b9da22ce2281e6a9f3b22a34>
> > > >.
> > > >2. productBeans.xml placed here
> > > ><
> > > https://gist.github.com/debraj-manna/5c406f597f8b7248369b206ed1f93842>
> > > >.
> > > >3. camelContext.xml placed here
> > > ><
> > > https://gist.github.com/debraj-manna/4210653d661beaee6beb87900c4f4911>
> > > >.
> > > >
> > > >
> > > > Can some please let me know why is this exception coming during
> bundle
> > > > start?
> > > >
> > > > The exception looks like below:-
> > > >
> > > > 2016-07-04 11:29:37,497 | ERROR | mix-6.1.0/deploy |
> > > BlueprintCamelContext
> > > >| 143 - org.apache.camel.camel-blueprint - 2.16.1 | {{
> > > bundle.id
> > > > ,143}{bundle.name
> > > ,org.apache.camel.camel-blueprint}{bundle.version,2.16.1}}
> > > > | Error occurred during starting Camel: CamelContext(camel-1) due
> > Failed
> > > to
> > > > create route orchestrator-service-route at: >>>
> > > > process[ref:jsonRPCProcessor] <<< in route:
> > > > Route(orchestrator-service-route)[[From[jetty:http://0.0.0.0...
> > because
> > > > of Cannot lookup: jsonRPCProcessor from registry:
> > > > org.apache.camel.blueprint.BlueprintContainerRegistry@7b081b97 with
> > > > expected type: interface org.apache.camel.Processor due:
> > > > [BeanRecipe[name='myTemplate'],
> > > > BeanRecipe[name='.camelBlueprint.bean.factory.myTemplate'],
> > > > BeanRecipe[name='camel-1'], BeanRecipe[name='myTemplate']]
> > > > org.apache.camel.FailedToCreateRouteException: Failed to create route
> > > > orchestrator-service-route at: >>> process[ref:jsonRPCProcessor] <<<
> in
> > > > route: Route(orchestrator-service-route)[[From[jetty:http://0.0.0.0.
> ..
> > > > because of Cannot lookup: jsonRPCProcessor from registry:
> > > > org.apache.camel.blueprint.BlueprintContainerRegistry@7b081b97 with
> > > > expected type: interface org.apache.camel.Processor due:
> > > > [BeanRecipe[name='myTemplate'],
> > > > BeanRecipe[name='.camelBlueprint.bean.factory.myTemplate'],
> > > > BeanRecipe[name='camel-1'], BeanRecipe[name='myTemplate']]
> > > > at
> > > >
> > >
> >
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1072)
> > > > at
> > > >
> > >
> >
> org.apache.camel.model.RouteDefinition.addRoutes(Rout

Re: Is it possible to make a message header or property immutable?

[Matt Sicker]

I actually used to use CXFRS in this application (you can still see
remnants of it like using the header "operationName" to route from a REST
endpoint to an ActiveMQ queue). Even if I used an immutable bean in the
header, that bean could still be replaced. It seems like the only way to
implement a truly immutable header or property would be an addition to the
camel-core API, and I'm not so sure if such a feature would be accepted.

On 5 July 2016 at 18:20, Brad Johnson  wrote:

> I've always used CXFRS so don't have any experience with the REST DSL
> itself. With CXFRS I usually end up binding everything to the data object
> when it first comes in and that does remain immutable so I don't end up
> working with headers for any data elements. By using the same interface for
> both my SOAP and REST and binding it this way.  The only requirement then
> is that the data bean have @XmlRootElement specified so that JAXB knows how
> to handle it. For the routing I then use the recipientList along with the
> method name so that it is disconnected from either SOAP or REST.  I'm
> making this example up off the top of my head so don't hold me to the
> specifics.
>
> @WebMethod(operationName = "updateContact", action = "")
> @WebResult(name = "Contact", targetNamespace = "")
> @PUT
> @Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
> @Consumes({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
> @Path("contact/{firstName}")
> public Contact updateContact(Contact contact) {
>   ...
> }
>
> Then in the CXF blueprint file I'll put something like this:
>
> 
> direct-vm:${header.operationName}
> 
>
>
> In this case when that interface is invoked it equates to the defined
> "operationName" on a direct-VM but that could be any transport.
>
> So calling that method invokes direct-vm:updateContact and that's where I
> start the route handling.  But by that time the data is firmly bound to the
> bean and is not mutable.
>
>  But you could, at the very least, create wrapper class with immutable
> fields on it that you could instantiate and save in the header as the first
> step in the process.  That would prevent any modification of those
> variables and at least help in debugging when something goes wrong.  Why
> didn't this go where it was supposed to?  Catch the exception and then pull
> the original bean with immutable fields and see what it says the values
> should be compared to what they currently are.
>
> It sounds like this is going to be a case where you're going to have to
> rely on some fairly rigorous testing to make sure nobody is doing anything
> stoopid.
>
>
> On Tue, Jul 5, 2016 at 4:03 PM, Matt Sicker  wrote:
>
> > Let me give a more specific use case. Path parameters from rest-dsl are
> > passed in as message headers. I don't want any route to accidentally
> > overwrite or modify those headers as they're useful for the entire
> > lifecycle of that message.
> >
> > On 5 July 2016 at 16:00, Matt Sicker  wrote:
> >
> > > The exact use case is preventing developers from [inadvertently]
> > modifying
> > > headers or properties that are used before and after a particular
> > subroute.
> > >
> > > On 5 July 2016 at 15:57, souciance 
> > > wrote:
> > >
> > >> I guess the question is, why would different routes split over
> different
> > >> bundles want to write over the same header/property? What's the case
> > here?
> > >> Surely it cannot be just to prevent accidents by developers because
> what
> > >> would be their reason to write over that header?
> > >>
> > >> I think it is better to agree on a naming and some sort of other
> > >> convention
> > >> and stick to that because I don't think there is a way to to make a
> > header
> > >> immutable. I guess an ugly solution would be to save the header in a
> map
> > >> and give the key name something very unique.
> > >>
> > >> On Tue, Jul 5, 2016 at 10:48 PM, Matt Sicker [via Camel] <
> > >> ml-node+s465427n578481...@n5.nabble.com> wrote:
> > >>
> > >> > Please let me know if you think of anything!
> > >> >
> > >> > On 5 July 2016 at 15:16, Brad Johnson <[hidden email]
> > >> > > wrote:
> > >> >
> > >> > > I certainly understand the impulse and think it is spot on but
> can't
> > >> > think
> > >> > > of how to do it with headers.  Claim checks might work but they
> are
> > >> > really
> > >> > > for reducing overhead of data and not for locking like that but
> that
> > >> > might
> > >> > > be a viable solution depending on the exact problem.
> > >> > >
> > >> > > Thanks Matt, this is going to be stuck in my head now.  I'll
> > probably
> > >> > dream
> > >> > > of an answer of some sort tonight.
> > >> > >
> > >> > > Brad
> > >> > >
> > >> > > On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker <[hidden email]
> > >> > > wrote:
> > >> > >
> > >> > > > My use case is basically to help prevent bugs where a header or
> > >> > exchange
> > >> > > 

Re: Is it possible to make a message header or property immutable?

[Brad Johnson]

I've always used CXFRS so don't have any experience with the REST DSL
itself. With CXFRS I usually end up binding everything to the data object
when it first comes in and that does remain immutable so I don't end up
working with headers for any data elements. By using the same interface for
both my SOAP and REST and binding it this way.  The only requirement then
is that the data bean have @XmlRootElement specified so that JAXB knows how
to handle it. For the routing I then use the recipientList along with the
method name so that it is disconnected from either SOAP or REST.  I'm
making this example up off the top of my head so don't hold me to the
specifics.

@WebMethod(operationName = "updateContact", action = "")
@WebResult(name = "Contact", targetNamespace = "")
@PUT
@Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
@Consumes({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
@Path("contact/{firstName}")
public Contact updateContact(Contact contact) {
  ...
}

Then in the CXF blueprint file I'll put something like this:


direct-vm:${header.operationName}



In this case when that interface is invoked it equates to the defined
"operationName" on a direct-VM but that could be any transport.

So calling that method invokes direct-vm:updateContact and that's where I
start the route handling.  But by that time the data is firmly bound to the
bean and is not mutable.

 But you could, at the very least, create wrapper class with immutable
fields on it that you could instantiate and save in the header as the first
step in the process.  That would prevent any modification of those
variables and at least help in debugging when something goes wrong.  Why
didn't this go where it was supposed to?  Catch the exception and then pull
the original bean with immutable fields and see what it says the values
should be compared to what they currently are.

It sounds like this is going to be a case where you're going to have to
rely on some fairly rigorous testing to make sure nobody is doing anything
stoopid.


On Tue, Jul 5, 2016 at 4:03 PM, Matt Sicker  wrote:

> Let me give a more specific use case. Path parameters from rest-dsl are
> passed in as message headers. I don't want any route to accidentally
> overwrite or modify those headers as they're useful for the entire
> lifecycle of that message.
>
> On 5 July 2016 at 16:00, Matt Sicker  wrote:
>
> > The exact use case is preventing developers from [inadvertently]
> modifying
> > headers or properties that are used before and after a particular
> subroute.
> >
> > On 5 July 2016 at 15:57, souciance 
> > wrote:
> >
> >> I guess the question is, why would different routes split over different
> >> bundles want to write over the same header/property? What's the case
> here?
> >> Surely it cannot be just to prevent accidents by developers because what
> >> would be their reason to write over that header?
> >>
> >> I think it is better to agree on a naming and some sort of other
> >> convention
> >> and stick to that because I don't think there is a way to to make a
> header
> >> immutable. I guess an ugly solution would be to save the header in a map
> >> and give the key name something very unique.
> >>
> >> On Tue, Jul 5, 2016 at 10:48 PM, Matt Sicker [via Camel] <
> >> ml-node+s465427n578481...@n5.nabble.com> wrote:
> >>
> >> > Please let me know if you think of anything!
> >> >
> >> > On 5 July 2016 at 15:16, Brad Johnson <[hidden email]
> >> > > wrote:
> >> >
> >> > > I certainly understand the impulse and think it is spot on but can't
> >> > think
> >> > > of how to do it with headers.  Claim checks might work but they are
> >> > really
> >> > > for reducing overhead of data and not for locking like that but that
> >> > might
> >> > > be a viable solution depending on the exact problem.
> >> > >
> >> > > Thanks Matt, this is going to be stuck in my head now.  I'll
> probably
> >> > dream
> >> > > of an answer of some sort tonight.
> >> > >
> >> > > Brad
> >> > >
> >> > > On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker <[hidden email]
> >> > > wrote:
> >> > >
> >> > > > My use case is basically to help prevent bugs where a header or
> >> > exchange
> >> > > > property gets modified. Some of my routes in question branch out
> >> into
> >> > > > several different bundles, and it is difficult to enforce
> contracts
> >> > that
> >> > > > way amongst several developers with varying levels of Camel
> >> expertise.
> >> > > > Similar to how one might use final variables to prevent people
> from
> >> > > > reassigning them, this could be a final header that prevents
> people
> >> > from
> >> > > > reusing them for things.
> >> > > >
> >> > > > On 5 July 2016 at 14:22, Brad Johnson <[hidden email]
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > > > That's what I figured.  I'd have to look at the M

camel-example-spring-boot-metrics

[Camel Guy]

Hello,

I have a Graphite server running and tested.
camel-example-spring-boot-metrics' Application.java settings are correct
for my installation.

When I run the example and look at the Graphite dashboard, I don't see any
metrics related to camel-example-spring-boot-metrics. Where should I look?

Also, two more questions:

1) Is this an example of the metrics component (
http://camel.apache.org/metrics-component.html) with the data being sent to
Graphite instead of, say, Hawtio?

2) Should I build a graphite component so I can send app-specific metrics
to Graphite? Has this already been done?


Thank you,
~cg

Re: Is it possible to make a message header or property immutable?

[Matt Sicker]

Let me give a more specific use case. Path parameters from rest-dsl are
passed in as message headers. I don't want any route to accidentally
overwrite or modify those headers as they're useful for the entire
lifecycle of that message.

On 5 July 2016 at 16:00, Matt Sicker  wrote:

> The exact use case is preventing developers from [inadvertently] modifying
> headers or properties that are used before and after a particular subroute.
>
> On 5 July 2016 at 15:57, souciance 
> wrote:
>
>> I guess the question is, why would different routes split over different
>> bundles want to write over the same header/property? What's the case here?
>> Surely it cannot be just to prevent accidents by developers because what
>> would be their reason to write over that header?
>>
>> I think it is better to agree on a naming and some sort of other
>> convention
>> and stick to that because I don't think there is a way to to make a header
>> immutable. I guess an ugly solution would be to save the header in a map
>> and give the key name something very unique.
>>
>> On Tue, Jul 5, 2016 at 10:48 PM, Matt Sicker [via Camel] <
>> ml-node+s465427n578481...@n5.nabble.com> wrote:
>>
>> > Please let me know if you think of anything!
>> >
>> > On 5 July 2016 at 15:16, Brad Johnson <[hidden email]
>> > > wrote:
>> >
>> > > I certainly understand the impulse and think it is spot on but can't
>> > think
>> > > of how to do it with headers.  Claim checks might work but they are
>> > really
>> > > for reducing overhead of data and not for locking like that but that
>> > might
>> > > be a viable solution depending on the exact problem.
>> > >
>> > > Thanks Matt, this is going to be stuck in my head now.  I'll probably
>> > dream
>> > > of an answer of some sort tonight.
>> > >
>> > > Brad
>> > >
>> > > On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker <[hidden email]
>> > > wrote:
>> > >
>> > > > My use case is basically to help prevent bugs where a header or
>> > exchange
>> > > > property gets modified. Some of my routes in question branch out
>> into
>> > > > several different bundles, and it is difficult to enforce contracts
>> > that
>> > > > way amongst several developers with varying levels of Camel
>> expertise.
>> > > > Similar to how one might use final variables to prevent people from
>> > > > reassigning them, this could be a final header that prevents people
>> > from
>> > > > reusing them for things.
>> > > >
>> > > > On 5 July 2016 at 14:22, Brad Johnson <[hidden email]
>> > >
>> > > > wrote:
>> > > >
>> > > > > That's what I figured.  I'd have to look at the Map implementation
>> > of
>> > > the
>> > > > > exchange but as far as I know there isn't a way to make it a write
>> > once
>> > > > > only operation.  It's just a map of some sort.  There might be a
>> way
>> > to
>> > > > do
>> > > > > it with transactions but I'm not an expert there.  I generally use
>> > > > headers
>> > > > > but in reality should probably be using exchange properties more
>> > often.
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel
>> > > > >
>> > > > > Almost any mechanism I can think of off the top of my head could
>> be
>> > > > > subverted by someone who wanted to or who didn't understand that
>> the
>> > > > value
>> > > > > associated with the bean shouldn't be modified.  For example, you
>> > could
>> > > > > create a bean that you associate with your header that stores data
>> > but
>> > > > also
>> > > > > returns a UUID.  That UUID could be stored in another header and
>> > > sometime
>> > > > > later in the routes you could verify that the bean stored under
>> your
>> > > key
>> > > > > returns the same UUID as the header indicates.  But that wouldn't
>> > stop
>> > > > > someone from changing the bean stored to the key and it wouldn't
>> > > prevent
>> > > > > them from updating the UUID to a new bean they might create.
>> > > > >
>> > > > > On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker <[hidden email]
>> > > wrote:
>> > > > >
>> > > > > > I'm thinking of an idea to prevent a header from being modified
>> by
>> > > > other
>> > > > > > parts of the route. A sort of contract if you will.
>> > > > > >
>> > > > > > On 5 July 2016 at 13:01, Brad Johnson <[hidden email]
>> > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Is there another part of your process that is specifically
>> > changing
>> > > > the
>> > > > > > > header or are you more concerned about it being consistently
>> > there
>> > > > > across
>> > > > > > > routes?  Nothing will change it automatically if it is your
>> > header.
>> > > > I
>> > > > > > > don't remember the actual implementation but conceptua

Re: Is it possible to make a message header or property immutable?

[Matt Sicker]

The exact use case is preventing developers from [inadvertently] modifying
headers or properties that are used before and after a particular subroute.

On 5 July 2016 at 15:57, souciance  wrote:

> I guess the question is, why would different routes split over different
> bundles want to write over the same header/property? What's the case here?
> Surely it cannot be just to prevent accidents by developers because what
> would be their reason to write over that header?
>
> I think it is better to agree on a naming and some sort of other convention
> and stick to that because I don't think there is a way to to make a header
> immutable. I guess an ugly solution would be to save the header in a map
> and give the key name something very unique.
>
> On Tue, Jul 5, 2016 at 10:48 PM, Matt Sicker [via Camel] <
> ml-node+s465427n578481...@n5.nabble.com> wrote:
>
> > Please let me know if you think of anything!
> >
> > On 5 July 2016 at 15:16, Brad Johnson <[hidden email]
> > > wrote:
> >
> > > I certainly understand the impulse and think it is spot on but can't
> > think
> > > of how to do it with headers.  Claim checks might work but they are
> > really
> > > for reducing overhead of data and not for locking like that but that
> > might
> > > be a viable solution depending on the exact problem.
> > >
> > > Thanks Matt, this is going to be stuck in my head now.  I'll probably
> > dream
> > > of an answer of some sort tonight.
> > >
> > > Brad
> > >
> > > On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker <[hidden email]
> > > wrote:
> > >
> > > > My use case is basically to help prevent bugs where a header or
> > exchange
> > > > property gets modified. Some of my routes in question branch out into
> > > > several different bundles, and it is difficult to enforce contracts
> > that
> > > > way amongst several developers with varying levels of Camel
> expertise.
> > > > Similar to how one might use final variables to prevent people from
> > > > reassigning them, this could be a final header that prevents people
> > from
> > > > reusing them for things.
> > > >
> > > > On 5 July 2016 at 14:22, Brad Johnson <[hidden email]
> > >
> > > > wrote:
> > > >
> > > > > That's what I figured.  I'd have to look at the Map implementation
> > of
> > > the
> > > > > exchange but as far as I know there isn't a way to make it a write
> > once
> > > > > only operation.  It's just a map of some sort.  There might be a
> way
> > to
> > > > do
> > > > > it with transactions but I'm not an expert there.  I generally use
> > > > headers
> > > > > but in reality should probably be using exchange properties more
> > often.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel
> > > > >
> > > > > Almost any mechanism I can think of off the top of my head could be
> > > > > subverted by someone who wanted to or who didn't understand that
> the
> > > > value
> > > > > associated with the bean shouldn't be modified.  For example, you
> > could
> > > > > create a bean that you associate with your header that stores data
> > but
> > > > also
> > > > > returns a UUID.  That UUID could be stored in another header and
> > > sometime
> > > > > later in the routes you could verify that the bean stored under
> your
> > > key
> > > > > returns the same UUID as the header indicates.  But that wouldn't
> > stop
> > > > > someone from changing the bean stored to the key and it wouldn't
> > > prevent
> > > > > them from updating the UUID to a new bean they might create.
> > > > >
> > > > > On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker <[hidden email]
> > > wrote:
> > > > >
> > > > > > I'm thinking of an idea to prevent a header from being modified
> by
> > > > other
> > > > > > parts of the route. A sort of contract if you will.
> > > > > >
> > > > > > On 5 July 2016 at 13:01, Brad Johnson <[hidden email]
> > >
> > > > > > wrote:
> > > > > >
> > > > > > > Is there another part of your process that is specifically
> > changing
> > > > the
> > > > > > > header or are you more concerned about it being consistently
> > there
> > > > > across
> > > > > > > routes?  Nothing will change it automatically if it is your
> > header.
> > > > I
> > > > > > > don't remember the actual implementation but conceptually it is
> > > just
> > > > a
> > > > > > > hastable/map with key/values.  If you set header with some
> > specific
> > > > key
> > > > > > > then nothing else will change it.
> > > > > > >
> > > > > > > As an example, I use a camel splitter and then set a header
> with
> > > the
> > > > > > > splitter index so that I can use it in another route later to
> > > > > reassemble
> > > > > > > with the resequencer.

Re: Is it possible to make a message header or property immutable?

[souciance]

I guess the question is, why would different routes split over different
bundles want to write over the same header/property? What's the case here?
Surely it cannot be just to prevent accidents by developers because what
would be their reason to write over that header?

I think it is better to agree on a naming and some sort of other convention
and stick to that because I don't think there is a way to to make a header
immutable. I guess an ugly solution would be to save the header in a map
and give the key name something very unique.

On Tue, Jul 5, 2016 at 10:48 PM, Matt Sicker [via Camel] <
ml-node+s465427n578481...@n5.nabble.com> wrote:

> Please let me know if you think of anything!
>
> On 5 July 2016 at 15:16, Brad Johnson <[hidden email]
> > wrote:
>
> > I certainly understand the impulse and think it is spot on but can't
> think
> > of how to do it with headers.  Claim checks might work but they are
> really
> > for reducing overhead of data and not for locking like that but that
> might
> > be a viable solution depending on the exact problem.
> >
> > Thanks Matt, this is going to be stuck in my head now.  I'll probably
> dream
> > of an answer of some sort tonight.
> >
> > Brad
> >
> > On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker <[hidden email]
> > wrote:
> >
> > > My use case is basically to help prevent bugs where a header or
> exchange
> > > property gets modified. Some of my routes in question branch out into
> > > several different bundles, and it is difficult to enforce contracts
> that
> > > way amongst several developers with varying levels of Camel expertise.
> > > Similar to how one might use final variables to prevent people from
> > > reassigning them, this could be a final header that prevents people
> from
> > > reusing them for things.
> > >
> > > On 5 July 2016 at 14:22, Brad Johnson <[hidden email]
> >
> > > wrote:
> > >
> > > > That's what I figured.  I'd have to look at the Map implementation
> of
> > the
> > > > exchange but as far as I know there isn't a way to make it a write
> once
> > > > only operation.  It's just a map of some sort.  There might be a way
> to
> > > do
> > > > it with transactions but I'm not an expert there.  I generally use
> > > headers
> > > > but in reality should probably be using exchange properties more
> often.
> > > >
> > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel
> > > >
> > > > Almost any mechanism I can think of off the top of my head could be
> > > > subverted by someone who wanted to or who didn't understand that the
> > > value
> > > > associated with the bean shouldn't be modified.  For example, you
> could
> > > > create a bean that you associate with your header that stores data
> but
> > > also
> > > > returns a UUID.  That UUID could be stored in another header and
> > sometime
> > > > later in the routes you could verify that the bean stored under your
> > key
> > > > returns the same UUID as the header indicates.  But that wouldn't
> stop
> > > > someone from changing the bean stored to the key and it wouldn't
> > prevent
> > > > them from updating the UUID to a new bean they might create.
> > > >
> > > > On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker <[hidden email]
> > wrote:
> > > >
> > > > > I'm thinking of an idea to prevent a header from being modified by
> > > other
> > > > > parts of the route. A sort of contract if you will.
> > > > >
> > > > > On 5 July 2016 at 13:01, Brad Johnson <[hidden email]
> >
> > > > > wrote:
> > > > >
> > > > > > Is there another part of your process that is specifically
> changing
> > > the
> > > > > > header or are you more concerned about it being consistently
> there
> > > > across
> > > > > > routes?  Nothing will change it automatically if it is your
> header.
> > > I
> > > > > > don't remember the actual implementation but conceptually it is
> > just
> > > a
> > > > > > hastable/map with key/values.  If you set header with some
> specific
> > > key
> > > > > > then nothing else will change it.
> > > > > >
> > > > > > As an example, I use a camel splitter and then set a header with
> > the
> > > > > > splitter index so that I can use it in another route later to
> > > > reassemble
> > > > > > with the resequencer.
> > > > > >
> > > > > > 
> > > > > > ${body}
> > > > > > 
> > > > > > exchangeProperty.CamelSplitIndex
> > > > > > 
> > > > > > ...
> > > > > >
> > > > > > The "seqnum" is just a key that I'm defining.  I could obviously
> > call
> > > > it
> > > > > > anything "sequenceNumber" or whatever but when I access it later
> > that
> > > > > > header is available on the exchange. If I explicitly change what
> > the
> > > > map
> > > > > is
> > > > > 

Re: Is it possible to make a message header or property immutable?

[Matt Sicker]

Please let me know if you think of anything!

On 5 July 2016 at 15:16, Brad Johnson  wrote:

> I certainly understand the impulse and think it is spot on but can't think
> of how to do it with headers.  Claim checks might work but they are really
> for reducing overhead of data and not for locking like that but that might
> be a viable solution depending on the exact problem.
>
> Thanks Matt, this is going to be stuck in my head now.  I'll probably dream
> of an answer of some sort tonight.
>
> Brad
>
> On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker  wrote:
>
> > My use case is basically to help prevent bugs where a header or exchange
> > property gets modified. Some of my routes in question branch out into
> > several different bundles, and it is difficult to enforce contracts that
> > way amongst several developers with varying levels of Camel expertise.
> > Similar to how one might use final variables to prevent people from
> > reassigning them, this could be a final header that prevents people from
> > reusing them for things.
> >
> > On 5 July 2016 at 14:22, Brad Johnson 
> > wrote:
> >
> > > That's what I figured.  I'd have to look at the Map implementation of
> the
> > > exchange but as far as I know there isn't a way to make it a write once
> > > only operation.  It's just a map of some sort.  There might be a way to
> > do
> > > it with transactions but I'm not an expert there.  I generally use
> > headers
> > > but in reality should probably be using exchange properties more often.
> > >
> > >
> > >
> >
> http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel
> > >
> > > Almost any mechanism I can think of off the top of my head could be
> > > subverted by someone who wanted to or who didn't understand that the
> > value
> > > associated with the bean shouldn't be modified.  For example, you could
> > > create a bean that you associate with your header that stores data but
> > also
> > > returns a UUID.  That UUID could be stored in another header and
> sometime
> > > later in the routes you could verify that the bean stored under your
> key
> > > returns the same UUID as the header indicates.  But that wouldn't stop
> > > someone from changing the bean stored to the key and it wouldn't
> prevent
> > > them from updating the UUID to a new bean they might create.
> > >
> > > On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker  wrote:
> > >
> > > > I'm thinking of an idea to prevent a header from being modified by
> > other
> > > > parts of the route. A sort of contract if you will.
> > > >
> > > > On 5 July 2016 at 13:01, Brad Johnson 
> > > > wrote:
> > > >
> > > > > Is there another part of your process that is specifically changing
> > the
> > > > > header or are you more concerned about it being consistently there
> > > across
> > > > > routes?  Nothing will change it automatically if it is your header.
> > I
> > > > > don't remember the actual implementation but conceptually it is
> just
> > a
> > > > > hastable/map with key/values.  If you set header with some specific
> > key
> > > > > then nothing else will change it.
> > > > >
> > > > > As an example, I use a camel splitter and then set a header with
> the
> > > > > splitter index so that I can use it in another route later to
> > > reassemble
> > > > > with the resequencer.
> > > > >
> > > > > 
> > > > > ${body}
> > > > > 
> > > > > exchangeProperty.CamelSplitIndex
> > > > > 
> > > > > ...
> > > > >
> > > > > The "seqnum" is just a key that I'm defining.  I could obviously
> call
> > > it
> > > > > anything "sequenceNumber" or whatever but when I access it later
> that
> > > > > header is available on the exchange. If I explicitly change what
> the
> > > map
> > > > is
> > > > > storing for "seqnum" then it will be different because I can't make
> > the
> > > > > header map itself immutable.
> > > > >
> > > > >
> > > > > On Tue, Jul 5, 2016 at 10:33 AM, Matt Sicker 
> > wrote:
> > > > >
> > > > > > As in once I set the header, nothing can change the header during
> > the
> > > > > > lifecycle of the message during a route. Same for an exchange
> > > property.
> > > > > >
> > > > > > --
> > > > > > Matt Sicker 
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker 
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: Is it possible to make a message header or property immutable?

[Brad Johnson]

I certainly understand the impulse and think it is spot on but can't think
of how to do it with headers.  Claim checks might work but they are really
for reducing overhead of data and not for locking like that but that might
be a viable solution depending on the exact problem.

Thanks Matt, this is going to be stuck in my head now.  I'll probably dream
of an answer of some sort tonight.

Brad

On Tue, Jul 5, 2016 at 3:02 PM, Matt Sicker  wrote:

> My use case is basically to help prevent bugs where a header or exchange
> property gets modified. Some of my routes in question branch out into
> several different bundles, and it is difficult to enforce contracts that
> way amongst several developers with varying levels of Camel expertise.
> Similar to how one might use final variables to prevent people from
> reassigning them, this could be a final header that prevents people from
> reusing them for things.
>
> On 5 July 2016 at 14:22, Brad Johnson 
> wrote:
>
> > That's what I figured.  I'd have to look at the Map implementation of the
> > exchange but as far as I know there isn't a way to make it a write once
> > only operation.  It's just a map of some sort.  There might be a way to
> do
> > it with transactions but I'm not an expert there.  I generally use
> headers
> > but in reality should probably be using exchange properties more often.
> >
> >
> >
> http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel
> >
> > Almost any mechanism I can think of off the top of my head could be
> > subverted by someone who wanted to or who didn't understand that the
> value
> > associated with the bean shouldn't be modified.  For example, you could
> > create a bean that you associate with your header that stores data but
> also
> > returns a UUID.  That UUID could be stored in another header and sometime
> > later in the routes you could verify that the bean stored under your key
> > returns the same UUID as the header indicates.  But that wouldn't stop
> > someone from changing the bean stored to the key and it wouldn't prevent
> > them from updating the UUID to a new bean they might create.
> >
> > On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker  wrote:
> >
> > > I'm thinking of an idea to prevent a header from being modified by
> other
> > > parts of the route. A sort of contract if you will.
> > >
> > > On 5 July 2016 at 13:01, Brad Johnson 
> > > wrote:
> > >
> > > > Is there another part of your process that is specifically changing
> the
> > > > header or are you more concerned about it being consistently there
> > across
> > > > routes?  Nothing will change it automatically if it is your header.
> I
> > > > don't remember the actual implementation but conceptually it is just
> a
> > > > hastable/map with key/values.  If you set header with some specific
> key
> > > > then nothing else will change it.
> > > >
> > > > As an example, I use a camel splitter and then set a header with the
> > > > splitter index so that I can use it in another route later to
> > reassemble
> > > > with the resequencer.
> > > >
> > > > 
> > > > ${body}
> > > > 
> > > > exchangeProperty.CamelSplitIndex
> > > > 
> > > > ...
> > > >
> > > > The "seqnum" is just a key that I'm defining.  I could obviously call
> > it
> > > > anything "sequenceNumber" or whatever but when I access it later that
> > > > header is available on the exchange. If I explicitly change what the
> > map
> > > is
> > > > storing for "seqnum" then it will be different because I can't make
> the
> > > > header map itself immutable.
> > > >
> > > >
> > > > On Tue, Jul 5, 2016 at 10:33 AM, Matt Sicker 
> wrote:
> > > >
> > > > > As in once I set the header, nothing can change the header during
> the
> > > > > lifecycle of the message during a route. Same for an exchange
> > property.
> > > > >
> > > > > --
> > > > > Matt Sicker 
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Matt Sicker 
> > >
> >
>
>
>
> --
> Matt Sicker 
>

Re: Is it possible to make a message header or property immutable?

[Matt Sicker]

My use case is basically to help prevent bugs where a header or exchange
property gets modified. Some of my routes in question branch out into
several different bundles, and it is difficult to enforce contracts that
way amongst several developers with varying levels of Camel expertise.
Similar to how one might use final variables to prevent people from
reassigning them, this could be a final header that prevents people from
reusing them for things.

On 5 July 2016 at 14:22, Brad Johnson  wrote:

> That's what I figured.  I'd have to look at the Map implementation of the
> exchange but as far as I know there isn't a way to make it a write once
> only operation.  It's just a map of some sort.  There might be a way to do
> it with transactions but I'm not an expert there.  I generally use headers
> but in reality should probably be using exchange properties more often.
>
>
> http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel
>
> Almost any mechanism I can think of off the top of my head could be
> subverted by someone who wanted to or who didn't understand that the value
> associated with the bean shouldn't be modified.  For example, you could
> create a bean that you associate with your header that stores data but also
> returns a UUID.  That UUID could be stored in another header and sometime
> later in the routes you could verify that the bean stored under your key
> returns the same UUID as the header indicates.  But that wouldn't stop
> someone from changing the bean stored to the key and it wouldn't prevent
> them from updating the UUID to a new bean they might create.
>
> On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker  wrote:
>
> > I'm thinking of an idea to prevent a header from being modified by other
> > parts of the route. A sort of contract if you will.
> >
> > On 5 July 2016 at 13:01, Brad Johnson 
> > wrote:
> >
> > > Is there another part of your process that is specifically changing the
> > > header or are you more concerned about it being consistently there
> across
> > > routes?  Nothing will change it automatically if it is your header.  I
> > > don't remember the actual implementation but conceptually it is just a
> > > hastable/map with key/values.  If you set header with some specific key
> > > then nothing else will change it.
> > >
> > > As an example, I use a camel splitter and then set a header with the
> > > splitter index so that I can use it in another route later to
> reassemble
> > > with the resequencer.
> > >
> > > 
> > > ${body}
> > > 
> > > exchangeProperty.CamelSplitIndex
> > > 
> > > ...
> > >
> > > The "seqnum" is just a key that I'm defining.  I could obviously call
> it
> > > anything "sequenceNumber" or whatever but when I access it later that
> > > header is available on the exchange. If I explicitly change what the
> map
> > is
> > > storing for "seqnum" then it will be different because I can't make the
> > > header map itself immutable.
> > >
> > >
> > > On Tue, Jul 5, 2016 at 10:33 AM, Matt Sicker  wrote:
> > >
> > > > As in once I set the header, nothing can change the header during the
> > > > lifecycle of the message during a route. Same for an exchange
> property.
> > > >
> > > > --
> > > > Matt Sicker 
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Aggregation Completion Criteria

[Vince Iglehart]

I need some assistance to make sure I'm on the right track.  I think I'm very
close, but I have a couple of missing pieces.  

I have the following SQL statement:
select ticket_date, ticket_nbr, line_nbr, item_desc, quantity
from tickets

I want to group these rows by ticket date, ticket nbr, and line nbr - such
that I will have xml similar to the following in the body of the message:



12345

1
Item desc 1
111


2
Item desc 2
222


3
Item desc 3
3



more tickets


more sales orders




>From what I understand, I would accomplish this as follows:

from("direct:start").routeId("Publish Ticket Data")
.to("sql:classpath:sql/SelectTicketInfo.sql?dataSource=myDataSource")

.split(body())
.setHeader("ticket_number", simple("${body.get(TICKET_NBR)}"))
.setHeader("ticket_date", simple("${body.get(TICKET_DATE)}"))

// build tickets by finding all line nbr's for that ticket
.aggregate(header("ticket_nbr"), new TicketAgg())

// build sales order by grouping tickets by ticket date
.aggregate(header("ticket_date"), new SalesOrderAgg())


// continue with more stuff


How do I specify a completion criteria such that I know the integration has
aggregated all records into the correct ticket?  After the tickets have been
created, how would I specify a completion criteria so that I know the
integration has aggregated all tickets into a sales order?  

Are there alternatives to accomplish this task?



--
View this message in context: 
http://camel.465427.n5.nabble.com/Aggregation-Completion-Criteria-tp5784806.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Is it possible to make a message header or property immutable?

[Brad Johnson]

That's what I figured.  I'd have to look at the Map implementation of the
exchange but as far as I know there isn't a way to make it a write once
only operation.  It's just a map of some sort.  There might be a way to do
it with transactions but I'm not an expert there.  I generally use headers
but in reality should probably be using exchange properties more often.

http://stackoverflow.com/questions/10330998/passing-values-between-processors-in-apache-camel

Almost any mechanism I can think of off the top of my head could be
subverted by someone who wanted to or who didn't understand that the value
associated with the bean shouldn't be modified.  For example, you could
create a bean that you associate with your header that stores data but also
returns a UUID.  That UUID could be stored in another header and sometime
later in the routes you could verify that the bean stored under your key
returns the same UUID as the header indicates.  But that wouldn't stop
someone from changing the bean stored to the key and it wouldn't prevent
them from updating the UUID to a new bean they might create.

On Tue, Jul 5, 2016 at 1:49 PM, Matt Sicker  wrote:

> I'm thinking of an idea to prevent a header from being modified by other
> parts of the route. A sort of contract if you will.
>
> On 5 July 2016 at 13:01, Brad Johnson 
> wrote:
>
> > Is there another part of your process that is specifically changing the
> > header or are you more concerned about it being consistently there across
> > routes?  Nothing will change it automatically if it is your header.  I
> > don't remember the actual implementation but conceptually it is just a
> > hastable/map with key/values.  If you set header with some specific key
> > then nothing else will change it.
> >
> > As an example, I use a camel splitter and then set a header with the
> > splitter index so that I can use it in another route later to reassemble
> > with the resequencer.
> >
> > 
> > ${body}
> > 
> > exchangeProperty.CamelSplitIndex
> > 
> > ...
> >
> > The "seqnum" is just a key that I'm defining.  I could obviously call it
> > anything "sequenceNumber" or whatever but when I access it later that
> > header is available on the exchange. If I explicitly change what the map
> is
> > storing for "seqnum" then it will be different because I can't make the
> > header map itself immutable.
> >
> >
> > On Tue, Jul 5, 2016 at 10:33 AM, Matt Sicker  wrote:
> >
> > > As in once I set the header, nothing can change the header during the
> > > lifecycle of the message during a route. Same for an exchange property.
> > >
> > > --
> > > Matt Sicker 
> > >
> >
>
>
>
> --
> Matt Sicker 
>

Re: Is it possible to make a message header or property immutable?

[Matt Sicker]

I'm thinking of an idea to prevent a header from being modified by other
parts of the route. A sort of contract if you will.

On 5 July 2016 at 13:01, Brad Johnson  wrote:

> Is there another part of your process that is specifically changing the
> header or are you more concerned about it being consistently there across
> routes?  Nothing will change it automatically if it is your header.  I
> don't remember the actual implementation but conceptually it is just a
> hastable/map with key/values.  If you set header with some specific key
> then nothing else will change it.
>
> As an example, I use a camel splitter and then set a header with the
> splitter index so that I can use it in another route later to reassemble
> with the resequencer.
>
> 
> ${body}
> 
> exchangeProperty.CamelSplitIndex
> 
> ...
>
> The "seqnum" is just a key that I'm defining.  I could obviously call it
> anything "sequenceNumber" or whatever but when I access it later that
> header is available on the exchange. If I explicitly change what the map is
> storing for "seqnum" then it will be different because I can't make the
> header map itself immutable.
>
>
> On Tue, Jul 5, 2016 at 10:33 AM, Matt Sicker  wrote:
>
> > As in once I set the header, nothing can change the header during the
> > lifecycle of the message during a route. Same for an exchange property.
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: Is it possible to make a message header or property immutable?

[Brad Johnson]

Is there another part of your process that is specifically changing the
header or are you more concerned about it being consistently there across
routes?  Nothing will change it automatically if it is your header.  I
don't remember the actual implementation but conceptually it is just a
hastable/map with key/values.  If you set header with some specific key
then nothing else will change it.

As an example, I use a camel splitter and then set a header with the
splitter index so that I can use it in another route later to reassemble
with the resequencer.


${body}

exchangeProperty.CamelSplitIndex

...

The "seqnum" is just a key that I'm defining.  I could obviously call it
anything "sequenceNumber" or whatever but when I access it later that
header is available on the exchange. If I explicitly change what the map is
storing for "seqnum" then it will be different because I can't make the
header map itself immutable.


On Tue, Jul 5, 2016 at 10:33 AM, Matt Sicker  wrote:

> As in once I set the header, nothing can change the header during the
> lifecycle of the message during a route. Same for an exchange property.
>
> --
> Matt Sicker 
>

Is it possible to make a message header or property immutable?

[Matt Sicker]

As in once I set the header, nothing can change the header during the
lifecycle of the message during a route. Same for an exchange property.

-- 
Matt Sicker 

RE: Unit test case for XML DSL context and routes

[Vanshul . Chawla]

Thanks.

I have seen this link.

I had some doubts. I have camelcontext.xml which gets message from MQ and 
transforms and sends to a webservice, gets a response and then transforms and 
send back to another queue.
I can mock the end points and can assert based on conditions etc.

How to tell my test case class that I am using which camelcontext.xml? ie how 
to bind test case and xml together?

-Original Message-
From: Steve Huston [mailto:shus...@riverace.com] 
Sent: Tuesday, July 05, 2016 9:17 AM
To: users@camel.apache.org
Subject: RE: Unit test case for XML DSL context and routes

http://camel.apache.org/testing.html

> -Original Message-
> From: Vanshul.Chawla [mailto:vanshul.cha...@target.com]
> Sent: Tuesday, July 05, 2016 10:08 AM
> To: users@camel.apache.org
> Subject: Unit test case for XML DSL context and routes
> 
> Hello All,
> 
> We have some Camel code which is written in XML DSL. We need to add 
> unit test cases for each context(multiple routes) . Could someone 
> please give a lead to how this can be achieved.
> 
> Vanshul

RE: Unit test case for XML DSL context and routes

[Steve Huston]

http://camel.apache.org/testing.html

> -Original Message-
> From: Vanshul.Chawla [mailto:vanshul.cha...@target.com]
> Sent: Tuesday, July 05, 2016 10:08 AM
> To: users@camel.apache.org
> Subject: Unit test case for XML DSL context and routes
> 
> Hello All,
> 
> We have some Camel code which is written in XML DSL. We need to add unit
> test cases for each context(multiple routes) . Could someone please give a
> lead to how this can be achieved.
> 
> Vanshul

Unit test case for XML DSL context and routes

[Vanshul . Chawla]

Hello All,

We have some Camel code which is written in XML DSL. We need to add unit test 
cases for each context(multiple routes) . Could someone please give a lead to 
how this can be achieved.

Vanshul

Re: Error occurred during starting Camel because of cannot look up a processor from registry

[Debraj Manna]

Yeah Tadayoshi. jsonRPCProcessor is using myTemplate as shown below:-













whereas myTemplate is defined in camelContext which in turn is using
jsonRPCProcessor as shown below:-

http://camel.apache.org/schema/blueprint";
useMDCLogging="true">


http://0.0.0.0:/orchestratorservice"; />



http://0.0.0.0:8889/fileuploadservice?enableMultipartFilter=true";
/>


...



I have tried to set the producer in my custom jsonRPCProcessor as mentioned
in this link
.
Can someone suggest me some other way of setting the producer in my custom
jsonRPCProcessor so that it does not lead to any circular dependency?

On Tue, Jul 5, 2016 at 8:21 AM, Tadayoshi Sato 
wrote:

> Hi,
>
> It looks like 'myTemplate' is defined in camelContext.xml, but the Camel
> context then refers to 'jsonRPCProcessor' in blueprint.xml, which in turns
> refers to 'myTemplate'. That should be the cyclic dependency in question.
>
> Hope this helps,
>
> Tadayoshi
>
> On Mon, Jul 4, 2016 at 10:27 PM, Debraj Manna 
> wrote:
>
> > It seems the error is getting triggered because of some cyclic
> dependency.
> > But I am not able to figure out from the trace what is causing the cyclic
> > dependency.
> >
> > On Jul 4, 2016 4:22 PM, "Debraj Manna"  wrote:
> >
> > > On placing a bundle (using camel) on Karaf I am seeing the below
> > > exception. The below exception comes only when the bundle is started.
> > After
> > > that everything works fine. The exeception does not seem to effect our
> > > functionality. The issue is coming on both camel 2.16.1 (deployed on
> > servicemix
> > > 6.1.0) and camel 2.16.3 (deployed on servicemix 7.0.0M2).
> > >
> > > My blueprint is split into three files. A simplified version of them
> are
> > > shown below:-
> > >
> > >
> > >1. blueprint.xml placed here
> > ><
> > https://gist.github.com/debraj-manna/42294561b9da22ce2281e6a9f3b22a34>
> > >.
> > >2. productBeans.xml placed here
> > ><
> > https://gist.github.com/debraj-manna/5c406f597f8b7248369b206ed1f93842>
> > >.
> > >3. camelContext.xml placed here
> > ><
> > https://gist.github.com/debraj-manna/4210653d661beaee6beb87900c4f4911>
> > >.
> > >
> > >
> > > Can some please let me know why is this exception coming during bundle
> > > start?
> > >
> > > The exception looks like below:-
> > >
> > > 2016-07-04 11:29:37,497 | ERROR | mix-6.1.0/deploy |
> > BlueprintCamelContext
> > >| 143 - org.apache.camel.camel-blueprint - 2.16.1 | {{
> > bundle.id
> > > ,143}{bundle.name
> > ,org.apache.camel.camel-blueprint}{bundle.version,2.16.1}}
> > > | Error occurred during starting Camel: CamelContext(camel-1) due
> Failed
> > to
> > > create route orchestrator-service-route at: >>>
> > > process[ref:jsonRPCProcessor] <<< in route:
> > > Route(orchestrator-service-route)[[From[jetty:http://0.0.0.0...
> because
> > > of Cannot lookup: jsonRPCProcessor from registry:
> > > org.apache.camel.blueprint.BlueprintContainerRegistry@7b081b97 with
> > > expected type: interface org.apache.camel.Processor due:
> > > [BeanRecipe[name='myTemplate'],
> > > BeanRecipe[name='.camelBlueprint.bean.factory.myTemplate'],
> > > BeanRecipe[name='camel-1'], BeanRecipe[name='myTemplate']]
> > > org.apache.camel.FailedToCreateRouteException: Failed to create route
> > > orchestrator-service-route at: >>> process[ref:jsonRPCProcessor] <<< in
> > > route: Route(orchestrator-service-route)[[From[jetty:http://0.0.0.0...
> > > because of Cannot lookup: jsonRPCProcessor from registry:
> > > org.apache.camel.blueprint.BlueprintContainerRegistry@7b081b97 with
> > > expected type: interface org.apache.camel.Processor due:
> > > [BeanRecipe[name='myTemplate'],
> > > BeanRecipe[name='.camelBlueprint.bean.factory.myTemplate'],
> > > BeanRecipe[name='camel-1'], BeanRecipe[name='myTemplate']]
> > > at
> > >
> >
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1072)
> > > at
> > >
> >
> org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:196)
> > > at
> > >
> >
> org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:947)
> > > at
> > >
> >
> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:3258)
> > > at
> > >
> >
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:2981)
> > > at
> > >
> >
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
> > > at
> > >
> >
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2812)
> > > at
> > >
> >
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2808)
> > > at
> > >
> >
> org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoade

Dependency chain conflicts for karaf feature camel-cxf 2.17.1

[Alexander Thiessen]

Hi All,

I update my camel karaf feature from 2.16.3 to 2.17.1, and now I get the
following exception:

/org.apache.karaf.shell.support.MultiException: Error executing command on
bundles:
Error starting bundle 225: Uses constraint violation. Unable to resolve
resource org.apache.camel.camel-cxf [org.apache.camel.camel-cxf [225](R
225.0)] because it is exposed to package 'org.springframework.beans' from
resources org.apache.servicemix.bundles.spring-beans
[org.apache.servicemix.bundles.spring-beans [119](R 119.0)] and
org.apache.servicemix.bundles.spring-beans
[org.apache.servicemix.bundles.spring-beans [118](R 118.0)] via two
dependency chains.

Chain 1:
  org.apache.camel.camel-cxf [org.apache.camel.camel-cxf [225](R 225.0)]
import:
(&(osgi.wiring.package=org.springframework.beans)(version>=4.1.0)(!(version>=5.0.0)))
 |
export: osgi.wiring.package: org.springframework.beans
  org.apache.servicemix.bundles.spring-beans
[org.apache.servicemix.bundles.spring-beans [119](R 119.0)]

Chain 2:
  org.apache.camel.camel-cxf [org.apache.camel.camel-cxf [225](R 225.0)]
import:
(&(osgi.wiring.package=org.apache.camel.spring)(version>=2.17.0)(!(version>=2.18.0)))
 |
export: osgi.wiring.package=org.apache.camel.spring;
uses:=org.springframework.beans
  org.apache.camel.camel-spring [org.apache.camel.camel-spring [54](R 54.0)]
import:
(&(osgi.wiring.package=org.springframework.beans)(version>=3.2.0)(!(version>=4.0.0)))
 |
export: osgi.wiring.package: org.springframework.beans/

I think the apache-camel-2.17.1-features.xml is not up-to-date. The
camel-spring feature use the spring feature [3.2,4) and the camel-cxf
feature has a dependency to camel-spring. But the camel-cxf bundle import
spring version [4.1,5). Is this an issues from camel side or I misunderstand
this exception? What I can do to resolve this problem?

Thanks in advance 

Best Regards
Alexander




--
View this message in context: 
http://camel.465427.n5.nabble.com/Dependency-chain-conflicts-for-karaf-feature-camel-cxf-2-17-1-tp5784786.html
Sent from the Camel - Users mailing list archive at Nabble.com.

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

[Claus Ibsen]

There is an example in the Camel in Action 2 book.
https://github.com/camelinaction/camelinaction2/tree/master/chapter10/jetty-rest-security-karaf



On Tue, Jul 5, 2016 at 10:18 AM, Satish Kumar Kesharwani
 wrote:
> I am using Swagger and rest dsl to build an application. Need to implement
> Basic Auth.
> how can i implement SSL/ Basic Auth for jetty component in blueprint xml?
> .endpointProperty("sslKeystore", "/security/serverKey.jks") how i can
> configure in blueprint.xml file.
>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Rest-DSL-how-to-configure-SSL-Basic-Auth-for-jetty-component-tp5758527p5784778.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: Rest DSL - how to configure SSL/Basic Auth for jetty component?

[Satish Kumar Kesharwani]

I am using Swagger and rest dsl to build an application. Need to implement
Basic Auth.
how can i implement SSL/ Basic Auth for jetty component in blueprint xml?
.endpointProperty("sslKeystore", "/security/serverKey.jks") how i can
configure in blueprint.xml file.



--
View this message in context: 
http://camel.465427.n5.nabble.com/Rest-DSL-how-to-configure-SSL-Basic-Auth-for-jetty-component-tp5758527p5784778.html
Sent from the Camel - Users mailing list archive at Nabble.com.