...
- MDA-166: The
ItemSerializer
andItemCollectionSerializer
interfaces now allow serializers to throwIOException
when appropriate. The providedDOMItemSerializer
will throw anIOException
wrapping aTransformerException
if the latter is thrown during XML serialization. Previously, this condition would only have resulted in logging at ERROR level. - MDA-167: The
ItemIdTransformStage
now transforms identifiers using a collection ofFunction
objects rather than of the similarConverter
provided by the Spring framework. This also affects the type of theMDQueryMD5ItemIdTransformer
andMDQuerySHA1ItemIdTransformer
classes. This change will not affect existing configurations if only those classes are in use. This matches the use ofFunction
elsewhere in the API. - MDA-169: The
SAMLMetadataSupport.getDescriptorExtensions
method has been renamed togetDescriptorExtension
to reflect the fact that it returns a single result. - MDA-170: The
PKCS11PrivateKeyFactoryBean
temporarily introduced in v0.9.2 has, as indicated for that release, moved to thespring-extensions
module; configurations will need to be adjusted accordingly:
Old class name:net.shibboleth.metadata.util.PKCS11PrivateKeyFactoryBean
New class name:net.shibboleth.ext.spring.factory.PKCS11PrivateKeyFactoryBean
- MDA-171: The
SAMLMetadataSupport.getDescriptorExtension
method's parameters must now be non-null
; their annotations have been changed to@Nonnull
to correspond with this. In previous releases, they were annotated as@Nullable
and passingnull
would result in the method returningnull
. - MDA-175: The
ItemOrderingStrategy
interface defined by theEntitiesDescriptorAssemblerStage
now allows the ordering strategy to throw aStageProcessingException
if, for example, the items presented are invalid in some way and can not be ordered. Such an exception will be propagated upwards to the caller of the stage'sexecute
method. - MDA-179: The
Version
class'sgetMicroVersion
method has been renamed togetPatchVersion
to align with current (semantic versioning) terminology. - MDA-182: Several classes exposed as part of the API for building custom stages have been reworked to simplify implementation of other stages and to correspond to current naming conventions:
BaseStage
has been renamed toAbstractStage
BaseIteratingStage
has been renamed toAbstractFilteringStage
- A new
AbstractIteratingStage
allows the simpler construction of stages which process each Item independently
- MDA-188: The
AbstractDOMTraversalStage
framework has been generalised to allow the use of custom context objects specific to the particular traversal, rather than relying on sometimes tortured uses of theClassToInstanceMultiMap
to carry everything. This is a breaking change, but will only affect writers of stages derived fromAbstractDOMTraversalStage
:- Context objects must implement the
DOMTraversalContext
interface. This no longer includes thegetStash
method (returning aClassToInstanceMultiMap
but does add a newend()
method to be called at the end of the traversal. - A basic implementation of
SimpleDOMTraversalContext
is provided without any data fields. This can be used in many cases where custom storage is not required in the context; for an example, seeAbstractElementVisitingStage
. - More complex cases can extend
SimpleDOMTraversalContext
to include additional fields and method. For a very straightforward example, seeCRDetectionStage
. A more complex example, including use of theend()
method fromDOMTraversalContext
, can be found inElementsStrippingStage
.
- Context objects must implement the
- MDA-198: In previous releases, the three X.509 validation component (
X509RSAExponentValidator
,X509RSAKeyLengthValidator
andX509RSAOpenSSLBlacklistValidator
) all set a default ID related to their names (e.g.,RSAKeyLength
). This default ID setting behaviour has been removed. This may have two effects on configurations which do not explicitly set the component ID:- If a configuration did not set the component ID, initializing the component will now fail with a
ComponentInitializationException
. - Configurations that implicitly set the component ID to a defaulted Spring component ID using
IdentifiableBeanPostProcessor
may give different results, as the Spring component ID may now appear in status objects replacing the previous default.
- If a configuration did not set the component ID, initializing the component will now fail with a
- MDA-191: The stages
PullUpCacheDurationStage
,PullUpValidUntilStage
,SetCacheDurationStage
,SetValidUntilStage
andValidateValidUntilStage
now use theInstant
andDuration
classes (introduced in Java 8) in their APIs rather than usinglong
values representing milliseconds as in previous releases.- This aligns the metadata aggregator with other Shibboleth projects based on the Java 11 platform. If you use the Java language to configure these stages, you will need to re-code appropriately; in most cases, this can be done quickly using
Instant.fromEpochMilli()
andDuration.ofMillis()
, but we recommend adopting the modernjava.time
classes throughout. - The
DurationToLongConverter
is no longer included as part of thejava-support
dependency. If you were using it as part of an XML configuration to specify durations in ISO 8601 format (e.g., "PT15M") then you should replace references toDurationToLongConverter
with references to the newStringToDurationConverter
.
- This aligns the metadata aggregator with other Shibboleth projects based on the Java 11 platform. If you use the Java language to configure these stages, you will need to re-code appropriately; in most cases, this can be done quickly using
- MDA-206: The
PipelineDemultiplexerStage
'swaitingForPipelines
property previously defaulted tofalse
, which could result in unexpected behaviour if the stage was invoked a second time without arranging to synchronise execution with the called pipelines. As a result, most deployments setwaitingForPipelines
totrue
so that the called pipelines will all complete before control is passed on from thePipelineDemultiplexerStage
; this behaviour is now the default. - MDA-219: In previous releases, the
DOMResourceSourceStage
tested for the existence of the suppliedResource
as part of component initialization, potentially resulting in aComponentInitializationException
duringinitialize()
. Unfortunately, this could also cause large remote resources to be fetched unnecessarily, and in addition did not guarantee that theResource
would be accessible during normal operation. This check has been removed: now, aStageProcessingException
will be thrown during stage execution instead, in the same way as was already the case for other I/O errors related to theResource
. - MDA-222: The contract for bean properties representing collections has changed:
- Property setters for collection properties are now annotated as
@Nonnull
@NonnullElements
@Unmodifiable
.- Previously, some setters allowed a null value to act in place of an empty collection. This usage will now result in most cases in a
NullPointerException
. - Previously, some setters filtered null values out of provided collections. Again, this usage will now result in most cases in a
NullPointerException
. - Setters now guarantee not to modify the passed collection. This was previously true in practice in most cases, but is now guaranteed.
- Previously, some setters allowed a null value to act in place of an empty collection. This usage will now result in most cases in a
- Most property getters for collection properties are also now annotated as
@Nonnull
@NonnullElements
@Unmodifiable
.- In exceptional cases, getters may be annotated as
@NonnullAfterInit
instead of@Nonnull
. This is only done when an "empty collection" default is inappropriate for the property and would normally be accompanied by@NotEmpty
on both the setter and the getter.
- In exceptional cases, getters may be annotated as
- Property setters for collection properties are now annotated as
- MDA-232: Previously, an invalid XPath expression provided to an
XPathFilteringStage
went largely unremarked: if the expression failed to compile, no filtering would be performed. If the expression could not be evaluated (for example, because it referenced a$variable
) errors would be logged, and all items would be filtered out. Now:- An XPath expression which fails to compile will result in a
ComponentInitializationException
when the stage is initialized. - An XPath expression which fails to evaluate will result in a
StageProcessingException
when the stage is executed.
- An XPath expression which fails to compile will result in a
- MDA-234: The
EntitiesDescriptorAssemblerStage
previously allowed entities to be reordered by setting a property to an instance of anItemOrderingStrategy
sub-interface that was specific toItem<Element>
. This interface has been extracted to thepipeline
package and expressed as a generic, allowing it to be reused for the newItemOrderingStage
. If you are using theorderingStrategy
property, your implementation ofItemOrderingStrategy
will need to be retargeted at the new definition. - MDA-238: All uses of the Guava functional interfaces (
Function
,Predicate
andSupplier
) have been replaced with their Java 8 equivalents.- This aligns the metadata aggregator with other Shibboleth projects based on the Java 11 platform.
- This change should be largely transparent, but if you use Java configuration you should note that
Predicate
's method name has changed fromapply
totest
.
- MDA-239: The collection of items passed to an
ItemCollectionSerializer
is now explicitly annotated as@NonnullElements
. This constraint was previously assumed by implementations. - MDA-240: The
QName
constants used as part of the API ofEntityRoleFilterStage
have been moved to theSAMLMetadataSupport
class. This will affect configurations which use those fields directly, but not configurations which construct their own equivalentQName
s. - MDA-242: The entire framework has been reviewed for thread safety. The major highlights of this are:
- Implementations of
Item
are no longer expected to be@ThreadSafe
and in fact are expected to be@NotThreadSafe
. In particular, theDOMElementItem
implementation has always had mutable but unsynchronized contents both in the DOM data it wraps and in theClassIndexedMultiMap
that is used to store the item'sItemMetadata
(although theItemMetadata
objects themselves are immutable and therefore thread-safe). Find more about this topic and its implications in the Javadoc for Item. - All classes that are part of configurations (pipelines, stages, validators, serializers, strategy functors etc.) are now
@ThreadSafe
or@Immutable
. - These revisions have resulted in a number of minor changes to the API, such as the removal of some getters provided for non-property values and the movement of some non-API classes to "impl" sub-packages.
- Implementations of
- MDA-247: The
ComponentInfo
class is now@Immutable
as required by allItemMetadata
subclasses. Callers need to migrate to a new constructor, as the existing ones relied on the presence of setter methods; all setter methods have been removed. - MDA-248: The
Item
andItemMetadata
interfaces no longer extendSerializable
. This dated back to early design work related to state management in the Shibboleth V3 identity provider. The IdP later took a different direction, but the unnecessary constraint remained in the MDA until now. The effect of this removal is mainly to simplify implementations, and remove the need for extension classes to include aserialVersionUID
variable. The inability to use Java serialization on these classes is not expected to be noticed in practice. - MDA-253: The signature of the
Stage
interface'sexecute
method has changed fromCollection<Item<T>>
toList<Item<T>>
to signify that the ordering of the items is significant, as it is for almost all use cases. This has always been the case in practice as the underlying implementation provided bySimpleItemCollectionFactory
is anArrayList
. This should not significantly affect existing deployments, but will affect downstream packages whereStage
s are defined. - MDA-254:
ItemIdentificationStrategy
is now a generic interface, parameterised by the type ofItem
to be identified. This makes it possible to write type-safe implementations of the interface specialised for specific types ofItem
such asItemIdentificationStrategy<Element>
to processItem<Element>
. - MDA-257: The contract implemented between
AbstractItemMetadataSelectionStage
and its subclasses (ItemMetadataFilterStage
,ItemMetadataTerminationStage
,StatusMetadataLoggingStage
) has changed to add a type bound for the selection criteria, and to pass aClassToInstanceMultiMap
of that bound back to the subclasses. If you have a custom subclass ofAbstractItemMetadataSelectionStage
you will need to track this change. It should not affect existing deployments unlessStatusMetadataLoggingStage
has wrongly been passed selection criteria which were not subclasses ofStatusMetadata
.
Improvements
- MDA-183: the
compromised-1024.txt
andcompromised-2048.txt
resources have been extended with keys shipped with some releases of the Jetty container.
...