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 <brad.john...@mediadriver.com> 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 <boa...@gmail.com> 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 <brad.john...@mediadriver.com> > > 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. > > > > > > <split> > > > <simple>${body}</simple> > > > <setHeader headerName="seqnum"> > > > <simple>exchangeProperty.CamelSplitIndex</simple> > > > </setHeader> > > > ... > > > > > > 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 <boa...@gmail.com> 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 <boa...@gmail.com> > > > > > > > > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
