<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 2/15/16 12:26 PM, Francesco
Barcellini wrote:<br>
</div>
<blockquote cite="mid:56C20A3B.5010706@intesigroup.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
Hello,<br>
<br>
I used opensaml V2 and I'm trying to migrate to V3 version. <br>
<br>
After library migration the following java code did not compile;<br>
<br>
SAMLMessageDecoder decoder = new HTTPRedirectDeflateDecoder();
<br>
BasicSAMLMessageContext messageContext = new
BasicSAMLMessageContext();<br>
messageContext.setInboundMessageTransport(new
HttpServletRequestAdapter(req));<br>
<br>
because the compiler didn't find the classes
BasicSAMLMessageContext and HttpServletRequestAdapter.<br>
</blockquote>
<br>
<br>
Right, those don't exist anymore. Read on...<br>
<br>
<br>
<blockquote cite="mid:56C20A3B.5010706@intesigroup.com" type="cite">
<br>
As declared in this url<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://shibboleth.net/pipermail/announce/2015-May/000112.html">http://shibboleth.net/pipermail/announce/2015-May/000112.html</a><br>
<i><br>
</i><i>the "compatibility between V2 and V3 is extremely
substantial".</i><br>
</blockquote>
<br>
It probably isn't sufficiently clear there in that note, but what is
really meant is compat between the v2 and v3 IdP's, from a
deployer's perspective. Support for legacy config files, endpoints
and so on.<br>
<br>
Compat for stuff at the Java level is a completely different story.
For example, plugins for the IdP v2 would not work as-is in the IdP
v3. There's both simple class/package changes as well as in most
cases complete architectural changes at the software level.<br>
<br>
<br>
<br>
<blockquote cite="mid:56C20A3B.5010706@intesigroup.com" type="cite">
<br>
Starting with new project that need a migration from old V2
libraries to new V3 libraries I would be "extremely" <br>
sure that all the V2 classes are presents in V3 packages. Is this
guarantee?<br>
<br>
</blockquote>
<br>
No, not at all. This is discussed in detail in our Java product
versioning policy. [1] We're very strict about what we will change
in a patch, minor and major release. Specifically, for a new major
version there is no guarantee of API compatibility at all.<br>
<br>
So at the level of Java code, they aren't (necessarily) guaranteed
to be compatible at all across major versions. The v2 and v3 stacks,
both IdP and OpenSAML, at some level are completely different in
that, at a minimum, every single class lives in a new package. Any
Java code being migrated from one to the other would at a minimum
need to have imports changed. In some cases there are some simple
class renames, e.g. "-Helper" -> "-Support". In some cases some
more substantial refactoring to different classes which have
different APIs.<br>
<br>
In reality, most of OpenSAML is largely functionally the same and
has a similar API between v2 and v3, and a very large percentage of
classes (modulo the package qualifier) are largely 1-for-1. That
includes things like XMLObject providers, XML Signature and XML
Encryption support, and other security-layer components. In fact it
changed much less than the IdP v3, where most everything was
completely rewritten for the new Spring Web Flow architecture.<br>
<br>
The thing that changed most substantially in OpenSAML v3 is the
messaging support components: the encoder/decoder support for
bindings, the message contexts and the fundamental way that
inbound/outbound message data is processed. That's a totally
different set of components and API. <br>
<br>
<br>
<blockquote cite="mid:56C20A3B.5010706@intesigroup.com" type="cite">
So, about my example code where is my error?<br>
</blockquote>
<br>
It's just a completely different API now for the decoders and
message contexts. What I would suggest is looking at some existing
examples in the unit tests, for example for SAML 2 bindings. [2]
The v3 API is still very simple, just different and more flexible.
The complex v3 message context inheritance hierarchy turned out to
be a real nightmare, that's why it got changed.<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/DEV/Java+Product+Version+Policy">https://wiki.shibboleth.net/confluence/display/DEV/Java+Product+Version+Policy</a><br>
<br>
[2]
<a class="moz-txt-link-freetext" href="http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-saml-impl/src/test/java/org/opensaml/saml/saml2/binding/decoding/impl/">http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-saml-impl/src/test/java/org/opensaml/saml/saml2/binding/decoding/impl/</a><br>
<br>
</body>
</html>