questions about ExtractUsernamePasswordFromWssToken

[Brent Putman]

On 8/1/13 9:45 PM, Cantor, Scott wrote:
> It's not clear we have control over that because anybody can override our
> configuration, right? If we assume we control the object provider
> registrations, then I guess we control it.

Well, I meant that for the object providers we implement, we always
correctly associate the QName with the type via the interface
constants.  But you are correct that someone else could override the
default config and register something else under a given QName where the
type assumption doesn't hold.  So yes, someone could break things by
errant provider registration, but the ones we provide out of the box are
correct. 

> Once can always check before casting, so it's a question of how much work
> to do to avoid cases that aren't supposed to come up. Much like checking
> for nulls in some layers of code.

Yes, I think the tradeoff is exactly the same as the null checking. 
Personally I don't think it's worth all the extra work and code clutter
to do all the cast checking for this particular case, especially in
light of what I said above.  If some custom component developer breaks
something via erroneous provider registration, then IMHO it's on them to
just not do that. :-)

Another point is that it's at least less bad than the ubiquitous pattern
of pulling extensible properties out of a Map<String,Object> map and
casting based on the key used.  At least we have clear documentation in
the code (the static QName constants on interfaces) which tell you what
the expected QName -> Java type mappings are.