Provide Jakarta compatible build

[fanste]

JakartaEE 9.x is available which uses a new package jakarta instead of javax. Therefore the currently available jars are not compatible with runtimes based on JakartaEE 9.x.

A possible solution would be the usage of the eclipse transformer plugin, which produces an additional jar file with updated imports, etc.

            <plugin>
                <groupId>org.eclipse.transformer</groupId>
                <artifactId>org.eclipse.transformer.maven</artifactId>
                <version>0.2.0</version>
                <executions>
                    <execution>
                        <id>jakarta-ee</id>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <phase>package</phase>
                        <configuration>
                            <classifier>jakarta</classifier>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

[bramhaag]

Has there been any progress on this? It has been more than a year since Jakarta EE 9 was released.

[josemgut]

The change is very easy, but once you make it. the version is not valid for systems with older libraries. I don't know how to do it in a sustainable way.
As I needed this in an app running in Tomcat 10, I made a fork and did the changes. I worked fine after I managed to fix a problem about the organization of resources inside the resulting ZIP.

[lounagen]

I need this jakarta.servlet compliant dependency too.

For now i will duplicate the 2 dummy Auth/ServletUtils classes on my side and manually change the servlet pkg name, but it would be better to avoid such fork.

I tried a workaround with zero java code impact in #379 to be 100% retro-compatible, please let me know if such trick could ever go upstream to avoid maintaining the dummy fork (any advice to improve are welcome).

[markkolich]

I think it would be ideal if java-saml refactored out all direct dependencies on javax.servlet.* and jakarta.servlet.*.

Meaning, replace all usages of HttpServletRequest and HttpServletResponse with a couple of new interfaces, say com.onelogin.saml2.http.HttpRequest and com.onelogin.saml2.http.HttpResponse. These new interfaces would define the minimum set of methods required for java-saml to work - surely not every method in the existing HttpServletRequest and HttpServletResponse interfaces is required for java-saml?

With that swap in place, the consumers of this library could provide their own HttpRequest and HttpResponse implementations based on either javax.servlet.* or jakarta.servlet.* (whatever Java/Jakarta EE implementation they happen to be using).

In theory, this would also allow java-saml to be used outside of servlet containers, e.g., what several of us we're hoping for in #115.

And FWIW, I understand what I'm proposing is effectively a backwards incompatible change. But it definitely seems like this is the right seam on which java-saml should divorce itself from specific servlet implementations and allow the user of the library to choose by providing their own HttpRequest and HttpResponse implementation.

CC // @pitbulk

[dsvensson]

FWIW, other project have started with two release tracks, one for javax, one for jakarta. Dropwizard, and Hibernate to name a few.

[krzysztof-osiecki]

Any chance for going forward with than anytime soon? Payara Community plans to work only with jakarta starting from version 6 so it will be crucial to make it usable with payara community.

[veselov]

@pitbulk ping?
We also ran into this, and now have to use a custom branch. #379 looks like a reasonable solution for this...

[lounagen]

Hi @veselov ,

#379 looks like a reasonable solution for this...

I made this PR to share a quickwin workaround without in-depth code modification, but i totally agree with the @markkolich 's comment above: all these specific servlet-like dependancies should move out of the highlevel helper methods of the project, and to be replaced by samples to load a generic "onelogin servlet" from all other servlets-like object (javax, jakarta, jersey, ...): Basically, the underlying code doesn't need a real servlet but only some fields (url, http verb, ...) and a callback for the case when there is an automatic redirection

[jeroenvs]

Are there any plans for supporting jakarta in the near future? An additional jakarta classifier dependency would be ideal.

[pitbulk]

HI all, we need to work on a long term solution.

Is #379 ok or should we go for the solution proposed by @markkolich?

[mauromol]

I personally think @markkolich solution is better. I don't have looked at this thoroughly, but I remember servlet dependencies are mainly (only?) in the toolkit project, rather than in the core project. If we could create a common toolkit project independent of the servlet API and then two additional projects toolkit-jee and toolkit-jakarta on top the common toolkit project, the consumer applications may use one of these two top-level dependencies, depending on whether they need the JEE or the Jakarta one. The current Auth class would be split into a common part in toolkit (independent of servlet API) and a top interface to be put in toolkit-jee, perhaps with the same API (and possibly package?) of the current one. Then, another JakartaAuth could be put into toolkit-jakarta which does the same of Auth but uses Jakarta API.
This is just brainstorming.

[veselov]

#379 is OK, i.e., it works. It's also along the path that most of the J2EE-based libraries have taken to resolve this mess.
On @markkolich 's solution - it will be beneficial to this library to have a non-J2EE based implementation. Doing this separation still requires a solution on what to do with J2EE bindings.

Whether you want to lose all J2EE dependencies should, IMHO, be based on how much general interest there is to do so. Are there other libraries that do server-side SAML, and are not tied with J2EE APIs?

There is OpenSAML, that seems to have stagnated in general. I can't even find their JavaDocs.
There is Oracle SAML, not sure if it's generally available as a module, that doesn't seem to be using J2EE
There is pac4j, IDK if it supports SP side operations, that has bindings for different framework, including J2EE

So, IMO - do #379 right now, so people don't have to use their custom solutions, and then work on isolating from J2EE separately.

[markkolich]

@pitbulk @veselov @mauromol @lounagen here's my proposed long term solution: #395 which completely removes all J2EE dependencies from core and toolkit.

I ripped out all usages of the servlet API and completely divorced core and toolkit from anything J2EE Servlet related. The consumer of the library has to provide their own HttpRequest and HttpResponse implementations. For convenience, I introduced java-saml-servlet-javax and java-saml-servlet-jakarta which are working (sample?) implementations for javax.* and jakarta.* containers.

Consumers outside of a servlet container can provide their own implementations (Spray, Akka, Play, etc.) of HttpRequest and HttpResponse.

Additional notes are in the PR.

Thoughts and feedback are very welcome.

[paulrutter]

Until a jakarta version is out, i have a workaround thats quite easy to use and works well.

• add compile dependency on https://mvnrepository.com/artifact/org.apache.felix/org.apache.felix.http.wrappers/1.1.2
• add compile dependency on https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api/4.0.1
• use HttpServletRequest / Response from that library as wrapper for the jakarta counterparts. E.g. https://github.com/apache/felix-dev/blob/master/http/wrappers/src/main/java/org/apache/felix/http/javaxwrappers/HttpServletRequestWrapper.java

For example:

Auth auth = new Auth(settings, new HttpServletRequestWrapper(request), new HttpServletResponseWrapper(response));

Those wrapper classes wire all methods from jakarta to javax namespace used in java-saml.