OpenSAML user discussion

[Neill Miller <>]

Hello Brent and Scott,

Thanks so much for your patience and assistance.  I think I got my code 
working now and everything appears as it should.  I ended up building the 
AttributeValue as an XSAny type and adding the instantiation of my custom 
type as a child (as you both had mentioned).

Reference code is included below -- I believe it's doing what you specified.  
Feel free to verify.

--------------------
// start with the attribute we're building
Attribute attribute = attributeBuilder.buildObject();
...

// instantiate my custom type and set parameters
XSMyType myTypeValue = myTypeBuilder.buildObject(
  "http://www.myns.org";, "myType", "myns");
myTypeValue.setParam1("foo");
myTypeValue.setParam2("bar");

// instantiate the XSAnyBuilder to build my XSAny typed AttributeValue
XSAnyBuilder xsb = new XSAnyBuilder();
XSAny myXSAny = xsb.buildObject(AttributeValue.DEFAULT_ELEMENT_NAME);

// add XSMyType built above to this XSAny typed AttributeValue's list of 
children
myXSAny.getUnknownXMLObjects().add(myTypeValue);

// finally, add the XSAny AttributeValue to the attribute
attribute.getAttributeValues().add(myXSAny);
--------------------

Appears to work perfectly!

Thanks again,
-Neill.

----- "Brent Putman" 
<>
 wrote:

> Scott Cantor wrote:
> 
> 
> That would be the other option, the one that's actually an xsi:type of
> your custom type.
> 
> I would guess that since AttributeValue is of anyType, you'd have to
> use the XSAny object set to construct it by itself. Or you'll have to,
> as Brent said, build a custom class set that handles not only the
> child element's type but also the type represented by an element with
> that element as a child.
> Right, since AttributeValue is defined as an xs:anyType, we don't
> supply a concrete implementation of AttributeValue. Any and all
> XMLObject types could theoretically be used, representing any simple
> or complex type. We supply those XS* schema providers for some of the
> common simple types from XML Schema. If it's a complex type, you need
> an XMLObject that implements that type. If you have a custom type that
> isn't defined in SAML or any of the other schemas we implement, then
> obviously we don't supply a provider for that, because we obviously
> can't. So you have to supply it. Either you write one, or you could
> use an XSAny that supports an open content model of any attribute and
> any child element.
> 
> I would say, though, that if you do have a formal schema and type
> model, etc, that you probably want to go ahead and implement providers
> for them. At least in my head, that lends itself to more conceptual
> correctness. I mean, we could use XSAny for just about everything at a
> functional level, but we don't. It's mostly intended to support
> unmarshalling unknown types that you receive, and provide access to
> the content model in an open fashion. It's not really for building and
> marshalling things in your own code (although it can function that
> way).
> 
> BTW, I've noted that that wiki page OSTwoUsrManJavaAnyTypes is
> horribly conflating some totally unrelated things, like ur-type
> xs:anyType vs. <any> wildcards, or is at the very least potentially
> confusing to someone who doesn't already understand these things in
> the first place. And is also outdated, as it still refers to the
> deprecated ElementProxy class (replaced by XSAny). I'll probably take
> a stab at rewriting it in the near future.