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:
<recipientList>
<simple>direct-vm:${header.operationName}</simple>
</recipientList>
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 <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>
>
