Orphan classes in java-support

[Ian Young]

On 14 Jan 2014, at 17:15, Rod Widdowson <rdw at steadingsoftware.com> wrote:

> I started looking at the HttpResource this morning and realized that it was
> the only code which made any use of a whole slew of classes in java-support.
> 
> This spurred me to pick up an old AI of mine
> https://issues.shibboleth.net/jira/browse/JSPT-37 which was to check how
> many of these classes are being used. 
> 
> I found it quite educational to do this, and I have just annotated that case
> with a list of orphans, plus some 'single use' classes.  Note that I did
> this mostly by using eclipse, and so some of these classes may well be being
> injected via Spring.

Thanks for this. I just finished crawling over the list to see what if anything I should be using more of. I added a couple of comments to JSPT-37:

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.

Second comment is this:

> The single use of TrimOrNullStringFunction in MDA is used when setting a property which is a set of element names to be handled. The function is used to trim whitespace from those names, and turn any (resulting) empty strings into nulls. Collections.addIf is then used to filter out the nulls.
> Other similar call sites in the MDA don't bother so much, and in many cases don't bother filtering nulls out of the supplied collection. So one approach would be to say that's not something we feel we need to do, and simplify the single use so that the class can be deleted.
> Of course another alternative would be to say that this is something we should be doing, and apply it everywhere. I'm not sure I really see much benefit in that, though. Opinions welcome.


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?

My third comment (and this one I didn't put on the issue, as it's kind of a different thing) is about xml.ClasspathResolver. I know that's another one that I'd inject into BasicParserPool instances if I was able to put more stuff on the classpath. In my case I'm a little stuck because I also need an equivalent to BasicParserPool for schemas to make that worthwhile, and the existing SchemaBuilder doesn't cut it for me. We have a ticket outstanding for that as well, and my recollection is that if you look into that more deeply that the function of SchemaBuilder is being duplicated elsewhere to solve that problem. So it's a tangled issue but definitely one that *should* be centralised.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20140115/af5de23f/attachment.bin