+1, strongly agree. It's a big version change, time to not worry too
much about backwards compatibility. I'd guess more people would be
interested in a major upgrade (in functionality, security, compatibility
with current tech) than would be worried about backwards compatibility.
I don't have any sense of how many users are actually using custom
plugins, but I'd think for many (if not most) they'd simply copy their
wiki page directory over to the new version and they'd be good to go.
I do like the idea of abandoning what is now effectively a bespoke
security solution and going with what's compatible with JDK-25. In 2025
I think that better integrating with contemporary work environments is
a big win.
M.
On 4/10/25 08:48, Jürgen Weber wrote:
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
--
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
