Yes - you got it - maybe an jaxbUnmarshaller if your byBusinessProcessor
returns an jaxb object.
Get that to work first - then you might want to use
http://camel.apache.org/binding.html as well (which is really just
syntactic sugar to make the dataformat a property of the endpoint/transport.
2014-12-24 11:29 GMT+01:00 James Green <james.mk.gr...@gmail.com>:
>
> So something like:
>
>
> from("the.input.queue").unmarshal(cryptoDataFormat).unmarshal(jaxbMapper).process(byBusinessProcessor).marshal(cryptoDataFormat).to("the.output.queue")
> ?
>
> Not entirely convinced I have this mentally modelled yet...
>
> On 24 December 2014 at 10:22, David Karlsen <davidkarl...@gmail.com>
> wrote:
>
> > Sure! The crypto is agnostic of transport and payload - stick it in
> between
> > the marshalling and the endpoint - and inbetween endpoint and
> unmarshalling
> > and you should be fit for fight.
> > Good luck!
> >
> > 2014-12-24 11:17 GMT+01:00 James Green <james.mk.gr...@gmail.com>:
> > >
> > > I'm looking at Camel's CryptoDataFormat and am wondering to what extent
> > we
> > > might employ it.
> > >
> > > In our use-case we want multiple Camel-powered JARs to send each other
> > > messages via a message broker. Some of message needs to remain private
> so
> > > cryptography needs to be used. Right now we have routes that produce
> and
> > > consume from brokers and use jaxb classes for mapping to/from POJOs.
> > >
> > > http://camel.apache.org/crypto.html Does not really deal with anything
> > > realistic - only mock endpoints. Can this be put into the above
> > > applications?
> > >
> > > Thanks,
> > >
> > > James
> > >
> >
> >
> > --
> > --
> > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
> >
>
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
