Hi Yeah the components gives more flexibility. And a component can also do the same work as a data format would do, its just how its represented in the DSL.
If there is a need for a data format for the signer, then we could add that as a new data format, as Franz pointed out, it has different configuration options. Also a data format can be added later if/when needed. On Wed, Aug 21, 2013 at 7:39 AM, Franz Paul Forsthofer <emc2...@googlemail.com> 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 > <cohei...@apache.org>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.ib...@gmail.com> >> 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 >> > <cohei...@apache.org> 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: cib...@redhat.com >> > 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 >> -- 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
