Thanks for the tip! On 15 July 2016 at 00:55, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi > > See about deep-clone at: http://camel.apache.org/multicast > > On Thu, Jul 14, 2016 at 6:54 PM, Matt Sicker <boa...@gmail.com> wrote: > > I think I found my issue with the mutable headers in question. It appears > > that the headers of a message are shared amongst the exchanges sent out > in > > a multicast, so modifying a header in one route affects the other route. > If > > that's not the case, then I've discovered some very strange behavior. > > > > On 6 July 2016 at 20:34, Tadayoshi Sato <sato.tadayo...@gmail.com> > wrote: > > > >> Hi, > >> > >> It's just an idea off the top of my head, but what about providing a > parity > >> check header in company with the header you want to be immutable. I.e. > >> > >> YOUR_HEADER = "Do not change!" > >> YOUR_HEADER_MD5 = "fef4de21954d4b9f1b3e61ed153799da" > >> > >> or > >> > >> YOUR_HEADER_HASH = "md5:fef4de21954d4b9f1b3e61ed153799da" > >> > >> When making use of this header, you can always validate if it's not > changed > >> in the routes. > >> > >> On Wed, Jul 6, 2016 at 6:03 AM, Matt Sicker <boa...@gmail.com> 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 <boa...@gmail.com> 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 < > souciance.eqdam.ras...@gmail.com> > >> > > 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] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=0>> 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] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=1>> 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] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=2>> > >> > >> > > > 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] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=3>> 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] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=4>> > >> > >> > > > > > 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 <[hidden > >> email] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=5>> > >> > >> > > > 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 <[hidden email] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=6>> > >> > >> > > > > > > > > >> > >> > > > > > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > -- > >> > >> > > > > > Matt Sicker <[hidden email] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=7>> > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > -- > >> > >> > > > Matt Sicker <[hidden email] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=8>> > >> > >> > > > > >> > >> > > > >> > >> > > >> > >> > > >> > >> > > >> > >> > -- > >> > >> > Matt Sicker <[hidden email] > >> > >> > <http:///user/SendEmail.jtp?type=node&node=5784811&i=9>> > >> > >> > > >> > >> > > >> > >> > ------------------------------ > >> > >> > If you reply to this email, your message will be added to the > >> > discussion > >> > >> > below: > >> > >> > > >> > >> > > >> > >> > >> > > >> > http://camel.465427.n5.nabble.com/Is-it-possible-to-make-a-message-header-or-property-immutable-tp5784800p5784811.html > >> > >> > To start a new topic under Camel - Users, email > >> > >> > ml-node+s465427n465428...@n5.nabble.com > >> > >> > To unsubscribe from Camel - Users, click here > >> > >> > < > >> > >> > >> > > >> > http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=465428&code=c291Y2lhbmNlLmVxZGFtLnJhc2h0aUBnbWFpbC5jb218NDY1NDI4fDE1MzI5MTE2NTY= > >> > >> > > >> > >> > . > >> > >> > NAML > >> > >> > < > >> > >> > >> > > >> > http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > >> > >> > > >> > >> > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> View this message in context: > >> > >> > >> > > >> > http://camel.465427.n5.nabble.com/Is-it-possible-to-make-a-message-header-or-property-immutable-tp5784800p5784812.html > >> > >> Sent from the Camel - Users mailing list archive at Nabble.com. > >> > > > >> > > > >> > > > >> > > > >> > > -- > >> > > Matt Sicker <boa...@gmail.com> > >> > > > >> > > >> > > >> > > >> > -- > >> > Matt Sicker <boa...@gmail.com> > >> > > >> > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > -- Matt Sicker <boa...@gmail.com>
