...
We only ever inject HttpServletRequest
or HttpServletResponse
into an object if it is known to have a short life (which means exactly one place - org.opensaml.saml.saml2.profile.impl.ValidateAssertions.AssertionValidationInput
. In all other places we inject a java.util.function.Supplier
. Two new beans are set in global-system which return the object directly from the TLS.
Moved Migration of net.shibboleth.utilities.java.support .net → net.shibboleth.shared
codec
Definitely used a fair bit, but the StringDigester can be rewired via Spring and the HTMLEncoder was left stubbed for compatibility. The others should be mostly used in code only, but we may end up wanting stubs for Base32/Base64.
collection
Mostly these are our interfaces and APIs, but Pair is an exception that has a parent bean but likely it came later than 3.0 so might be an issue. Discussed possibly migrating off of Pair to Java Records.
component
Our APIs by and large.
net
Impacts a few APIs some might use in scripts to do servlet-y things, but should be rare. IPRange in particular tends to be used with String conversions via Spring.
...
httpclient
...
Used in some APIs but not likely by many deployers. One exception is the HttpClientSupport class which gets used in scripts to process response bodies, eg. in the HTTP data connector. To maintain compatibility, a stub with warnings was left behind.
...
resolver
Our APIs used by a lot of our code but hopefully not by deployers much.
resource
One interface, our non-Spring version of Resource, really just used in APIs and not as a class itself.
scripting
Used by our higher level classes.
security
Command line tool changes but those are captured in shell files we supply. The AccessControl interfaces move but I don’t expect deployers would have directly interacted with that service as an API. Various beans move but they’re system-defined in almost all cases. Biggest API ripple is the IdentifierGenerationStrategy stuff, but that’s unlikely to affect anybody but us and probably needs more work given the use of impl classes all over the code base.
...
xml
Moved BasicParserPool and an errorhandler class into an impl subpackage. Lots of Java code will have used the various XSupport classes and likely depend on the ParserPool and exception classes, but I do not expect deployer impact of much significance.