OpenSAML user discussion

[Brent Putman <>]

Not sure if you were intentionally mixing up these 2 threads.  This thread's recommendation to call DefaultBootstrap.bootstrap() is only tangentially relevant to your problem.  Sounds like this poster wasn't doing it at all.  You are doing it, but getting an error for a wholly different reason (JAXP issues).

Currently I’m just trying to call a method that returns the version of jaxp I’m using. Here is part of my java class file, the 2 methods that are being used. When I call getJAXPVersion it gives me the error.

 

      public String getJAXPVersion()

      {

            return Version.getVersion();

      }

 

I have no idea what that Version class is.  You don't indicate the import statement.  I wasn't aware that JAXP had anything like that.  Their Javadocs don't seem to indicate anything like that.

Trying to figure out versions of JAXP stuff you are actually using is a good thing to do, I suppose, but note that there is a difference between the JAXP API version that some component might report, and the version of the JAXP impl which is going to supply the actual runtime JAXP objects you are using.  Your problem is really about the latter.  In fact, the JAXP version is almost certainly fine, since you have the setSchema method in the first place.  The problem is that the JAXP impl at runtime is so old that it doesn't implement it.

I do think that I’m missing a jar file or something but am unsure where. I’m using xercesImpl-2.9.1 and xml-apis-2.9.1, which appear to contain the DBFI and DBF.

They do contain those, the issue is you need to get those jars in the right place and/or otherwise configured so that the JAXP framework actually uses Xerces 2.9.1 (and don't forget Xalan too) rather than whatever came with your container/app server.  If you are getting that UnsupportedOperationException on called DBF setSchema, then that Xerces 2.9.1 definitely isn't getting used, at least not in the way it needs to be by the JAXP framework.  It's probably using what came with your container, probably some old version of something,

 

Since I’m not a ColdFusion person I’m wondering if the CF server is not picking them up correctly,

Almost certainly that's the problem.

but reading the Adobe site it looks like the search order should start where I have placed the jar files.

What you need to look for are details on how to endorse those jars.  It's usually not about order, endorsement causes some jars that are otherwise supplied by the JRE to be treated as special (part of the JRE spec).  From your stack trace (I didn't notice earlier), it seems you are in fact using JRun in some form or another, rather than the CF "J2EE version" or whatever its called now, that runs in another container.  So you need to look for info on how to endorse jars in JRun.


--Brent

 

 

Thanks again,

 

M

 

 

---

From: Brent Putman []
Sent: Tuesday, January 19, 2010 3:20 PM
To:
Cc: Chandra Tondepu
Subject: Re: [OpenSAML] Re: Not able to load certificate into the Signed Attribute Query

 

On 1/14/10 3:21 PM, Chandra Tondepu wrote:

The issue is resolved.

While bootstraping ensure to
load xmltooling-1.2.0\src\main\resources\signature-config.xml.

If encryption is being done, the corresponding encryption-config.xml should
also be loaded.

Inshort, better load the .xml resources from xmltooling.jar, open-ws.jar and
opnesaml.jar to stayout of the trouble.

All of this is done for you if you use the supplied default method to bootstrap/configure the OpenSAML library, described here:


https://spaces.internet2.edu/display/OpenSAML/OSTwoUsrManJavaLibIntro


In short, call this static method *once* at the initialization stage of your code, before using any of the features of the library:

org.opensaml.DefaultBootstrap#bootstrap()


--Brent