[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