Brent Putman
putmanb at georgetown.edu
Tue Apr 21 14:25:14 EDT 2015
On 4/21/15 10:02 AM, Cantor, Scott wrote:
> On 4/21/15, 3:55 AM, "LECUYER, Dominic" <dominic.lecuyer at capgemini.com> wrote:
>> My problem is the escaping of the characters.
> No, your problem is using "string" as a type to carry XML, that's not correct. You would have to construct an XMLObject tree and embed that as the value.
Exactly.
>
> But you really shouldn't, as Jeff indicated.
Agree.
>
>> I am now thinking of how to create my own AbstractXMLObject extentions and factories but this seems to be excessive work with unsure results ^^.
> I believe you can use XSAny to construct any tree required if you wanted to, but I'm not really familiar. It's just a bad idea regardless.
Right. The 2 ways that you could do this are: 1) use XSAny and 2)
implement XMLObject provider impl(s) for the element(s) you need.
XSAny would work ok if the element structure is relatively simple, and
all you need to do is *generate* this XML. There is an example of this
in the wiki, see near the bottom, the health role example:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUsrManJavaAnyTypes
That's actually for v2, so you'd have to adjust a little for v3 (e.g. no
Configuration class, etc), but the XSAny concepts are the same.
If you need to both generate and *consume* new element type(s), then
it's probably best to implement XMLObject impls for those. You can
technically use XSAny for consuming, but it's awkward.
If you want to go the XMLObject impl route, you'd want to look at the
developer's guide:
https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoDeveloperManual
Again, that is for v2, and is probably even a little outdated for v2,
but the concepts are the same. Or if it's easier, just look at some
actual examples in the v3 OpenSAML project. You'd basically be doing
the same thing: for each element declare an interface, write an impl and
finally create the relevant builder/marshaller/unmarshaller set which
you then register with the XMLObjectProviderRegistry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150421/5fc05991/attachment.html>
More information about the dev
mailing list