Orphan classes in java-support

[Rod Widdowson]

> First comment was that I use HttpBuilder, as I think I've mentioned
before, in
> Spring configurations. The only actual *feature* I use is the
> connectionDisregardSslCertificate property, so that I can make
HttpResource
> objects to fetch metadata from SSL-protected metadata locations without
> worrying about the certificates (several federations use this model, but
all of
> them also use XML DSIG so I just ignore the TLS).
> 
> So I guess that as long as there's a way to do something similar with the
new
> style HTTP resource, I'm content there.

I spent more time back at HTTPResource land this morning, and I think I see
what is going on.  Brent will confirm, but AIUI both the HTTPResource and
the HTTMetadataResolver have/will have HttpClient objects as constructor
parameters.  HttpClientBuilder (and HttpClientSupport) or their successors
will almost certainly have a job to do to create these specialized versions
of HttpClient.  I suspect that this will all be buried in Spring
configuration, whereas in V2 the parsers summoned the builder up on the fly.


So my suspicion is that these are not orphans (or rather will not be
orphans), but should move to the "Used in XML or spring config" section.

> This is probably worth discussing. We don't have any standards anywhere as
to what we should be checking or transforming in bean setters, so 
> I suspect it's somewhat inconsistent. Do we think we *should* have
standards in this area?

I think we certainly need this discussion - their use is patchy and in some
cases I'm not quite sure what we are being defensive against.  Then there is
IDP-345 which is to do guava having deprecated one of the Constraints that
we inject into these classes.

/R