1.6.0-Jakarta

[rgrashel]

Hi all,

It's been many years, since I've been able to contribute to Stripes, but after looking at some recent PRs by community members and seeing several asks (including my own asks), I have taken on the upgrade of the Stripes stable 1.6.0 branch to Jakarta. I'm not 100% complete, because I need to figure out how to get this pushed out to the Maven repositories, but after that, I think this is ready (as-is) for people to try out in their own test environments.

Just a few highlights of goodness in this branch:

• Completely built using Java 11 for maximum backwards compatibility.
• All unit tests pass (except for one small one that I had to remove due to reflection behavior changes in JDK 1.8+.
• TestNG has been completely removed and replaced with JUnit4. All tests have been converted.
• The Bugzooky examples application works now after making several legacy (pre-1.5) fixes.
• The Canoo webtests actually fully pass now (configured with Tomcat 10). Tomcat 11.x cannot be used because it requires Java 17.
• This uses Servlet 6.0 and the latest Jakarta JSTL/Servlet APIs.
• Spring has been updated to the latest 5.3.29. Spring 6.x cannot be used for now because it requires Java 17. That might be another future parallel branch.
• Commons-fileupload has been moved to commons-fileupload2.
• All other library dependencies have been updated to their latest possible versions.

Now, for some potentially breaking changes things that I took the liberty to do for security considerations:

1. The Log4JLogger has been completely removed. After the log4shell exploit, I decided to remove it and let Stripes consumers implement their own Log4j logger at their own risk. The default logger is now the SimpleJdk14Logger.
2. The O'Reilly COS library and CosMultipartWrapper has been completely removed as a dependency (and from the code). It is replaced with the Apache commons-fileupload2 implementation. In the future, I may contribute a pure-Java Servlet 3.1 multipart wrapper which I have implemented and I know works.

Why The 1.6.0 Branch And Not Master?

I know this question will be in people's minds. And the answer is because, right now, I do not have a good level of comfort for what is in the master branch. I am not saying that what is there is not good, but I need to take a complete inventory of all of those commits. While there are some good things/fixes in master, I also know that there are things in there which don't make sense (some that I even wrote/contributed) which people have commented on, some poorly chosen dependencies, among other things. I will probably go commit-by-commit in a new branch, pulling in fixes, and potentially some enhancements. But I'll probably have to do that in a new branch. The new 1.7.0 (or maybe even 2.0) branch.

How Can You Help?

Please feel free to pull/build the 1.6.0-Jakarta branch. Build and test it in your own environments. I have personally tested it on Payara 6 and Tomcat 10 (not to mention that the Canoo webtests also pass on Tomcat 10.x). If you see any issues, please report them and I will try to get them fixed. One area that I would like people to try out is the SpringHelper/Injection. The tests pass for it, but I personally did not test this on a running/working application.

Where Will It Go From Here?

Next on my list will be to probably create a new Stripes 2.0 branch which will feature a build on Java17 (GraalVM). Along with that will be an upgrade to Spring 6.x and webtests targeting Tomcat 11.x. After that, I will look at pulling stable well-tested/sensible fixes/enhancements from master into the Stripes 2.0 branch. But I am 100% sure that some of what is in the master branch will be removed because it is too old, irrelevant, or unstable.

Please Comment!

If you read this and are still around, please make yourself known. If you are doing testing and have some success, please put some feedback here. I'm not expecting Stripes to replace Jakarta MVC in JEE10. I certainly don't expect it to replace Spring Boot. But I know it is used in many legacy applications that are still running around the world. At the very least, I hope this Jakarta release of Stripes 1.6.0 can serve you well and will give your projects/software some peace of mind and allow you to migrate onto the latest JakartaEE stack.

Best Regards,

Rick

What's Changed

• • Initial Jakarta EE 10 Conversion on Java 11. by @rgrashel in * Initial Jakarta EE 10 Conversion on Java 11. #104

Full Changelog: 1.6.0...1.6.0-Jakarta-beta

---

This discussion was created from the release 1.6.0-Jakarta.

[blackflame7000]

Hey, this is fantastic news and very convenient timing for me as I’m having to upgrade a project that uses stripes for tomcat10 that requires Jakarta. Much appreciated, and know that your efforts will be used.

[ojaha065]

I second what the commenter above said. We're currently migrating away from Stripes but still have some legacy stuff depending on it. As we need to update to Tomcat 10 soon, we were planning to create a custom fork but now that seems unnecessary. Very much appreciated

We'll begin testing and will report back if we encounter any notable issues. Do you think you will be able to make this release available on Maven soon?

[simonKimathi]

Im in the same situation too.

[scarywombat]

Just about to upgrade a project from Centos6 to RHEL9. They want (for some unknown reason) to use the latest java and latest tomcat. I guess that based upon this release I will Java 11.

[ojaha065]

Just about to upgrade a project from Centos6 to RHEL9. They want (for some unknown reason) to use the latest java and latest tomcat. I guess that based upon this release I will Java 11.

We've been using this in prod with Java 17 and have been testing with Java 21 (the latest LTS) without encountering any issues

[hvyas27]

I've been using the Stripes Framework for a long time, ever since Tim Fennell's initial release. I appreciate Rick Grashel's efforts to revive this project. I only found out about the new version when I stumbled upon the project on GitHub while searching for something else. I'm part of the old user group ([email protected]) and haven't received any notification about this update. We should update the website and notify the community about this new release. I'm willing to donate to support hosting the website for the community.

[isaclutz]

We are in the same situation, where we need to update an application to the jakarta package namespace in order to patch some security holes with some other frameworks, but we have a fair amount of legacy code that is still using Stripes. We are having a bit of difficulty with the migration.

When we have a page-hierarchy (using <s:layout-render />) the <s:layout-component /> elements in the middle page are never evaluated. In the debugger, we can see that the tags are called with "context.isComponentRenderPhase() => false" but never with "context.isComponentRenderPhase() => true"

Everything worked correctly using stripes 1.5.7, but I am experiencing this identical behavior in the 1.6.0-Jakarta version here as well in a 1.5.7 version which I have ported myself (bare-bones, ignore all tests, etc...) Has anyone else seen this behavior?

Here is a sample:
Login.jsp

<%@ include file="/WEB-INF/jsp-commons/taglibs-and-encoding/Taglib.jsp" %>
<s:layout-render name="/WEB-INF/jsp-layouts/page-with-base-layout.jsp">
	<s:layout-component name="content">
		This is my content
	</s:layout-component>
</s:layout-render>

page-with-base-layout.jsp

<%@ include file="/WEB-INF/jsp-commons/taglibs-and-encoding/Taglib.jsp" %>
<s:layout-definition>
	<s:layout-render name="/WEB-INF/jsp-layouts/page-with-empty-body.jsp" disablePageWrapper="${disablePageWrapper}">
		<s:layout-component name="body">
			${content}
		</s:layout-component>
	</s:layout-render>
</s:layout-definition>

page-with-empty-body.jsp

<%@ taglib prefix="s" uri="http://stripes.sourceforge.net/stripes.tld" %>
<s:layout-definition>
<html lang="en">
    <body>
        Content: ${content}
        <br />
        Body: ${body}
    </body>
</html>
</s:layout-definition>

This renders the following HTML

<html lang="en">
    <body>
        Content: 
		This is my content
	
        <br />
        Body: 
    </body>
</html>

I've also attached a minimal maven project with 3 WAR modules,
stripes-problem.zip

http://localhost:8080/tomcat9-stripes-1.5.7/stripes/Broken.action (Actually, this works OK)
http://localhost:8080/tomcat9-stripes-1.5.7/stripes/OK.action

http://localhost:8080/tomcat11-stripes-1.5.7/stripes/Broken.action
http://localhost:8080/tomcat11-stripes-1.5.7/stripes/OK.action

http://localhost:8080/tomcat11-stripes-1.6.0/stripes/Broken.action
http://localhost:8080/tomcat11-stripes-1.6.0/stripes/OK.action

[isaclutz]

After a bit more debugging and experimentation, I believe the problem is a couple "javax" constants.

In StripesConstants.java I changed the following values:

String REQ_ATTR_INCLUDE_PATH = jakarta.servlet.RequestDispatcher.INCLUDE_SERVLET_PATH;
String REQ_ATTR_INCLUDE_PATH_INFO = RequestDispatcher.INCLUDE_PATH_INFO;

In DefaultMultipartWrapperFactory
File tempDir = (File) config.getServletContext().getAttribute(ServletContext.TEMPDIR);

[rgrashel]

Hi all!

Good news! I have been able to work with Sonatype to get identity validation completed in order to publish to Maven Central. I did need to register a new namespace (it will be io.github.stripesframework). However, I now have the ability to publish. I will take a few days to modify the assemblies to publish using the updated namespace and then give it a try. I'll let you guys know the moment things look like they are working.

Thanks!

-- Rick

[jringbox]

I'm a bit stuck. When I use this new library with my code I get Could not instantiate specified Configuration. Class name specified was [net.sourceforge.stripes.config.RuntimeConfiguration]. net.sourceforge.stripes.exception.StripesRuntimeException: Problem instantiating default configuration objects. which is caused by this error.

Caused by: net.sourceforge.stripes.exception.StripesRuntimeException: Could not find class [net.sourceforge.stripes.integration.spring.SpringInterceptor] specified by the configuration parameter [Interceptor.Classes]. This value must contain fully qualified class names separated  by commas.
	at net.sourceforge.stripes.config.BootstrapPropertyResolver.getClassPropertyList(BootstrapPropertyResolver.java:207)
	at net.sourceforge.stripes.config.BootstrapPropertyResolver.getClassPropertyList(BootstrapPropertyResolver.java:250)
	at net.sourceforge.stripes.config.RuntimeConfiguration.initInterceptors(RuntimeConfiguration.java:223)
	at net.sourceforge.stripes.config.DefaultConfiguration.init(DefaultConfiguration.java:217)

Any ideas?

[jringbox]

I just took the original SpringInterceptor and made my own implementation of it. I suppose that's the "go forward"?

[rgrashel]

Hi there! I don't think you should have to do this. You should be able to add this to your web.xml: <init-param> <param-name>Extension.Packages</param-name> <param-value>net.sourceforge.stripes.integration.spring</param-value> </init-param> This comes from this: https://stackoverflow.com/questions/32223323/stripes-1-6-missing-springinterceptor The interceptor approach for Spring injection was abandoned in favor of a post processor in Stripes 1.6. So I think this should "just work" if you use the above integration and then use @SpringBean. Thanks.

…

On Tue, Aug 19, 2025 at 3:05 PM jringbox ***@***.***> wrote: I just took the original SpringInterceptor and made my own implementation of it. I suppose that's the "go forward"? — Reply to this email directly, view it on GitHub <#107 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABF7QH3MQD4GACCT6IGXBAL3ON7QDAVCNFSM6AAAAAB37RHM2WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJVGY2DSMQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>