On Wed, Aug 21, 2013 at 8:33 AM, Babak Vahdat <babak.vah...@swissonline.ch> wrote: > Hi > > I guess as this will be part of the upcoming 2.12.0 release, the users can > make use of it as a component even if we stick to a data format > implementation: > > http://camel.apache.org/dataformat-component.html >
Ah yeah, that gives the data format the freedom to be used in recipient lists, and other EIPs which has dynamic routing. Where as data formats is static as they require to use the marshal and unmarshal in the DSL. > Babak > > > Franz Paul Forsthofer wrote >> Hi Colm, >> >> I made the proposal with the XML Signature component. I did not implement >> it as Data Formater because I found out that the signer needs quite >> different parameters than the verifier. For example, the signer needs as >> input a signature algorithm, canonicalization methods, transformation >> methods, whereas the verifier only needs a few input parameters like >> public >> key. A Data Formater would have the same paramerters for the marschaller >> and unmarschaller available, whereas in a component the different >> endpoints >> (signer and verifier) can have different parameters. At least that's my >> understanding. >> >> Regards Franz >> >> >> On Tue, Aug 20, 2013 at 5:05 PM, Colm O hEigeartaigh < > >> coheigea@ > >> >wrote: >> >>> Hi Claus, >>> >>> I hadn't actually seen that JIRA when I wrote my original mail. An >>> immediate question that comes to mind on looking at the patch is whether >>> we >>> care about roughly aligning the configuration of the new functionality >>> with >>> the existing "XML Security" DataFormat? >>> >>> For example, the supplied patch uses configuration that looks like >>> "xmlsecurity:sign://enveloping?keyAccessor=#accessor", whereas the >>> existing >>> component uses ".marshal().secureXML(.....)". Should the new >>> functionality >>> be implemented as a DataFormat as well, or does this not matter? >>> >>> Colm. >>> >>> >>> On Fri, Aug 16, 2013 at 2:52 PM, Claus Ibsen < > >> claus.ibsen@ > >> > >>> wrote: >>> >>> > Hi >>> > >>> > There is this ticket. I assume its likely related to your proposal >>> > https://issues.apache.org/jira/browse/CAMEL-6339 >>> > >>> > As it was a big patch and also we should double check that the source >>> > code is fully ASF acceptable. I think there is some schema files or >>> > whatnot copied from SUN/Oracle which may be a problem? Though haven't >>> > had the time to dive in. >>> > >>> > Would be great if you had the time to check the patch on the ticket, >>> > and maybe align with your work. >>> > >>> > >>> > >>> > On Fri, Aug 16, 2013 at 3:47 PM, Colm O hEigeartaigh >>> > < > >> coheigea@ > >> > wrote: >>> > > Would the Camel community be interested in a XML Signature >>> DataFormat? >>> It >>> > > would be quite similar to the existing XML Security DataFormat, >>> except >>> > that >>> > > it would offer XML Signature instead of XML Encryption. Both could be >>> > used >>> > > together to support "sign-before-encrypt" or "encrypt-before-sign" >>> type >>> > of >>> > > functionality. >>> > > >>> > > I have implemented a prototype, but don't want to waste any more time >>> in >>> > > case there are any objections? >>> > > >>> > > Thanks, >>> > > >>> > > Colm. >>> > > >>> > > >>> > > -- >>> > > Colm O hEigeartaigh >>> > > >>> > > Talend Community Coder >>> > > http://coders.talend.com >>> > >>> > >>> > >>> > -- >>> > Claus Ibsen >>> > ----------------- >>> > Red Hat, Inc. >>> > Email: > >> cibsen@ > >>> > Twitter: davsclaus >>> > Blog: http://davsclaus.com >>> > Author of Camel in Action: http://www.manning.com/ibsen >>> > >>> >>> >>> >>> -- >>> Colm O hEigeartaigh >>> >>> Talend Community Coder >>> http://coders.talend.com >>> > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/XML-Signature-DataFormat-tp5737414p5737643.html > Sent from the Camel Development mailing list archive at Nabble.com. -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
