Shibboleth Developers

["Howard Gilbert" <>]

Yes I am planning to change both Shibboleth and OpenSAML. I have to if the
code is going to run on a version of Java that only exposes JAXP (because it
has the Sun 1.5 runtime version of Xalan/Xerces and no endorsed Apache
distribution). Of course, it will also run on earlier versions of Java with
Xalan in the path and Xerces endorsed. Right now, I am working on a naked
Java 1.5 classpath and fixing all the errors that the compiler calls out
when a package or class is not found.

That said, I am finding that this is a much larger code change than
originally expected. I also have to deal with some explicit use of the
serializer, mostly to dump XML out for diagnostic and log purposes. There is
more code in the test cases than in the mainline.

My plan, if it works, is to centralize the creation of parsers and
serializers in one class. There is a lot of redundant code that creates a
validating parser, and an EntityResolver specific to some particular XSD
file, and the same ErrorHandler. I realize this happened during earlier
versions of the XML support when it didn't always work and was not feature
complete. Now that we are many Apache releases farther along and have to
reopen the question, it makes sense to run all versions of what is
essentially the same operation through a common utility class. This class
will expose static methods (to create the parser, parse the file, and drop
everything) and instance methods (where the parser is created once and
reused, especially for unit testing).

Also, the conversion will be a bit easier with some adapter methods that
match some old interface semantics to the new JAXP interface. It was an
aesthetic decision for the Document to be returned from parser.parse()
(JAXP) instead of through a separate parser.getDocument() (Xerces). Since I
am building a class anyway, I can save a lot of restructuring of old code by
supporting both methods of obtaining the document object.

Given the current CVS structure, I either have to make the utility routine
exclusively part of OpenSAML or create two nearly identical classes, one
there and one for Shibboleth. This is a last minute packaging decision I can
make when I see how the code settles.

> So I think we (Walter/I) are willing to say, if the JAXP interfaces for
> the
> parser and schema lookup are functional at this point, let's use them. If
> I
> understood your offer, you were willing to undertake a test and change the
> OpenSAML code as part of testing it.