deploying the current Shib v3 snapshot on Tomcat

[Tom Zeller]

On Wed, Sep 3, 2014 at 2:57 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/3/14, 9:18 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>>
>>The installer couldn't. I suppose the code could try, we'll have to take a
>>look at it. It's going to cause problems the way it is now, this is just
>>the first case.
>
> I think it really can't, at least not easily. Testing for the presence of
> particular SecurityManager classes doesn't really tell you which parser
> implementation will actually get used at runtime when the JAXP calls are
> made.
>
> The problem is just a JAXP limitation, they haven't standardized the
> SecurityManager class API so that you can install one portably (or for
> that matter just install one by default so we don't have to).

Caveat : I don't really know what I'm doing ... but ... I've been
using the testbed to test the consent flows, and after a little while
I got tired of clicking, so I added Selenium to the testbed, and
Selenium brings along Xerces/Xalan so our default configuration does
not work, as described in this thread. So I added the following to the
app ctx initializer, which adjusts idp.properties in-memory, not
on-filesystem, as a workaround. It's wrong because ClassNotFound and
IllegalArgument exceptions should be handled differently, but it
"works".

try {
    final DocumentBuilderFactory newFactory =
DocumentBuilderFactory.newInstance();
    newFactory.setAttribute("http://apache.org/xml/properties/security-manager",
            Class.forName("com.sun.org.apache.xerces.internal.util.SecurityManager").newInstance());
} catch (IllegalArgumentException | ClassNotFoundException |
InstantiationException | IllegalAccessException e) {
    properties.setProperty("idp.xml.securityManager",
"org.apache.xerces.util.SecurityManager");
}