RE: OpenSAML Extensions

[Pedro Nuno Santos]

Ok it makes sense, thanks for the quick reply!

-----Original Message-----
From: dev-b...@shibboleth.net [mailto:dev-b...@shibboleth.net] On Behalf Of Chad La Joie
Sent: 27 March 2012 12:22
To: Shib Dev
Subject: Re: OpenSAML Extensions

The Extensions element can appear in many places, each with a different namespace. We could have made multiple copies of that class and placed one in each corresponding package but chose not to do that.

So, since that element can appear in multiple namespaces there is no
*default* namespace qualified name and thus those constants aren't there. The builder's no-arg constructor just picked one possible option as the default option instead of throwing a UnsupportedOperationException. I think metadata was the right one as the vast majority of use cases that we've seen occur there.

On 3/27/12 6:50 AM, Pedro Nuno Santos wrote:
> Hi everyone,
>
>
>
> I have a question regarding the < org.opensaml.saml2.core.Extensions >
> class. Is there a reason why it's structure doesn't follow the other
> elements? Specifically why there's a field < LOCAL_NAME : String >
> instead of a < DEFAULT_LOCAL_NAME : String > and no <
> DEFAULT_ELEMENT_NAME : QName > ? These fields are useful for using
> reflection to build the various SAML elements J
>
>
>
> Also the Extensions builder uses on it's no arg constructor the
> metadata namespace (SAML20MD_NS), shouldn't it be the protocol
> namespace
> (SAML20P_NS) the default?
>
>
>
>
>
>
>
> Cheers,
>
> Pedro Santos
>
>
>
>
>
>
>
>
>
> --
> To unsubscribe from this list send an email to
> dev-uns...@shibboleth.net
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net