camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Is it possible to make a message header or property immutable?
Date Tue, 05 Jul 2016 20:48:31 GMT
Please let me know if you think of anything!

On 5 July 2016 at 15:16, Brad Johnson <brad.johnson@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 <boards@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.johnson@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 <boards@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.johnson@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 <boards@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 <boards@gmail.com>
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker <boards@gmail.com>
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker <boards@gmail.com>
> >
>



-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message