Hi, Tomcat 10.0.0 was released 2020-12-08. Now almost five years later we should finally release the Jakarta migration as 3.0. So users can move on to Tomcat 10.1.46 or JBoss EAP 8. Tomcat have released 73 fix versions since 10.0.0. Removing Security Manager stuff is a big change, way bigger than Jakarta which basically was a trivial change. Still JSPWIKI-1170 took over three years. Let's not wait again. Let's get out 3.0 now and do all further changes for 3.1.
Cheers, Juergen Am Fr., 3. Okt. 2025 um 21:16 Uhr schrieb Juan Pablo Santos Rodríguez <[email protected]>: > > Hi! > > just to clarify, there are two topics here: > > 1.- Deleting a method from a class in jspwiki-api: given that, by > [#1], changes in there are reserved for major versions, and the > proposed deletion is hardly used and, as a fact, needs to be removed > in the future b/c affected classes will not exist in the JDK, my > proposal is to delete that method now. AIUI, this would hardly give a > headache to anyone. > > 2.- Security Manager stuff: talking about first point, why not go and > remove ALL the security manager related code for 3.0.0. That would > make it JDK-25 compatible. JSPWiki security is indeed built around the > Security Manager (f.ex the policy files), but not around all the > classes that are going away. JSPWiki relies on a global policy (1), if > set, through the SM, and if not present defaults to the local policy > (2). Reading the code, seems that this second part is still supported > in JDK-25. I suspect that very few people are using the global > security manager, while the rest delegate on the local policies, so > that ought to be another not-so-annoying breaking change, which > affects a small minority. I want to make a quick test of removing the > deprecated code and seeing how JSPWiki security behaves. If it still > works as expected, keep that, if not, it would be a major PITA, > requiring much more attention, and would not be on scope for 3.0.0. > > Also, we have a long outstanding, > https://issues.apache.org/jira/browse/JSPWIKI-129 which was logged to > make JSPWiki run under a Security Manager, meaning that "an effective > policy cannot be written". > > Anyway, I'll dig a bit and see where do I get (anyone with a bit of > spare time to also look at this would be very welcome O:-)). > > cheers, > juan pablo > > [#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=VersioningProposal > > On Wed, Oct 1, 2025 at 2:22 PM Alex O'Ree <[email protected]> wrote: > > > > My complaint is that jspwiki reads in and parses the web.xml file at bootup > > to get the security roles. Anything not listed is ignored. This could be a > > bit more dynamic. Servlet request.isUserInRole is all we really need > > instead of all the caching and middlewear code in the middle. Makes it hard > > for users backed by ldap to quickly and easily add new roles, especially in > > a docker container > > > > On Wed, Oct 1, 2025, 7:32 AM Arturo Bernal <[email protected]> wrote: > > > > > I think JSPWiki’s security is JAAS/container-managed with our > > > Permission/ACL layer; it isn’t built on the JDK SecurityManager. The only > > > SM-adjacent touchpoint is the deprecated Session#doPrivileged(...) > > > wrapper—barely used and not on the auth/ACL path—so 3.0.0 is the right > > > time > > > to drop it and document. > > > > > > Arturo > > > > > > > > > On Wed, Oct 1, 2025 at 12:02 PM Jürgen Weber <[email protected]> wrote: > > > > > > > I believe the jspwiki Security is built around the SecurityManager, > > > > isn't > > > > it? > > > > Removing the dependency is better for 3.1 > > > > > > > > Arturo Bernal <[email protected]> schrieb am Mi., 1. Okt. 2025, 11:37: > > > > > > > > > Hi All, > > > > > > > > > > +1 (binding). 3.0.0 is the right line in the sand: remove the Security > > > > > Manager–dependent API and other long-deprecated code, finish the > > > > > javax→Jakarta cleanup, and baseline JDK 17 > > > > > > > > > > cheers, > > > > > Arturo > > > > > > > > > > > > > > > Arturo > > > > > > > > > > > > > > > On Tue, Sep 30, 2025 at 8:52 PM Juan Pablo Santos Rodríguez < > > > > > [email protected]> wrote: > > > > > > > > > > > Hi! > > > > > > > > > > > > While going through the code I've noticed that jspwiki-api not only > > > > > > contained a method relying on javax, thus implying a major version), > > > > > > but there's also a method [#1] which uses classes from the Security > > > > > > Manager, marked Deprecated and for removal at a latter version (done > > > > > > in JDK-24, IIRC). This method is barely used throughout the code, > > > > > > and > > > > > > I suspect is less used on third party extensions. > > > > > > > > > > > > As such, I'd like to remove it from the jspwiki-api module, so we > > > > > > avoid a breaking change in a future release, and also remove the > > > > > > rest > > > > > > of the related deprecated code throughout the code base. > > > > > > > > > > > > This way JSPWiki should be able to run using JDK 17 to 25. Thoughts? > > > > > > > > > > > > > > > > > > cheers, > > > > > > juan pablo > > > > > > > > > > > > [#1]: > > > > > > > > > > > > > > > > > > https://github.com/apache/jspwiki/blob/master/jspwiki-api/src/main/java/org/apache/wiki/api/core/Session.java#L240-L252 > > > > > > > > > > > > > > > > > >
