Hi Colm I attached the missing files. Please have alook into the JIRA.
Regards Franz On Wed, Aug 21, 2013 at 12:46 PM, Colm O hEigeartaigh <cohei...@apache.org>wrote: > Thanks for the feedback. I will have a go at reviewing the patch for this > task. Franz, could you please attach all missing (new) files to the JIRA so > that I can fully run the tests? > > Colm. > > > On Wed, Aug 21, 2013 at 10:44 AM, Claus Ibsen <claus.ib...@gmail.com> > wrote: > > > 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 > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
