Skip to Content.
Sympa Menu

shibboleth-dev - Re: opensaml.jar

Subject: Shibboleth Developers

List archive

Re: opensaml.jar


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: opensaml.jar
  • Date: Mon, 29 Aug 2005 22:01:53 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XAJCO/uOwVJBRjQo6UqjdrMNzyOxnIdKhRLqVfMZC8eLjI19zUmUnkejYTX0wfFheX6QblEUv7cMFy+GOilIevenlCjqgUQcqjRfSSTbO23Tsbr6AvoZlsI51PcYV5QJcZfkju2bDwcQn9mOKAoLD1n0lPptCNJ4SlNT3TPDK6I=

On 8/29/05, Scott Cantor
<>
wrote:
> >
> > The tester
> > requires OpenSAML and as luck would have it, it relies on one of the
> > few OpenSAML classes that needs the servlet.jar. So can the install
> > process copy the latter into ${idp.home}/lib?
>
> Probably the future answer would be to factor the interface in question into
> client and server halves so that clients wouldn't need access to the
> server-side interfaces.
>
> I'm guessing that's the source of the problem, I can't think of any other
> reason a client-side function would run into one of those classes.

Hmm, is it unreasonable for an attribute requester to rely on
SAMLSOAPHTTPBinding?

Tom



Archive powered by MHonArc 2.6.16.

Top of Page