Jakarta supported version

[npsakthi]

Using java-saml for security. its depends on javax.servlet. my project migrated from 'javax 'namespace to 'jakarta'. current version not supporting for jakarta servlet.

[pietro-saccani]

I'm gonna link here #395 just so that more people can find it.
Man I wish there already was a jakarta-compatible version. We're gonna need it soon-ish and the alternative is a library that's hosted on yet another repository to add to the build.gradle file, and it also uses Guava, which we would rather not have...

[Jerry29]

Is there any update to this ? Can we expect a jakarta supported onelogin any time soon ? If not is there any work around.
I had to upgrade springboot in my project to 3.0.5 and stuck with the javax dependency in onelogin

[tjmackert]

Is there any update to this ? Can we expect a jakarta supported onelogin any time soon ? If not is there any work around. I had to upgrade springboot in my project to 3.0.5 and stuck with the javax dependency in onelogin

I worked around this issue with org.apache.felix.http.wrappers. Still waiting on full jakarta support

[catji12152]

Currently, the latest version of java-saml (2.9.0?) is running 'javax'.
However, since our project is 'jakarta',

「The type javax.servlet.http.HttpServletResponse cannot be resolved. It is indirectly referenced from required type com.onelogin.saml2.Auth」
This error has occurred.

Is there a way to make it work in jakarta?

[pietro-saccani]

Currently, the latest version of java-saml (2.9.0?) is running 'javax'. However, since our project is 'jakarta',

「The type javax.servlet.http.HttpServletResponse cannot be resolved. It is indirectly referenced from required type com.onelogin.saml2.Auth」 This error has occurred.

Is there a way to make it work in jakarta?

A workaround is right above your post. You can use the Apache Felix Http Wrappers library to provide java-saml objects that wrap Jakarta ones and "pretend" to be Javax ones.

If you don't want to use a workaround then no, currently there's no way. You may want to follow this issue: #395
but it hasn't been updated in a long while.
There may be forks that support Jakarta, but if you're in a corporate environment using a potentially unsupported fork may not be a feasible solution.

[jp196]

I would prefer an official build as well. I'm at the stage where I'm seeing what it would take to migrate our app from Tomcat 9 to 10.1. I haven't tried running this yet, but I downloaded the 2.9.0 source, ran the Apache migration utility on it, made a little Gradle build file, and built the JARs successfully. The code changes are literally 4 import statements in 2 Java files; and the java-saml JAR contains a total of 4 class files built from 3 Java source files. I have no reason to think that it wouldn't work. I'm attaching a ZIP file with the source and the pre-built JAR, built with OpenJDK 11 (figured that JDK 11 would provide the greatest class file version compatibility). The JAR and sources JAR are under the java-saml-2.9.0/toolkit/build/libs directory in the ZIP: java-saml-2.9.0-jakarta.jar and java-saml-2.9.0-jakarta-sources.jar. If I think about it, I'll come back here and confirm that it works, once I get past the other migration hurdles. Hope this helps someone.

java-saml-2.9.0-jakarta.zip

[catji12152]

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<%@ page import="org.apache.log4j.Logger" %>
<%@ page import="com.onelogin.saml2.Auth" %>

<%

    Auth auth = null;
    try{
        auth = new Auth(request, response);
    }catch(Exception e){

    }
%>

Thank you so much for letting me know.
But I didn't understand.

In the past, our project has been approached in the form of source code from the JSP screen to the top.
Is there a solution?

[jp196]

For runtime/deployment, you would need to replace the original java-saml-2.9.0.jar with the corresponding java-saml-2.9.0-jakarta.jar from the ZIP file within your WAR file (or from the set of JARs deployed to WEB-INF/lib under your webapp). Tomcat 10.1 (or higher) already provides the necessary jakarta.servlet.http.HttpServletRequest and HttpServletResponse implementation classes for the runtime classpath, as it implements Servlet 6.0 API.

For compiling, I've never used JSP so I am not sure how JSP is resolving the imports for the "request" and "response" parameters - there are no import statements in that code snippet. We use this toolkit in plain Java, and to get that to compile, I had to change the compile time classpath to use the jakarta-servlet-api-6.0.0.jar, replace the original java-saml-2.9.0.jar with the java-saml-2.9.0-jakarta.jar from that ZIP, and change the imports in our application code from:

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

to

import jakarta.servlet.http.HttpServletRequest;
import jakara.servlet.http.HttpServletResponse;

Our team has postponed the migration of our app to Tomcat 10.1, so I haven't had a chance to deploy it to a server configured to support SAML. However, I am about 95% sure that it would work, as the code changes within the JAR were just import changes - there were zero logic changes.