Please let me know if you think of anything! On 5 July 2016 at 15:16, Brad Johnson <brad.john...@mediadriver.com> 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 <boa...@gmail.com> 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 <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> > > > -- Matt Sicker <boa...@gmail.com>
