[prev in list] [next in list] [prev in thread] [next in thread]
List: shibboleth-dev
Subject: =?UTF-8?Q?Undocumented_AttributeResolutionContext_API=c2=a0change_b?= =?UTF-8?Q?etween_3=2e3_and_3=2
From: Etienne Dysli Metref <etienne.dysli-metref () switch ! ch>
Date: 2018-12-03 13:33:36
Message-ID: 11ff47e9-fd0b-55fc-8201-aa3a065eedf4 () switch ! ch
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/mixed)]
Developers beware: a java.lang.NoSuchMethodError just bit me when I
deployed a class compiled against IdP 3.4.1 on a 3.3.2. It happened
because the class in question uses method
`net.shibboleth.idp.attribute.resolver.context.AttributeResolutionContext=
#setPrincipal`
and its signature changed in IdP 3.4:
- 3.3: `void setPrincipal(String)`
- 3.4: `AttributeResolutionContext setPrincipal(String)`
The only trace of this change that I could find is commit
1b9071076e1c137c11e7960ce6972b1de1215e1e in java-identity-provider.
Shouldn't this have been more prominently documented?
Moreover, I find it rather unusual for setters to return anything,
except in a builder-style API (but then methods aren't usually named
setX). So all-in-all that's not a big deal (*), but slightly frustrating
because I now have to recompile against 3.3 and it doesn't have the nice
Maven BOM POM... :/
Etienne
(*) Unless this violates the IdP's versioning policy
(https://wiki.shibboleth.net/confluence/display/DEV/Java+Product+Version+=
Policy)
which says:
> Minor Version Compatibility
> - Java API: may add/deprecate, but *not* remove, APIs
hmm oops!
["signature.asc" (application/pgp-signature)]
--
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic