Add support for Jakarta Servlet API Specification #768
Replies: 21 comments 56 replies
-
|
It's been a LONG TIME since I set up a Spring application, but IIRC the issue is that ESAPI codes against the servlet-api but it isn't packaged with it. I would first ensure that your application dependencies are explicit. https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api Some application servers have their own methods for supplying the servlet-api, I know with WebSphere we deployed it as a web app server library so applications didn't need to include it as their own dependency. We Code against the specification only so there is no need for any explicit support for Jakarta, Websphere, etc. You supply your own implementation. It is 100% supported, you just need to fix your dependencies. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for commenting back so quickly. Unfortunately the newest version of Spring and Spring Boot are using Jakarta Servlet API specification and no longer using Java Servlet API specification hence the new package for Jakarta's servlet api is starting with jakarta.servlet and not java.servlet. Also the newest versions of Tomcat and Jetty are now using this new Servlet API specification so I imagine other folks will be experiencing our pain soon. |
Beta Was this translation helpful? Give feedback.
-
@guadgarcia, it looks like jakarta.servlet-api changed this between their 4.x releases (when it was using We have to support older versions of javax.servlet-api because many ESAPI clients are still running older versions of Java application servers and (at least originally) that was what the Glassfish reference model used as well as WebLogic server. And since it is the app server that generally decides that, maybe you need to switch to a different default app server. (I think you use an embedded version of Jetty, right?) That's the only thing I can think of beyond forking ESAPI and making those changes in your fork. (Come to think of it, the ServiceMix folks put an OSGI wrapper around ESAPI. Maybe you could get that to work? See https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.esapi.) However, if you can come up with some other suggestion that will allow us to support clients using application servers that use javax.servlet-api as jakarta.servlet-api that doesn't require significant code changes to those ESAPI clients, I'm all ears and will gladly reopen this and we can consider working on something. In the meantime, I'm going to convert this issue to a Discussion and hopefully get some more ESAPI community eyes on it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback @kwwall. We are using Tomcat but switching servers won't resolve the issue since Spring itself also uses the newer Jakarta Servlet API. I haven't dug through the ESAPI codebase but my initial thought is to maybe create a servlet wrapper interface in ESAPI that would hide the underlying Servlet API specification being used. Then create servlet wrapper implementations for each of the different servlet api specifications. Perhaps a property could be added to ESAPI.properties defining which servlet wrapper implementation to use. At the end of the day I assume this would still have a ripple effect through the code and could possibly break existing usage of the current API. |
Beta Was this translation helpful? Give feedback.
-
|
So, does Spring 6 require a Java app container that supports the jakarta.servlet-api? In other words, if one wanted to update to the latest version of Spring (looks like 6.0.4 when I checked a few hours ago) and they were using Tomcat 8.5, that they would have to move to Tomcat 10? If so, that's going to cause all sorts of chaos. Not sure what RHEL version supports Tomcat 10 out-of-the box, but it probably isn't RHEL 8 and certainly not RHEL 7, so this will require customized docker containers, etc. |
Beta Was this translation helpful? Give feedback.
-
|
The timing here was great. We are just looking into the same issue with our projects. This is an issue with the new Servlet API version. The new API comes with package names like This is frustrating because it looks like the servlet API is only used to output the local server IP and port, and we aren't even using that functionality. It looks like as a workaround, you can manully create the Servlet API classes in your own codebase. For example, a bunch of empty class/interface files like this: package javax.servlet;
public interface ServletResponse extends jakarta.servlet.ServletResponse { }And then do the same thing for ServeltRequest/HttpServletRequest/HttpServletResponse/HttpSession. You also have to do the same for Cookie and ServletException (and include all the constructors for those, calling the corresponding But... we definitely shouldn't have to do this... (and it likely breaks other 3rd party JARs that are properly detecting what version of Servlet API is on the classpath) |
Beta Was this translation helpful? Give feedback.
-
@JosephWitthuhnTR -please can you explain how you did this trick to bypass the "java.lang.NoClassDefFoundError: javax/servlet/ServletRequest" error? Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
@ebarry-vp I think I explained what I did above. What question did you have? We've moved our projects off of the |
Beta Was this translation helpful? Give feedback.
-
|
@JosephWitthuhnTR - I created the empty interfaces/classes under my own package javax.servlet. Still getting the NoClassDefFoundError... Am I missing something perhaps? |
Beta Was this translation helpful? Give feedback.
-
|
@ebarry-vp If you've created classes with those names, and they are on your classpath, I would expect that would deal with the NoClassDefFoundError. I'm not sure what your environment or setup looks like that that wouldn't work. As I mentioned above, it is a somewhat messy hack that could easily have side effects or not work for all situations. |
Beta Was this translation helpful? Give feedback.
-
|
@JosephWitthuhnTR got it, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
This isn't a fix, but I wonder about this as a workaround. In the stack trace I posted above for our use case, it blows up on line 54 of of This is the first line of a block that looks like this: HttpServletRequest request = ESAPI.currentRequest();
if (request != null && logServerIP) {
appInfo.append(request.getLocalAddr()).append(":").append(request.getLocalPort());
}We below up on that first line when we call I think that would both alleviate the exception for our use case (since we aren't logging server IPs) if we refactor this slightly: if (logServerIP) {
HttpServletRequest request = ESAPI.currentRequest();
if (request != null) {
appInfo.append(request.getLocalAddr()).append(":").append(request.getLocalPort());
}
}This moves the line that blows up into the if block and it only gets processed in the use case where it needs to be processed. Again, not a fix for the overarching issue, but perhaps a fix/workaround for certain use cases where this IP information is not needed? |
Beta Was this translation helpful? Give feedback.
-
|
That could fix it (and similar cases), but As for the IP addresses not being needed, that may be true for your particular use case, but I don't think we can make that assumption in general. And if Tomcat and Jetty and others Java app servers start using jakarta.servlet-api rather than javax.servlet-api, the scope of the problem definitely goes beyond that. As an example, of the difficulty of this, there are 5 different ESAPI classes that act as Java EE Servlet Filters. How do you write a Unless someone can think of an ingenious solution, this is going to be a tough nut to crack. Not impossible perhaps, but certainly difficult. So we need to think big picture here. |
Beta Was this translation helpful? Give feedback.
-
|
@kwwall I 100% agree about the need to think big picture, and that this fix doesn't address many use cases, but I'm assuming it might be a little bit before whatever that larger fix looks like is available. This fix would allow those of us with a need to use Spring 6 (but who aren't using the Servlet based features) to get by in the meantime while that is worked out (and without needing to wait for the next major ESAPI version). I took a quick look, and changing this one line seems to be enough to make this work (without the "hack" of creating new servlet API classes) for our simple use case using this logger. And I don't think it is a bad change - it isn't "dirtying" the codebase just to make it work. Instead it saves us the reflection involved in getting the HTTP Utilities class to grab the current request by checking a simple boolean first and only executing that code if needed. In short, this isn't a replacement for a real fix at all. But it might be a small change that would let some of us get by while we wait for whatever the bigger change ends up looking like. |
Beta Was this translation helpful? Give feedback.
-
|
@JosephWitthuhnTR wrote:
See this comment for a list of all the places that use |
Beta Was this translation helpful? Give feedback.
-
|
@kwwall I have confirmed that this fix works fine for everything we are using the JAR for (if there are other use cases where this happens, they must already be properly nested in I'll work on getting a PR issued. |
Beta Was this translation helpful? Give feedback.
-
|
@kwwall I've submit a PR and did my best to follow the instructions for contributors. Please let me know if you have any feedback or if I should be doing something differently. |
Beta Was this translation helpful? Give feedback.
-
|
This is an off-the-wall idea (hey, I resemble that remark), but one possibility might be to provide a tool that would go through the byte code in the ESAPI jar and convert all the javax.servlet references to jakarta.servlet references and create an esapi-jakarta version of the jar. Anyone think that would have a prayer? I've never done anything like that so I have no idea of how much effort it might involve, who knows, maybe someone already as a tool similar to that, or better, a Maven plugin. |
Beta Was this translation helpful? Give feedback.
-
|
Possible solution? https://github.com/apache/tomcat-jakartaee-migration Not clear if it works on source code or byte code though. The ESAPI team doesn't want to have to maintain 2 source trees (the core team is only 3 people), so I'm hoping it operates on byte code. |
Beta Was this translation helpful? Give feedback.
-
|
Hi kwwall, We do have a small maven plugin, to transform the javax* classes to jakarta.* classes from eclipse, (https://github.com/eclipse/transformer) and is used by some of the projects which are in similar situation, here we don't have manage two version of the code, rather this plugin takes care of publishing a special jar with jakarta as classifier to a maven repo. In Project pom.xml : On client side we just have to add one new element called classifier during the dependency declaration. Can we please see if this is something we can take up. |
Beta Was this translation helpful? Give feedback.
-
|
@abtabhi - Does this Maven plugin result in building an uber jar or does it exclude dependencies? If it excludes all dependencies, I think it's worth looking into. But I don't think uber jars is a viable solution. |
Beta Was this translation helpful? Give feedback.
-
|
No it does not creates any Uber jar it will end up creating a separate esapi jar file with same class structure as that of the original one. |
Beta Was this translation helpful? Give feedback.
-
|
I will give it a try when I get a bit of time, although I'm presently working to complete a presentation for a BSides talk so it may be a short while. If it's urgent, someone can submit a PR as that will make it faster. @abtabhi - Perhaps you can drop me an email so if I have questions about how to use this plugin, I can ask you directly. You can find my email as a mailto: link under Leaders on the OWASP ESAPI wiki page. |
Beta Was this translation helpful? Give feedback.
-
|
I think the Maven shade plugin might be able to help here…
Steps…
1) include javax.servlet in a copy of the esapi jar file
This is the copy we would modify
See the <filter> bit below
2) relocate javax.servlet to jakarta.servlet
This would change all references to those methods in ESAPI code
See the <relocation> bit below
3) delete javax.servlet classes from our jar
Would probably require some other maven plugin
Can’t be that hard
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.4.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<filters>
<filter>
<artifact>javax.servlet:javax.servlet-api</artifact>
<includes>
<include>**</include>
</includes>
</filter>
</filters>
<relocations>
<relocation>
<pattern>javax.servlet</pattern>
<shadedPattern>jakarta.servlet</shadedPattern>
</relocation>
</relocations>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Not pretty but beats writing the code to modify the ASM (which I can do if this doesn’t work)
…--Jeff
From: Kevin W. Wall ***@***.***>
Date: Thursday, January 12, 2023 at 7:17 PM
To: ESAPI/esapi-java-legacy ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [ESAPI/esapi-java-legacy] Add support for Jakarta Servlet API Specification (Discussion #768)
This is an off-the-wall idea (hey, I resemble that remark), but one possibility might be to provide a tool that would go through the byte code in the ESAPI jar and convert all the javax.servlet references to jakarta.servlet references and create an esapi-jakarta version of the jar. Anyone think that would have a prayer? I've never done anything like that so I have no idea of how much effort it might involve, who knows, maybe someone already as a tool similar to that, or better, a Maven plugin.
—
Reply to this email directly, view it on GitHub<#768 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUUFTDTA5X35EW7P4BOWJTWSCNH5ANCNFSM6AAAAAATZQU6JI>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the pointer Jeff. Will look into it. |
Beta Was this translation helpful? Give feedback.
-
|
@planetlevel - I read a bit through the Maven Shade Plugin, here are my concerns based on my minimal understanding:
So some questions:
|
Beta Was this translation helpful? Give feedback.
-
|
If we're going to make the attempt to support a new dependency version I'd much rather make a branch that I can test and review over trying to allow extension of the current bundled jar. I have no doubt that we can make the jar/class swapping work, I contend that we should not. If we explicitly support swapping this jar out then we will be receiving bugs and feedback based on that configuration. We have enough difficulty getting feedback with flat-file property configurations, and I do not think that this solution will be at all maintainable or sustainable. If we're going to support this then I believe the only long term option is to branch and re-version. At that point we have a consistent way of determining what each client is using by having them provide the version of the artifact in the environment. |
Beta Was this translation helpful? Give feedback.
-
|
@jeremiahjstacey - At the present, I'm not sure of the details of how all this would work out. I get your point with making this more difficult in reporting issues, but we can somewhat address that via our issue templates. It's not perfect, but workable. What I don't understand is your comment of "this is a breaking API change". My thoughts is that we would upload two jars to Maven Central. There would be our usual 'esapi-version.jar' and a new 'esapi-jakarta-version.jar'. The former would stay the same, so no "breaking API change" there and the 2nd would be a new jar, so ditto with that. Am I missing something here? |
Beta Was this translation helpful? Give feedback.
-
|
I agree. This is a bit of a unicorn type situation. It's pretty rare for package names to change like this. |
Beta Was this translation helpful? Give feedback.
-
|
@kwwall, please disregard my comment on compatibility and the idea of a "breaking API change". I was conflating the API that ESAPI exposes (public API) with the API ESAPI uses. Publishing another Jar is basically having a branch in the develop branch. That does help with getting better user feedback and bugs, but at the end of the day it is still another line of development that will need to be integrated and tested. If we go this route, I think a formal branch is a better option. |
Beta Was this translation helpful? Give feedback.
-
|
Reading this bug reports makes me slump into my chair. I'm thinking about the problem it is going to cause for thousands of development teams. Sigh... Is it possible to tune the behavior of ESAPI with a command line option? The option would control whether ESAPI uses (This is another one of those times I wish Java had |
Beta Was this translation helpful? Give feedback.
-
|
@noloader - Unfortunately, there are a lot of places where |
Beta Was this translation helpful? Give feedback.
-
|
After a little hunting it looks like this change was initiated back in 2018. I have no explanation as to why I haven't heard of it yet. I'm guessing that Spring is just now getting to enforcing this perhaps? I left a question over on another github asking why "javax" couldn't be used... it was dropped offhandedly. |
Beta Was this translation helpful? Give feedback.
-
|
Spring 6 and Spring Boot 3 were released near the end of Nov 2022, and those were the first versions to use the new Servlet API. My suspicion is that many projects will end up moving to the new Servlet API as they perform their Spring upgrades. |
Beta Was this translation helpful? Give feedback.
-
This had been debated for a long time, and wasn't done on a whim. The core issue was that the If it helps, I did a writeup about the transfer process here: https://blogs.oracle.com/javamagazine/post/transition-from-java-ee-to-jakarta-ee |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate the writeup and the history. Let me be clear: I wasn't trying to throw shade. I am more shocked that despite all the communities that I'm involved in at work, this question never once came up. I suppose I should have been on higher alert with Oracle changing the Java license... THAT caused a ruckus. I never would have imagined that they'd want to divest control over J2EE however. Thank you @arjantijms |
Beta Was this translation helpful? Give feedback.
-
|
My preference is that we should just update to the latest dependencies for the project, and keep up-to-date. The most recent ESAPI should use the most recent versions of all its dependencies (accounting for the java 8 requirement). If someone requires an older reference to one of our dependencies, then they should use the version of ESAPI compatible with their needs -- until they can update. Keep rolling forward with the expectation that everyone is coming with us. |
Beta Was this translation helpful? Give feedback.
-
|
The package name switch was done in the JakartaEE 9 standard (current is 10). That together with the SpringBoot3 / Spring 6 release means, that both major Java Enterprise frameworks enforce the new package names. So to keep relevant you really should invent a branch strategy supporting this. We currently are also switching to SpringBoot 3 and it seems that we have to remove ESAPI because of this problem at all |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, @jeremiahjstacey - if we can't find some alternative that works, I'd have to agree on @RupprechJo here. We would need to branch it and support the older Now, if I can come up with a way that we can switch to Jakarta 10 but also have a way that people can revise their builds to do shading to get back the old behavior, then sure, we can probably do what you propose without any branching and deploying multiple ESAPI jars, but that remains to be seen. |
Beta Was this translation helpful? Give feedback.
-
|
I know no technical solution, that can support the two different servlet APIs in different package names with one implementation of ESAPI. But if the differences are almost only the package names, maybe merging between those two branches is not too hard. |
Beta Was this translation helpful? Give feedback.
-
|
@kwwall Apache Commons File Upload will not be supported when we move forward to Jakarta. I don't necessarily disagree with the idea of providing two jars, but I'd prefer to put it off for as long as possible. We can create a branch from a versioned fork at any point, from what I think I understand about git. By removing the File Upload dependency we can set it up so the next ESAPI release addresses all currently known issues, tag it, then roll forward to the Jakarta update. If the need arises for content to be back-ported then we can create the javax branch and provide that artifact as well, but I'd prefer to not plan that strategy until it is required. We know we are capable of managing multiple branches, I'm just hoping we won't have to. |
Beta Was this translation helpful? Give feedback.
-
There are 2 ways that I'm aware of that this could be done. One is to replace all the places where ESAPI uses javax.servlet classes and replace them with The 3rd option and one that I think most applications that have heavy dependencies on libraries that use the javax.servlet packages will end up being forced todo, is to have their applications themselves do the "shading" themselves. For applications that have dependencies on several such FOSS 3rd party libraries, I suspect that they are going to have to do that as a temporary solution because waiting for all your dependencies to be converted may be a long time. Some are likely never to covert to Jakarta Servlet API. I'm investigating how easy it is to do that now but I have a lot of other things sucking up my time at the moment. |
Beta Was this translation helpful? Give feedback.
-
|
@jeremiahjstacey - I will email you and @xeno6696 about removing the Apache Commons File Upload dependency that you mentioned in #768 (reply in thread). I don't want to clutter up this discussion with that side note. That said, it would be useful if all 3 of us could do a quick 30 minute or so virtual meeting sometime soon. I think the pros and cons need to be well understood and discussed before we make any major moves. Because once we commit to Jakarta Servlet API, there's no turning back and I think we have to commit to both at that point. So let's plan to discuss this. |
Beta Was this translation helpful? Give feedback.
-
|
Which esapi version support jakarta.*? |
Beta Was this translation helpful? Give feedback.
-
|
None, as of yet. The package renaming means we will have to support 2 versions of ESAPI or move to Jakarta and abandon our existing users who are still using Spring Boot 2.x or Spring 5.x or earlier, which is a lot of them. I think the most promising path is to try the Maven Shade plugin described at #768 (comment). That said, there's no reason why you couldn't try that approach as an ESAPI user. Because we only have 3 main contributors, that may be the path we end up taking. |
Beta Was this translation helpful? Give feedback.
-
|
The maven shade plugin unfortunately is NOT a solution for this problem. It creates an uber jar, which means, it packs all your dependencies in one jar together with your source code. So if you use such a jar together with the regular dependencies, you get duplicated classes. But maybe this is a solution: |
Beta Was this translation helpful? Give feedback.
-
|
This is actually an interesting strategy. This would likely work better with a Gradle build, where you have the canonical "old" source, then use OpenRewrite to generate the new source from the old source and compile that into a different JAR. These two JARs could be published with different GAV coordinates? Or with different Gradle Metadata https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html |
Beta Was this translation helpful? Give feedback.
-
|
If you support 2 versions, is the only difference going to be the package names? If that's true, can you make future changes in one branch and then merge everything, except package name differences, to the other branch? This doesn't seem like a ton of effort and you may only need to do it a few times since it appears changes are made roughly every 6 months and, in a year or 2, it seems reasonable to drop support for the javax.* version completely. Thanks... I appreciate the work you guys do on this project. |
Beta Was this translation helpful? Give feedback.
-
|
Well, it is more effort than you think it is. We only have 3 of us who regularly contribute to this project and all of us have families and full-time jobs. There are 41 different Java source files under 'src/main/java' that would need to be ported. And while we could that initial split easily enough, we almost certainly would need more or less duplicate everything. It's not the initial work that is our concern, but rather then ongoing maintenance. Now instead of fixing something in one place, there are 2 places to deal with it so maintenance becomes almost twice the amount of work even if the change has nothing to do with the Servlet API at all. However, the bigger drawback that I see is there is at least one direct dependency that I'm aware of (Apache Commons FileUpload) that has a dependency on the Servlet API and I don't think that they've done a drop-in replacement for a version that uses the latest Jakarta Servlet API changed its package namespace from javax.servlet to jakarta.servlet. (I think other packages were changed as well, but none that I aware of.) As an example, ESAPI's So, no, we've decided that the ESAPI development team is not going to do this. This whole thing by the Jakarta team run by the Eclipse foundation has not given library developers the heads up they need. (For example, we originally had a 2 year deprecation policy before we would actually remove an old interface. We felt that we needed to give our ESAPI clients adequate time to develop alternate versions or workarounds, etc.) But this whole thing has taken us by surprise. And not just us, but many other application developers. I've spoken to 4 or 5 other Java developer team leads where I work and not a single one of them knew this was a problem. I was the first person at our company to become aware of it (or at least, bothered to mention it to upper management.) That still leaves you with an option though. You could do what you are asking us to do, which essentially would be to fork ESAPI/esapi-java-legacy and spin it off into a Jakarta version. ESAPI is released under a BSD license which is a very liberal FOSS license, so you technically you wouldn't even have to make your changes back to the larger community. Or, if someone wants to come up with some funding to pay 1 or 2 developers to do that, we may be able to find some people (not the 3 of us though). I wouldn't mind providing occasional guidance, but we just can't afford to do this. The 3 of us keep on wanting to dive in and start working on ESAPI 3 (ESAPI/esapi-java) full time, but because of constant bug-fixing and patching, we don't even get a chance to do that. If we take on what you are proposing, I don't think we will ever get to ESAPI 3. (FYI: For ESAPI 3, since it is a change in the major release #, there will be a lot of other breaking changes so we are almost certainly only going to support the Jakarta Servlet API.) |
Beta Was this translation helpful? Give feedback.
-
|
@alecode84 - Converting from |
Beta Was this translation helpful? Give feedback.
-
|
I think this 2-part write-up is relevant to this discussion, so I am dropping a couple of links here: |
Beta Was this translation helpful? Give feedback.
-
|
Hello ESAPI team, Is there a plan to provide a jakarta compliant jar in future? |
Beta Was this translation helpful? Give feedback.
-
|
At some point in the future, yes. But I've been busy preparing 2 security presentations and haven't had much chance to work on it. If you are in a hurry to get it, then I suggest modifying the pom.xml (or creating a new one for Jakarta) and submitting a PR. Even if you do that, it still leaves a lot to be done by the ESAPI team (can will have to release it as something else (e.g., esapi-jakarta-2.x.y.z.jar) which along means several administrative changes. But we can't and won't abandon supporting javax.servlet for the 2.x version. (At least not without going through our deprecation process first.) So, you probably were hoping for more, but that's all I got. All of us contributors do have day jobs and families so getting more people to help is the main way to move this forward. Thanks for your understanding in this matter. |
Beta Was this translation helpful? Give feedback.
-
|
@kwwall I've submitted PR #799 as a starting point for getting this project up-to-date with the Jakarta namespace changes. It just creates another JAR in the target directory with the classifier of <dependency>
<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.5.3.0-SNAPSHOT</version>
<classifier>jakarta</classifier>
</dependency>Happy to help get this over the finish line in whatever way I can. |
Beta Was this translation helpful? Give feedback.
-
|
Also, JitPack is just a service that allows you to pull in maven dependencies from GitHub projects, the naming convention wouldn't change once the PR is pulled in. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not through testing or looking at the PR, but I did test it by running ' $ ls -1 target/*.jar
target/esapi-2.5.3.0-SNAPSHOT-jakarta.jar
target/esapi-2.5.3.0-SNAPSHOT-jakarta-javadoc.jar
target/esapi-2.5.3.0-SNAPSHOT-jakarta-sources.jar
target/esapi-2.5.3.0-SNAPSHOT.jar
target/esapi-2.5.3.0-SNAPSHOT-javadoc.jar
target/esapi-2.5.3.0-SNAPSHOT-sources.jarSo, that's probably how Maven's works with Maven Central; it just adjusts the name of the jar that it is expecting to download. But it does address my concern about multiple, distinct jar names, one (the original jar name) for Java EE Servlet API and one for Jakarta Servlet API, with '-jakarta' as part of the file name. So that's just like I wanted. I also confirmed that it does not create an uber jar like the Maven Shade plugin seems to do (at least by default). That said, I it's going to be a complete solution for everything related to Jakarta. We use Apache Commons FileUpload (currently 1.5) and it uses javax.servlet package namespace, so that in turn means anyone trying to use the Jakarta version is going to get a runtime (rather than compile-time) error if they try calling Does anyone know if Apache Commons File Upload is going to release a version that supports the Jakarta Servlet API spec? Once they do, maybe we can figure out how to use that version with the jakarta classifier. If they don't intend doing that, then maybe a uber jar is an approach that will work for that edge case. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, one more thing. I shall not be able to start looking at this again until 9/18 at the very earliest. There is still a lot to do though on this, but at least I think this is a viable path forward. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like Apache Commons File Upload is adding support for <dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-fileupload2</artifactId>
<version>2.0.0-M1</version>
</dependency> |
Beta Was this translation helpful? Give feedback.
-
|
Well, that's going to be a problem then, because it likely will have a different package namespace ( |
Beta Was this translation helpful? Give feedback.
-
|
@jcputney - One more thing to add... I did a quick look at the contents of the target/esapi-2.5.3.0-SNAPSHOT-jakarta-javadoc.jar file that PR #799 created by extracting all the comments into a tmp directory. I then did a recursive grep for |
Beta Was this translation helpful? Give feedback.
-
|
Hi @kwwall and congrats on the PR merge @JosephWitthuhnTR I noticed that #776 was merged in Feb. Does that mean that the 2.5.2.0 release contains the changes? Thanks for helping the open source community! |
Beta Was this translation helpful? Give feedback.
-
|
@alzaki-clgx - Yes, PR #776 was merged in Feb 2023 and 2.5.2.0 release came out in April 2023, so it is included. It is also mentioned (via issue #770) in the 2.5.2.0 release notes. You can see the merged commit that actually fixed this specific issue modified ServerInfoSupplier.java file. Note however that this ONLY addressed a very small, specific niche problem, and not the broader problem in Discussion #768. I have a way forward that looks promising for that, but we're still a long way off on that because it's unclear how that is going to affect the actual release steps used by ESAPI. |
Beta Was this translation helpful? Give feedback.
-
|
Cool! I tried looking for the ESAPI release notes earlier with little luck so this helped |
Beta Was this translation helpful? Give feedback.
-
|
So, good news. ESAPI 2.5.3.0 is now released and is available (shows up at https://central.sonatype.com/artifact/org.owasp.esapi/esapi/2.5.3.0, but not yet visible at https://mvnrepository.com/artifact/org.owasp.esapi/esapi when I just checked). Along with esapi-2.5.3.0.jar though, it seems to have also updated esapi-2.53.0-jakarta.jar which ought to work with the Jakarta Servlet API Specification that uses That said, I'm not sure exactly how to request it as a dependency in Maven or Gradle, etc. Perhaps @jcputney would be so kind as to illustrate how that would work in this discussion before I close this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
I just documented how to use the Jakarta version of ESAPI on our ESAPI GitHub wiki page: Therefore I am marking this discussion as closed. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We are in the process of upgrading our Spring Boot application to use Spring Boot 3.0.1 and we are getting an error related to ESAPI. The issue is happening because ServletResponse is now located in a different package.
Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed: java.lang.NoClassDefFoundError: javax/servlet/ServletResponse] with root cause","context":"","exception":"java.lang.ClassNotFoundException: javax.servlet.ServletResponse\n\tat java.base/java.net.URLClassLoader.findClass(Unknown Source)\n\tat java.base/java.lang.ClassLoader.loadClass(Unknown Source)\n\tat org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:149)\n\tat java.base/java.lang.ClassLoader.loadClass(Unknown Source)\n\tat java.base/java.lang.Class.forName0(Native Method)\n\tat java.base/java.lang.Class.forName(Unknown Source)\n\tat org.owasp.esapi.util.ObjFactory.loadClassByStringName(ObjFactory.java:158)\n\tat org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:81)\n\tat org.owasp.esapi.ESAPI.httpUtilities(ESAPI.java:123)\n\tat org.owasp.esapi.ESAPI.currentRequest(ESAPI.java:70)\n\tat
Beta Was this translation helpful? Give feedback.
All reactions