Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] OpenSAML 2.0 custom data type help

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] OpenSAML 2.0 custom data type help


Chronological Thread 
  • From: Neill Miller <>
  • To:
  • Subject: Re: [OpenSAML] OpenSAML 2.0 custom data type help
  • Date: Mon, 9 Feb 2009 13:57:12 -0600 (CST)

Hello,

To make the question more clear (hopefully), how about this:

https://spaces.internet2.edu/display/OpenSAML/OSTwoUsrManJavaAnyTypes#OSTwoUsrManJavaAnyTypes-AttributeValues

This page has a code snippet that properly builds the AttributeValue element
inside of the Attribute tag. This example works great for me, but now I'm
creating my own type instead of an XSString.

So I want to do something like this instead:

-------------------------
Attribute attribute;
XSMyTypeBuilder = (XSMyTypeBuilder)
Configuration.getBuilderFactory().getBuilder(XSMyType.TYPE_NAME);

// build custom type for method 1 (below): NOTE this way avoids the xsi:type
emission
XSMyType myTypeValue =
myTypeBuilder.buildObject("http://www.myns.org","myType","myns";);
// OR
// build custom type for method 2 (below)
XSMyType myTypeValue =
myTypeBuilder.buildObject(AttributeValue.DEFAULT_ELEMENT_NAME,
XSMyType.TYPE_NAME);

myTypeValue.setParam1("foo");
myTypeValue.setParam2("bar");
attribute.getAttributeValues().add(myTypeValue);
-------------------------

I have currently tried two ways of marshalling the data into XML (in my
custom marshaller), but the problem is that both generate invalid XML.

Method 1:
Implement marshallAttributes

<snip>
XSMyType myType = (XSMyType)xmlObject;
domElement.setAttributeNS("http://www.myns.org";, "param1",
myType.getParam1());
domElement.setAttributeNS("http://www.myns.org";, "param2",
myType.getParam2());
<snip>

This code generates invalid XML like this:

<saml:Attribute Name="MyAttribute" NameFormat="myType">
<myns:myType xmlns:myns="http://www.myns.org"; param1="foo" param2="bar" />
</saml:Attribute>

[ Note the lack of a 'AttributeValue' tag wrapping the custom type ]

Method 2:
Implement marshallElementContent (instead of marshallAttributes) and manually
build the XML string to be emitted in the data area of the AttributeValue:

<snip>
XSMyType myType = (XSMyType)xmlObject;
StringBuffer str = new StringBuffer("<");
str.append("myns:myType param1=\"");
str.append(myType.getParam1());
str.append("\" param2=\"");
str.append(myType.getParam2());
str.append("\" />");
XMLHelper.appendTextContent(domElement, str.toString());
<snip>

This code generates invalid XML like this:

<saml:Attribute Name="MyAttribute" NameFormat="myType">
<saml:AttributeValue xmlns:myns="http://www.myns.org";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:type="myns:myType">&lt;myns:myType group="ESG-NCAR" role="admin"&gt;
</saml:AttributeValue>
</saml:Attribute>

[ Note the escaped angle brackets that were converted to textual &lt; and
&gt; sequences ]

I'm convinced that method 2 is incorrect because it is attempting to insert
an element as text and it also can't leave out the xsi:type parameter because
leaving it out causes a runtime error that won't allow my type to be cast to
an XSAny type (presumably the default xsi:type if not specified). But it's
still unclear what the proper way to go to get the properly built XML output
required is.

Does this explanation help a bit more on what the problem is?

-Neill.

----- Original Message -----
From: "Brent Putman"
<>
To:

Sent: Monday, February 9, 2009 10:37:20 AM GMT -06:00 US/Canada Central
Subject: Re: [OpenSAML] OpenSAML 2.0 custom data type help



Neill Miller wrote:
> Hello Brent,
>
> Thanks, the prettyPrintXML method looks great.

Just be aware that if you're doing signing, you can't use pretty print.
You have to serialize using a mechanism that doesn't modify the signed
DOM, which pretty printing does. That method is primarily only for use
in making log files or debug output more easily human-readable.

> Any ideas on my original question about the custom data type building
> into the AttributeValue?
>

I thought that Scott and I had already answered that question. For the
reasons Scott stated, you probably don't want the xsi:type to be
emitted. You can achieve that by using one of the builder build(...)
methods that doesn't take the type QName argument.

--Brent






Archive powered by MHonArc 2.6.16.

Top of Page