Re: 2.12.2 release?

[Juan Pablo Santos Rodríguez]

Hi!

this weekend I pushed some commits to master regarding JSPWIKI-1186
and some ci stuff, so from my side 2.12.2 should be ready to go? Does
anyone want to volunteer to act as release manager for 2.12.2? If
none, I'll begin with it in a couple or days or so-

cheers,
juan pablo

On Mon, May 13, 2024 at 4:36 PM Arturo Bernal  wrote:
>
> Hi Juan Pablo,
>
> I agree that we should proceed with the release of 2.12.2 as soon as
> possible, especially to address the security issue that has already been
> fixed on the master branch. Ensuring that JSPWiki-1186 is resolved is
> important to avoid any negative first impressions from new users.
>
> I need to address the commit related to the virtual threat, but I'll
> prioritize the release and the security fixes.
>
> Best regards,
>
>
> Arturo
>
>
> On Thu, May 9, 2024 at 11:30 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi,
> >
> > we've been some months with a security issue fixed on master, but
> > unreleased, so I was wondering when to release 2.12.2, the soonish the
> > better. Right now I'd only want to look at JSPWIKI-1186, as it is
> > related to the installer and having an issue there would leave a bad
> > impression for first-timers trying JSPWiki. Other than that I think
> > 2.12.2 should be ready to go, but I was wondering if anyone else wants
> > to push something else more into 2.12.2.
> >
> > Thoughts?
> >
> > br,
> > jp
> >

2.12.2 release?

[Juan Pablo Santos Rodríguez]

Hi,

we've been some months with a security issue fixed on master, but
unreleased, so I was wondering when to release 2.12.2, the soonish the
better. Right now I'd only want to look at JSPWIKI-1186, as it is
related to the installer and having an issue there would leave a bad
impression for first-timers trying JSPWiki. Other than that I think
2.12.2 should be ready to go, but I was wondering if anyone else wants
to push something else more into 2.12.2.

Thoughts?

br,
jp

Re: [DRAFT] 2024/04 Board report

[Juan Pablo Santos Rodríguez]

fixed (and sent), thanks!

On Tue, Apr 9, 2024 at 10:13 PM Dirk Frederickx
 wrote:
>
> +1
> (small typo :  double entry of the word "detected"
>
> dirk
>
> On Tue, Apr 9, 2024 at 7:30 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi,
> >
> > as usual, this quarter's draft of the Board report. It should be sent
> > by tomorrow, so apologies on the rush. Still, any correction, comment,
> > edit, etc. is more than welcome
> >
> > cheers,
> > juan pablo
> >
> > +## Description:
> > +The mission of JSPWiki is the creation and maintenance of software
> > related to
> > +Leading open source WikiWiki engine, feature-rich and built around
> > standard
> > +JEE components (Java, servlets, JSP).
> > +
> > +## Project Status:
> > +Current project status: Ongoing, with low activity.
> > +Issues for the board: There are no issues requiring board attention.
> > +
> > +## Membership Data:
> > +Apache JSPWiki was founded 2013-07-17 (10 years ago)
> > +There are currently 15 committers and 9 PMC members in this project.
> > +The Committer-to-PMC ratio is 5:3.
> > +
> > +Community changes, past quarter:
> > +- Arturo Bernal was added to the PMC on 2023-06-21
> > +- Arturo Bernal was added as committer on 2023-06-21
> > +
> > +## Project Activity:
> > +Except from the last weeks, it has been a quiet quarter, with almost no
> > +activity:
> > +
> > +* There's being some work on the refactor, referenced on last report, to
> > +benefit from virtual threads under JDK-21, but it is not complete yet.
> > +* A small bug detected detected while our public wiki being attacked was
> > +fixed.
> > +* We've began to publish SBOMs alongside our main artifacts.
> > +* Some dependencies and plugins have been upgraded.
> > +
> > +We still have to release 2.12.2, and then publish a CVE already fixed on
> > +master, which should be done this quarter.
> > +
> > +## Community Health:
> > +Work on latest master shows commits from 1 commiter, done on the same git
> > push.
> > +
> > +As noted above, on Eastern Week we were target of an automated attack,
> > which
> > +tried to explote vulnerabilities inside JSPWiki, through every single form
> > +available. Thankfully, all the attack vectors were covered on previous
> > +vulnerability reports, so nothing serious did happen, other than wiki
> > +defacement which was manually fixed.
> > +
> > +As a result of this, we've documented on our SVN private area the setup of
> > +the VM that hosts our public wiki, so any PMC can know how to operate it;
> > +we're also temporarily not allowing new accounts on our public wiki, until
> > +we put manual approval of accounts, and we've asked for volunteers to help
> > +mantaining our public wiki content, having received one request off-list
> > to
> > +it.
> > +
> > +One new user appeared on our user ML, has opened several JIRA issues and
> > has
> > +provided a PR for one of them, which should be reviewed and hopefully
> > merged
> > +sooner than later.
> > +
> > +No questions unanswered on MLs, although they've had very little traffic.
> > \ No newline at end of file
> >

[DRAFT] 2024/04 Board report

[Juan Pablo Santos Rodríguez]

Hi,

as usual, this quarter's draft of the Board report. It should be sent
by tomorrow, so apologies on the rush. Still, any correction, comment,
edit, etc. is more than welcome

cheers,
juan pablo

+## Description:
+The mission of JSPWiki is the creation and maintenance of software related to
+Leading open source WikiWiki engine, feature-rich and built around standard
+JEE components (Java, servlets, JSP).
+
+## Project Status:
+Current project status: Ongoing, with low activity.
+Issues for the board: There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (10 years ago)
+There are currently 15 committers and 9 PMC members in this project.
+The Committer-to-PMC ratio is 5:3.
+
+Community changes, past quarter:
+- Arturo Bernal was added to the PMC on 2023-06-21
+- Arturo Bernal was added as committer on 2023-06-21
+
+## Project Activity:
+Except from the last weeks, it has been a quiet quarter, with almost no
+activity:
+
+* There's being some work on the refactor, referenced on last report, to
+benefit from virtual threads under JDK-21, but it is not complete yet.
+* A small bug detected detected while our public wiki being attacked was
+fixed.
+* We've began to publish SBOMs alongside our main artifacts.
+* Some dependencies and plugins have been upgraded.
+
+We still have to release 2.12.2, and then publish a CVE already fixed on
+master, which should be done this quarter.
+
+## Community Health:
+Work on latest master shows commits from 1 commiter, done on the same git push.
+
+As noted above, on Eastern Week we were target of an automated attack, which
+tried to explote vulnerabilities inside JSPWiki, through every single form
+available. Thankfully, all the attack vectors were covered on previous
+vulnerability reports, so nothing serious did happen, other than wiki
+defacement which was manually fixed.
+
+As a result of this, we've documented on our SVN private area the setup of
+the VM that hosts our public wiki, so any PMC can know how to operate it;
+we're also temporarily not allowing new accounts on our public wiki, until
+we put manual approval of accounts, and we've asked for volunteers to help
+mantaining our public wiki content, having received one request off-list to
+it.
+
+One new user appeared on our user ML, has opened several JIRA issues and has
+provided a PR for one of them, which should be reviewed and hopefully merged
+sooner than later.
+
+No questions unanswered on MLs, although they've had very little traffic.
\ No newline at end of file

[DRAFT] Board 2024/01 report

[Juan Pablo Santos Rodríguez]

Hi, and happy new year everyone!

please see inlined draft below for upcoming Board meeting. IIRC, the
report is due to next Wednesday, so any comments, edits, etc., are
more than welcome!


best regards,
juan pablo

-- Forwarded message -
From: 
Date: Sun, Jan 7, 2024 at 5:08 PM
Subject: (jspwiki-asf-docs) branch master updated: DRAFT Board 2024/01 report
To: comm...@jspwiki.apache.org 


This is an automated email from the ASF dual-hosted git repository.

juanpablo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/jspwiki-asf-docs.git


The following commit(s) were added to refs/heads/master by this push:
 new 6b87737  DRAFT Board 2024/01 report
6b87737 is described below

commit 6b87737a9a70486d442781b198779845b903abd2
Author: Juan Pablo Santos Rodríguez 
AuthorDate: Sun Jan 7 17:06:25 2024 +0100

DRAFT Board 2024/01 report
---
 board-reports/2024-01.txt | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/board-reports/2024-01.txt b/board-reports/2024-01.txt
new file mode 100755
index 000..02f637a
--- /dev/null
+++ b/board-reports/2024-01.txt
@@ -0,0 +1,38 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related to
+Leading open source WikiWiki engine, feature-rich and built around standard
+JEE components (Java, servlets, JSP).
+
+## Project Status:
+Current project status: Ongoing, with low activity.
+Issues for the board: There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (10 years ago)
+There are currently 15 committers and 9 PMC members in this project.
+The Committer-to-PMC ratio is 5:3.
+
+Community changes, past quarter:
+- Arturo Bernal was added to the PMC on 2023-06-21
+- Arturo Bernal was added as committer on 2023-06-21
+
+## Project Activity:
+We received two vulnerability reports this quarter, of which one of them
+resulted in an actual vulnerability, already fixed in master.
+
+As a result from a thread on the user ML, we also have introduced support
+of custom wiki event listeners on our public API, and squashed a bug
+regarding the content of some wiki events.
+
+We still have to release 2.12.2, but we'd like to introduce in it a big
+internal refactor so that JSPWiki can benefit from virtual threads support
+when running under JDK-21. This work is tracked at [#1].
+
+## Community Health:
+Work on latest master shows commits from 2 different commiters.
+
+Other than that, we got the usual amount of emails (that is, not too much). No
+unanswered questions, and there is enough people appearing on the ML and
+providing project oversight.
+
+[#1]: https://github.com/apache/jspwiki/pull/307
\ No newline at end of file

Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. [jspwiki]

[Juan Pablo Santos Rodríguez]

Hi Murray,

I agree, listeners should only appear on startup, if they appear later on
then there's something wrong.

It occurs to me that, in this case, perhaps replacing the listener list
with a CopyOnWriteArrayList would be enough to tackle all the synchronized
code (and the need to wrap it around Synchronizer on the PR). There are
only about 30 listeners, give or take, and they get instantiated/added on
startup, so CopyOnWriteArrayList makes sense to me in this case.

WDYT? Would you mind sending a PR with that?


cheers,
juan pablo


El sáb, 2 dic 2023, 23:53, Murray Altheim  escribió:

> Hi Juan Pablo,
>
> It's been many years since I wrote that event manager and I assume there've
> been many edits since, but it occurs to me that the vast majority of
> changes
> are made to the engine when the wiki engine is first started up. Isn't that
> the case? I guess there's also the possibility of instances of listeners
> popping up from its use on page-based plugins. Hmm.
>
> In any case, I would think that we consider what the purposes of the locks
> are for in the first case. Since the manager is a singleton, used by the
> whole wiki engine, we'd not want it to be having its set of listeners
> modified
> while in the middle of processing an event. So I would tend to agree with
> you that at least for 'm_listenerList' a single lock is best. On the other
> hand, another approach would be to modify the event manager to be able to
> simply ignore the issue, i.e., if an event comes through for a listener
> that
> is in the process of being added, I'm not sure what the harm is in ignoring
> that. The chance of that event being tied to the new listener seems rather
> remote. Dunno. We'd just need to avoid ConcurrentModificationExceptions.
>
> [I'm somewhat embarrassed to see that at that time (about 20 years ago) I
> had gotten into the habit of using Hungarian Notation in my code. I suppose
> when I was doing all my coding in vi it made more sense. Now it just looks
> weird to me.]
>
> Cheers,
>
> Murray
>
> On 3/12/23 11:24, juanpablo-santos (via GitHub) wrote:
> >
> > juanpablo-santos commented on code in PR #307:
> > URL: https://github.com/apache/jspwiki/pull/307#discussion_r1412879450
> >
> >
> > ##
> > jspwiki-event/src/main/java/org/apache/wiki/event/WikiEventManager.java:
> > ##
> > @@ -406,15 +429,15 @@ public Set< WikiEventListener >
> getWikiEventListeners() {
> >* @return true if the listener was added (i.e., it was not
> already in the list and was added)
> >*/
> >   public boolean addWikiEventListener( final WikiEventListener
> listener ) {
> > -synchronized( m_listenerList ) {
> > +return Synchronizer.synchronize(wikiEventListenerLock, ()
> -> {
> >
> > Review Comment:
> > shouldn't `m_listener` reuse the same `Lock` through the entire
> class? Different locks on different operations would imply they could
> execute operations on `m_listenerList` at the same time
> >
> >
> >
> > ##
> >
> jspwiki-main/src/main/java/org/apache/wiki/auth/authorize/DefaultGroupManager.java:
> > ##
> > @@ -367,14 +395,18 @@ protected String[] extractMembers( final String
> memberLine ) {
> >
> >   /** {@inheritDoc} */
> >   @Override
> > -public synchronized void addWikiEventListener( final
> WikiEventListener listener ) {
> > -WikiEventManager.addWikiEventListener( this, listener );
> > +public void addWikiEventListener( final WikiEventListener listener
> ) {
> >
> > Review Comment:
> > should use the same lock as `removeWikiEventListener`
> >
> >
> >
> > ##
> > jspwiki-main/src/main/java/org/apache/wiki/WatchDog.java:
> > ##
> > @@ -136,26 +154,26 @@ private static void scrub() {
> >*  Can be used to enable the WatchDog.  Will cause a new Thread
> to be created, if none was existing previously.
> >*/
> >   public void enable() {
> > -synchronized( WatchDog.class ) {
> > +Synchronizer.synchronize(enableLock, () -> {
> >
> > Review Comment:
> > same as before, same synchronized object should reuse the same Lock
> throughout the class.
> >
> >
> >
> > ##
> >
> jspwiki-main/src/main/java/org/apache/wiki/auth/authorize/DefaultGroupManager.java:
> > ##
> > @@ -152,13 +180,13 @@ public void initialize( final Engine engine, final
> Properties props ) throws Wik
> >
> >   // Load all groups from the database into the cache
> >   final Group[] groups = m_groupDatabase.groups();
> > -synchronized( m_groups ) {
> >
> > Review Comment:
> > converting `m_groups` to `ConcurrentHashMap` would avoid the use of
> `Synchronizer`
> >
> >
> >
> > ##
> > jspwiki-event/src/main/java/org/apache/wiki/event/WikiEventManager.java:
> > ##
> > @@ -314,35 +337,35 @@ private Map< Object, WikiEventDelegate >
> getDelegates() {
> >* @param client   the client Object, or alternately a Class
> reference
> >   

Re: Proposal to Implement New GitHub Actions Workflows for CI/CD

[Juan Pablo Santos Rodríguez]

Hi Arturo!

My 2c,

I'm ok with the change, with a caveat:

If we switch to GH actions, let's ditch the Jenkins build entirely, in
order to not have two different build/ci systems. This implies a number of
things

- SQ analysis should be done from one of the pipelines, perhaps the codeql
one? So it would have to be renamed to qa.yaml or something like that

- Also, currently, if the ci build is successful and we have a SNAPSHOT
version, we automatically deploy to repository.a.o, one of the pipelines
should also take care of that, not sure which.

- Last, a successful build also triggers the build on charge of deploying
the static site and associated assets (javadocs, japicmp reports). IIRC,
infra provides support for these actions when working with either Jenkins
or GH actions, but don't have any pointer on how to do it on the latter.

Of course we can keep the Jenkins build until all of these steps are
completed, but always having the final picture in mind (i.e., one build/ci
system).

Said that a couple questions/wishes on the GH actions builds:

1) what kind of errors display the windows builds? I suspect that most
probably there's a problem with the test execution order (at least that's
what happened in other similar situations). Could we get a lot of any of
those builds?

2) would it be possible to also run the integration tests? They can be run
on headless mode, so we'd only need an additional chrome binary on the
build path. Don't know if it's possible though.


Thx + best regards,
juan pablo

El jue, 19 oct 2023, 22:08, Arturo Bernal  escribió:

> Dear Team,
>
> I'd like to propose the addition of three new GitHub Actions workflows to
> enhance our CI/CD pipeline for the Apache JSPWiki project. Below are the
> details:
>
>1.
>
>*Java CI Workflow*: Provides continuous integration support across
>multiple OS (Ubuntu, macOS) and Java versions (11, 17). It also caches
>Maven dependencies for optimized build times.
>2.
>
>*Dependency Review Workflow*: Triggered on pull requests to review and
>ensure that dependencies are safe.
>3.
>
>*CodeQL Workflow*: Provides continuous integration and code quality
>checks.
>
> These workflows are designed to automate and streamline our development
> process, making it more efficient. They will run on every push to the
> master branch and on every pull request, ensuring that our code is
> continuously tested and dependencies are reviewed.
>
> I've already created a pull request with these changes, which you can
> review here .
>
> Here are the key files to be added:
>
>- CodeQL (codeql.yml) for continuous integration and code quality
> checks.
>- Dependency Review (dependency-review.yml) for dependency checks.
>- Java CI (maven.yml) for continuous integration across multiple OS and
>Java versions.
>
> I'd appreciate your thoughts and feedback on this proposal. Are there any
> concerns or suggestions you'd like to share?
>
> Best regards,
> Arturo
>

Re: Failing CI builds (was: Re: [PR] JSPWIKI-925 - Add Missing i18n Literals for Multiple Languages [jspwiki])

[Juan Pablo Santos Rodríguez]

Hi,

Do you have the failing build at hand? Last build on master [#1] shows it
finished ok, whereas the invalid file causing the issue [#2] looks ok on
Nexus.

If the issue is happening on your machine, perhaps that file is malformed
on your .m2? In that case, deleting it there should be enough to fix the
issue.


Best regards,
juan pablo


[#1]
https://ci-builds.apache.org/job/JSPWiki/job/ci/job/master/lastSuccessfulBuild/
[#2]
https://repository.apache.org/content/repositories/snapshots/org/apache/jspwiki/wikipages/jspwiki-wikipages-en/maven-metadata.xml

El mié, 18 oct 2023, 23:08, Arturo Bernal  escribió:

> Hi JP, I just checked, and it seems the issue is still occurring.
>
> Could you please advise on what I might be doing wrong or what I should be
> looking for?"
>
> Kind regards
>
> Arturo
>
>
> On Sat, Oct 14, 2023 at 6:57 PM Arturo Bernal  wrote:
>
> > Tank you JP
> >
> > Arturo
> >
> >
> > On Sat, Oct 14, 2023 at 3:47 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> Issue is fixed now, associated Jira had been resolved.
> >>
> >>
> >> Cheers,
> >> juan pablo
> >>
> >> El mié, 11 oct 2023, 10:31, Juan Pablo Santos Rodríguez <
> >> juanpablo.san...@gmail.com> escribió:
> >>
> >> > Hi,
> >> >
> >> > yup, noticed a couple of days ago, seems a malformed maven metadata
> >> > file has been
> >> > uploaded to the snapshots repository, making impossible to deploy a
> >> > specific module. As
> >> > our ci build automatically deploys snapshots, we're stucked there.
> >> >
> >> > Contacted infra a couple of days back about this [#1], but no answers
> >> > yet; also opened
> >> > a jira ticket today ([#2]) to track this.
> >> >
> >> >
> >> > best regards,
> >> > juan pablo
> >> >
> >> > [#1] https://lists.apache.org/thread/7w1gmzcr2xhgttssl0s83pv80h1szql8
> >> > (needs asf login)
> >> > [#2] https://issues.apache.org/jira/browse/INFRA-25078 (needs asf
> >> login)
> >> >
> >> > On Wed, Oct 11, 2023 at 1:36 AM Murray Altheim 
> >> > wrote:
> >> > >
> >> > > To be clear, in XML, comments are permitted in the XML Prolog
> >> (Production
> >> > > 22 in the XML spec) and the doctypedecl (Production 28), but I think
> >> the
> >> > > POM parser barfs on them.
> >> > >
> >> > > On 11/10/23 12:24, Murray Altheim wrote:
> >> > > > Hi Arturo,
> >> > > >
> >> > > > Does there happen to be an XML comment between the 
> >> declaration
> >> > > > and the  start tag? That's what the error message
> suggests.
> >> > > >
> >> > > > Cheers,
> >> > > >
> >> > > > Murray
> >> > > >
> >> > > > On 11/10/23 05:44, arturobernalg (via GitHub) wrote:
> >> > > >>
> >> > > >> arturobernalg commented on PR #312:
> >> > > >> URL:
> >> > https://github.com/apache/jspwiki/pull/312#issuecomment-1755833207
> >> > > >>
> >> > > >> @juanpablo-santos
> >> > > >> I'm encountering the following error while when the CI is
> >> running:
> >> > > >> ```[ERROR] Failed to execute goal
> >> > org.apache.maven.plugins:maven-deploy-plugin:3.1.1:deploy
> >> (default-deploy)
> >> > on project jspwiki-wikipages-en: Failed to update metadata
> >> > > >>
> >> org.apache.jspwiki.wikipages:jspwiki-wikipages-en/maven-metadata.xml:
> >> > Could not parse metadata
> >> >
> >>
> /home/jenkins/.m2/repository/org/apache/jspwiki/wikipages/jspwiki-wikipages-en/maven-metadata-apache.snapshots.https.xml:
> >> > in epilog non
> >> > > >> whitespace content is not allowed but got t (position: END_TAG
> seen
> >> > ...\nt... @12:2) -> [Help 1]
> >> > > >> ```
> >> > > >> This isn't the first time I've encountered this issue; I
> faced
> >> > the same error in another PR as well. Do you have any insights into
> what
> >> > might be causing it?"
> >> > >
> >> > >
> >> >
> >>
> ...
> >> > > Murray Altheim 
>  = =
> >> > ===
> >> > > 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
> >> > >
> >> >
> >>
> >
>

Re: Failing CI builds (was: Re: [PR] JSPWIKI-925 - Add Missing i18n Literals for Multiple Languages [jspwiki])

[Juan Pablo Santos Rodríguez]

Hi,

Issue is fixed now, associated Jira had been resolved.


Cheers,
juan pablo

El mié, 11 oct 2023, 10:31, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> escribió:

> Hi,
>
> yup, noticed a couple of days ago, seems a malformed maven metadata
> file has been
> uploaded to the snapshots repository, making impossible to deploy a
> specific module. As
> our ci build automatically deploys snapshots, we're stucked there.
>
> Contacted infra a couple of days back about this [#1], but no answers
> yet; also opened
> a jira ticket today ([#2]) to track this.
>
>
> best regards,
> juan pablo
>
> [#1] https://lists.apache.org/thread/7w1gmzcr2xhgttssl0s83pv80h1szql8
> (needs asf login)
> [#2] https://issues.apache.org/jira/browse/INFRA-25078 (needs asf login)
>
> On Wed, Oct 11, 2023 at 1:36 AM Murray Altheim 
> wrote:
> >
> > To be clear, in XML, comments are permitted in the XML Prolog (Production
> > 22 in the XML spec) and the doctypedecl (Production 28), but I think the
> > POM parser barfs on them.
> >
> > On 11/10/23 12:24, Murray Altheim wrote:
> > > Hi Arturo,
> > >
> > > Does there happen to be an XML comment between the  declaration
> > > and the  start tag? That's what the error message suggests.
> > >
> > > Cheers,
> > >
> > > Murray
> > >
> > > On 11/10/23 05:44, arturobernalg (via GitHub) wrote:
> > >>
> > >> arturobernalg commented on PR #312:
> > >> URL:
> https://github.com/apache/jspwiki/pull/312#issuecomment-1755833207
> > >>
> > >> @juanpablo-santos
> > >> I'm encountering the following error while when the CI is running:
> > >> ```[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:3.1.1:deploy (default-deploy)
> on project jspwiki-wikipages-en: Failed to update metadata
> > >> org.apache.jspwiki.wikipages:jspwiki-wikipages-en/maven-metadata.xml:
> Could not parse metadata
> /home/jenkins/.m2/repository/org/apache/jspwiki/wikipages/jspwiki-wikipages-en/maven-metadata-apache.snapshots.https.xml:
> in epilog non
> > >> whitespace content is not allowed but got t (position: END_TAG seen
> ...\nt... @12:2) -> [Help 1]
> > >> ```
> > >> This isn't the first time I've encountered this issue; I faced
> the same error in another PR as well. Do you have any insights into what
> might be causing it?"
> >
> >
> ...
> > Murray Altheim= =
> ===
> > 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
> >
>

Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. [jspwiki]

[Juan Pablo Santos Rodríguez]

Hi Murray,

to add some context to the PR, from what I understand, the important
thing about the Synchronizer class, is more on the switch to use
ReentrantLock instead of synchronized blocks, than the code
readability/simplification. The Synchronizer class just captures an
idiom throughout the code, but what's important is the change being
carried, using ReentrantLocks instead of synchronized.

As for the why of above, for the time now, we are not going to use
virtual threads directly, but we can benefit from it indirectly when
running under JDK21, request dispatching and I/O are two examples
where we should see performance gains. And to that we should move away
from synchronized sections (not from *every* synchronized section, a
bit on that below). JEP 444 [#1] introduced Virtual Threads so is a
good starting point to get an overall feeling of how they work and
what they strive to deliver. Quoting from it:

> [...] There are two scenarios in which a virtual thread cannot be unmounted 
> during blocking operations because it is pinned to its carrier:
>
>When it executes code inside a synchronized block or method, or
>When it executes a native method or a foreign function.
>
> Pinning does not make an application incorrect, but it might hinder its 
> scalability. If a virtual thread performs a blocking operation such as I/O
> or BlockingQueue.take() while it is pinned, then its carrier and the 
> underlying OS thread are blocked for the duration of the operation. Frequent
> pinning for long durations can harm the scalability of an application by 
> capturing carriers.
> The scheduler does not compensate for pinning by expanding its parallelism. 
> Instead, avoid frequent and long-lived pinning by revising synchronized
> blocks or methods that run frequently and guard potentially long I/O 
> operations to use java.util.concurrent.locks.ReentrantLock instead. There is 
> no
> need to replace synchronized blocks and methods that are used infrequently 
> (e.g., only performed at startup) or that guard in-memory operations.
> As always, strive to keep locking policies simple and clear.
> [...]
> In a future release we may be able to remove the first limitation above, 
> namely pinning inside synchronized.[...]

(the carrier is the platform [normal / real / underlying] thread)

So, generally, switching to ReentrantLock should be the way to go to
benefit from virtual threads. The case you highlight, as per the jep,
could be left as a it is, but I don't see much difference on
performance there either. Most probably, the synchronized keyword is
being translated under the hoods to the code generated by the
synchronized class; I haven't seen the generated bytecode, so I may be
completely wrong here, it's a gut feeling. I don't have an strong
opinion whether to use one over the other (I'll defer Arturo to that),
but since it seems that it could fit the idiom, and was done in the
PR, which carries some significant work, I've lgtm'ed that when
reviewing - but I'm more than happy to be corrected if it isn't a good
solution.

Regarding the increase in memory usage, as per [#2], a fully working
WikiEngine weights around 5.5MB. The attached PR adds, say about, 40
to 60 ReentrantLock, haven't counted them, which are either static or
part of a WikiEngine manager, that is, those locks should not increase
over time. I have no idea about the impact on memory that they will
have, but hopefully we can run that test afterwards and observe how
much that costs to the Engine and iterate over that. I expect that the
memory increase should be tolerable, specially if it allows to benefit
from virtual threads, but again, will be very grateful for ayone
correcting me. And, on the particular case you mention, I have no
strong opinion on which one should be used, I think both of them
should be fine, but happy to be corrected if needed, I just wanted to
put some context on the PR.

As a side note, IIRC, the technique you describe for creating
singletons is the same that enums use under the covers to create their
values, so a very clean way to create singletons as of today is
through enums, f.ex.:

public enum IdGenerator {
INSTANCE;
public static getInstance() {
return INSTANCE;
}
[...]
}

should be roughly the same as the example noted on the previous email.


best regards,
juan pablo

[#1] https://openjdk.org/jeps/444
[#2] https://lists.apache.org/thread/cqppw3bmgmthr86718yrhtz93kw3d2h1


On Thu, Oct 12, 2023 at 12:38 AM Murray Altheim  wrote:
>
> Hi,
>
> My use of the synchronized block in WikiEventManager was based on a
> section "Use Double-Checked Locking to Reduce Synchronization" of Craig
> Larman and Rhett Guthrie's book "Java 2: Performance and Idiom Guide"*
> about the use of a synchronized block on singleton classes protected by
> a pair of null checks.
>
> I have been successfully using this approach in my own software designs
> since the 90s, quoting from page 100:
>
>"Consider the example of 

Failing CI builds (was: Re: [PR] JSPWIKI-925 - Add Missing i18n Literals for Multiple Languages [jspwiki])

[Juan Pablo Santos Rodríguez]

Hi,

yup, noticed a couple of days ago, seems a malformed maven metadata
file has been
uploaded to the snapshots repository, making impossible to deploy a
specific module. As
our ci build automatically deploys snapshots, we're stucked there.

Contacted infra a couple of days back about this [#1], but no answers
yet; also opened
a jira ticket today ([#2]) to track this.


best regards,
juan pablo

[#1] https://lists.apache.org/thread/7w1gmzcr2xhgttssl0s83pv80h1szql8
(needs asf login)
[#2] https://issues.apache.org/jira/browse/INFRA-25078 (needs asf login)

On Wed, Oct 11, 2023 at 1:36 AM Murray Altheim  wrote:
>
> To be clear, in XML, comments are permitted in the XML Prolog (Production
> 22 in the XML spec) and the doctypedecl (Production 28), but I think the
> POM parser barfs on them.
>
> On 11/10/23 12:24, Murray Altheim wrote:
> > Hi Arturo,
> >
> > Does there happen to be an XML comment between the  declaration
> > and the  start tag? That's what the error message suggests.
> >
> > Cheers,
> >
> > Murray
> >
> > On 11/10/23 05:44, arturobernalg (via GitHub) wrote:
> >>
> >> arturobernalg commented on PR #312:
> >> URL: https://github.com/apache/jspwiki/pull/312#issuecomment-1755833207
> >>
> >> @juanpablo-santos
> >> I'm encountering the following error while when the CI is running:
> >> ```[ERROR] Failed to execute goal 
> >> org.apache.maven.plugins:maven-deploy-plugin:3.1.1:deploy (default-deploy) 
> >> on project jspwiki-wikipages-en: Failed to update metadata
> >> org.apache.jspwiki.wikipages:jspwiki-wikipages-en/maven-metadata.xml: 
> >> Could not parse metadata 
> >> /home/jenkins/.m2/repository/org/apache/jspwiki/wikipages/jspwiki-wikipages-en/maven-metadata-apache.snapshots.https.xml:
> >>  in epilog non
> >> whitespace content is not allowed but got t (position: END_TAG seen 
> >> ...\nt... @12:2) -> [Help 1]
> >> ```
> >> This isn't the first time I've encountered this issue; I faced the 
> >> same error in another PR as well. Do you have any insights into what might 
> >> be causing it?"
>
> ...
> Murray Altheim= =  ===
> 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
>

[DRAFT] board report for 2023/10

[Juan Pablo Santos Rodríguez]

Hi,

as usual the draft for next board's report (due to 11th); any edits,
comments, etc are more than welcome!

best regards,
juan pablo

[DRAFT] board report for 2023/10
---
 board-reports/2023-10.txt | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/board-reports/2023-10.txt b/board-reports/2023-10.txt
new file mode 100755
index 000..184e9f5
--- /dev/null
+++ b/board-reports/2023-10.txt
@@ -0,0 +1,34 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related to
+Leading open source WikiWiki engine, feature-rich and built around standard
+JEE components (Java, servlets, JSP).
+
+## Project Status:
+Current project status: Ongoing, with low activity.
+Issues for the board: There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (10 years ago)
+There are currently 15 committers and 9 PMC members in this project.
+The Committer-to-PMC ratio is 5:3.
+
+Community changes, past quarter:
+- Arturo Bernal was added to the PMC on 2023-06-21
+- Arturo Bernal was added as committer on 2023-06-21
+
+## Project Activity:
+2.12.1 release happened this quarter, which fixed the workflow approval area,
+which wasn't working as expected since a lot of releases, upgraded bundled
+dependencies and defaulted jspwiki working directory to
+$javax.servlet.context.tempdir if it existed.
+
+We are having talks about incoming 2.12.2, trying to catch on with our
+stated release train.
+
+
+## Community Health:
+Work on latest master shows commits from 3 different commiters.
+
+Other than that, we got the usual amount of emails (that is, not too much). No
+unanswered questions, and there is enough people appearing on the ML and
+providing project oversight.
\ No newline at end of file

Re: [PR] [JSPWIKI-1178] Address potential deadlock with JDK 21 Virtual Threads. (jspwiki)

[Juan Pablo Santos Rodríguez]

Hi Murray,

broadly speaking, synchronized blocks aren't go to play so very nice
with the new virtual threads functionality, so in order to take
advantage of them, the suggeston is to switch to something else,
namely locking with a ReentrantLock

Going that way, the PR ends up having a lot of blocks like

> lock.lock();
> try {
> doSomething();
> } finally {
> lock.unlock();
> }

instead of having that everytime, I suggested encapsulating that block
on an utility method, so instead of that you simply end up writting
something like

> Synchronizer.synchronize( lock, ()-> doSomething() );

The utility class is just to capture the idiom that is getting
repeated throughout the code, not managing or trying to enhance the
lock in any way. And of course, if later on more advanced cases of
locking/syncing appear, we can move away from the utility method, and
we also don't have to tie to it later on if it's not needed.


cheers,
juan pablo

On Mon, Oct 9, 2023 at 12:22 PM Murray Altheim  wrote:
>
> Hi,
>
> My apologies for arriving a bit out of context, so please excuse me if this
> has already been asked or addressed, but can I assume that we would be using
> the existing java.util.concurrent.locks.ReentrantLock class for this? I'm
> trying to understand the question better. I don't see the need for a utility
> class if ReentrantLock is used, and would advise against a bespoke solution
> considering the JVM is likely optimised to handle the existing class.
>
> I'm not yet familiar with JDK 21's Virtual Threads and am just reading up
> on them now.
>
> Cheers,
>
> Murray
>
> On 9/10/23 22:05, juanpablo-santos (via GitHub) wrote:
> >
> > juanpablo-santos commented on PR #307:
> > URL: https://github.com/apache/jspwiki/pull/307#issuecomment-1752606848
> >
> > Hi @arturobernalg !
> >
> > > However, this approach has limitations when it comes to working with 
> > condition variables and allowing for custom scenarios. Specifically, using 
> > a utility class for locking would make it challenging to implement more 
> > complex control flows that involve waiting for certain conditions to be met 
> > or signaling other threads to proceed.
> > >
> > > In essence, while the utility class would make the code cleaner for 
> > basic locking and unlocking, it might not be flexible enough to handle 
> > advanced locking scenarios that require the use of conditions.
> >
> > I agree that more complex scenarios would fit inside this utility 
> > class. However, the scope of the PR is to switch away from `synchronized` 
> > blocks, and for all them we have the same idiom all over the place:
> >
> > ```
> > lock.lock();
> > try {
> > doSomething();
> > } finally {
> > lock.unlock();
> > }
> > ```
> >
> > So abstracting it into a common method makes sense to me. If later on a 
> > we want to refactor or we want to capture more complex scenarios, we can 
> > move away from the utility `synchronize` method. The utility/class method 
> > focus should be more about synchronizing than locking (hence the names).
> >
> > WDYT?
> >
> >
>
> --
>
> ...
> Murray Altheim= =  ===
> 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
>

Re: Timing of Next Apache JSPWiki Release 2.12.2

[Juan Pablo Santos Rodríguez]

Hi!

My 2c, I'd rather wait and merge those two issues, they're close to
completion and the java 21 support enhancements would be really cool to
have.

I'd also like to push some dependency upgrades sitting on my PC, I'll try
to do it between tomorrow and next Wednesday. Also I'll draft the report
for the incoming Board meeting.


Cheers,
juan pablo

El jue, 5 oct 2023, 14:49, Arturo Bernal  escribió:

> Dear Apache JSPWiki Development Team and PMC Members,
>
> I hope this email finds you well. As we approach the two-month mark since
> our last release in August, I'd like to discuss the timing and content of
> our next release.
>
> While we have made significant progress on various fronts, there are a
> couple of pending tickets, specifically JSPWIKI-1056 and JSPWIKI-1178, that
> are nearing completion. I believe these would be valuable additions to our
> next release.
>
> Given everyone's tight schedules, I'd like to hear your thoughts on whether
> we should proceed with the planned release or wait a bit longer for these
> tickets to be merged.
>
> Your timely feedback will greatly assist in our planning and
> decision-making process for the upcoming release.
>
> Best regards,
>
> Arturo
>

Re: Discussion on Fixing Relative URLs in Email Notifications (JSPWIKI-1056)

[Juan Pablo Santos Rodríguez]

Hi!

Thx for looking into this :-) On the associated PR, I wondered if checking
for an specific, custom, header with the appropriate value for the absolute
url would be the way to go, due to uncovered corner cases if we check for
"known" headers.

On a second thought, I'm more comfortable if we follow your approach:
corner cases with known headers can be solved with the same configuration
needed if we go through the custom header route; plus, setting up known
headers will raise less eyebrows than setting some app-specific stuff on
the web server.


Cheers,
juan pablo

El mar, 3 oct 2023, 20:04, Arturo Bernal  escribió:

> HI,
>
> Maybe we should consider extending the URL construction logic to include
> checks for the X-Forwarded-Server header, in addition to X-Forwarded-Host
> and X-Forwarded-Proto. This would offer a more comprehensive way to
> determine the original server and scheme, particularly in scenarios where
> the application is behind a proxy.
>
> What are your thoughts on this approach?
>
> Arturo
>
>
> On Tue, Oct 3, 2023 at 6:41 PM Arturo Bernal  wrote:
>
> > Hi Team,
> >
> > I hope this email finds you well. I am writing to open a discussion on
> the
> > issue JSPWIKI-1056 ,
> > which concerns the generation of relative URLs in email notifications
> sent
> > after user registration.
> >
> > As some of you may know, the emails currently contain relative URLs due
> to
> > changes in JSPWIKI-1035
> > . I have submitted a
> > pull request (PR #311 ) that
> > aims to address this by generating absolute URLs. The PR introduces
> utility
> > methods in HttpUtil for this purpose.
> >
> > However, there are concerns about how this approach handles different
> > deployment scenarios, especially when JSPWiki installations are behind a
> > web server like Apache. The issue is that using HttpServletRequest to
> > generate the URL could expose internal URLs, which is not intended.
> >
> > I would like to invite your thoughts on how best to tackle this issue.
> > Some options include:
> >
> >1. Checking for specific headers that might contain the "external"
> >IP/domain.
> >2. Introducing a new configuration option to set the base URL
> >explicitly.
> >
> > I look forward to your input on this matter. Your expertise and insights
> > would be invaluable in finding the most robust and flexible solution.
> >
> > Best regards,
> >
> > Arturo
> >
>

Re: [apache/jspwiki] JSPWIKI-1181 - Fix: Correct URL Generation for Pages with Special Characters (PR #310)

[Juan Pablo Santos Rodríguez]

Typo, meant 2.12.2-git-03 (although nothing especially important, if it
stays on git-02 is ok too)

Br,
juan pablo

El dom, 1 oct 2023, 19:01, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> escribió:

> Hi! Shouldn't this be part of 2.12.1-git-03 instead?
>
> Cheers,
> juan pablo
>
> El dom, 1 oct 2023, 18:58, Arturo Bernal 
> escribió:
>
>> @arturobernalg <https://github.com/arturobernalg> pushed 1 commit.
>>
>>- 6bf3f32
>>
>> <https://github.com/apache/jspwiki/commit/6bf3f324114c063e2b6c51b38f140c91fb859a81>
>>Add changelog
>>
>> —
>> View it on GitHub
>> <https://github.com/apache/jspwiki/pull/310/files/c6f161eedaa02ca8b0e31e21ac9d70ee59dd990a..6bf3f324114c063e2b6c51b38f140c91fb859a81>
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AAJJPYXGKYI3ONIZUW7QJCLX5GOLFANCNFSM6AA5OJJ2AU>
>> .
>> You are receiving this because you are subscribed to this thread.Message
>> ID: 
>>
>

Re: [apache/jspwiki] JSPWIKI-1181 - Fix: Correct URL Generation for Pages with Special Characters (PR #310)

[Juan Pablo Santos Rodríguez]

Hi! Shouldn't this be part of 2.12.1-git-03 instead?

Cheers,
juan pablo

El dom, 1 oct 2023, 18:58, Arturo Bernal 
escribió:

> @arturobernalg  pushed 1 commit.
>
>- 6bf3f32
>
> 
>Add changelog
>
> —
> View it on GitHub
> 
> or unsubscribe
> 
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: 
>

Re: Delay in Website Update for Latest Release

[Juan Pablo Santos Rodríguez]

The website has been updated, so I think all is fine and dandy now, no need
to look into nothing :-)


Best regards
juan pablo

El dom, 13 ago 2023, 13:27, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> escribió:

> Hiya!
>
> Site update is fine through
> https://ci-builds.apache.org/job/JSPWiki/job/site/
>
> This job is scheduled every time a commit is pushed into master, on
> jspwiki's main repo, and it appears to have run successfully last on 7th
> Aug.
>
> I've just scheduled a build, so hopefully we'll have the site updated in a
> few minutes. If it doesn't, we'll have to look into why.. last build
> displays a suspicious message at the very end:
>
> remote: Saw GitHub meta-data in .asf.yaml, but not in main/master/trunk or
> default branch, not updating...
>
>
> Best regards,
> juan pablo
>
> El dom, 13 ago 2023, 12:11, Arturo Bernal  escribió:
>
>> HI All
>>
>> There seems to be a delay in the website update reflecting the latest
>> release notes and versions. I committed the changes last Friday, but as of
>> now,  it doesn't seem to have taken effect.
>>
>> Could you please check on this and let me know if there's any additional
>> action required from my end?
>>
>> Best regards,
>>
>> Arturo
>>
>

Re: Delay in Website Update for Latest Release

[Juan Pablo Santos Rodríguez]

Hiya!

Site update is fine through
https://ci-builds.apache.org/job/JSPWiki/job/site/

This job is scheduled every time a commit is pushed into master, on
jspwiki's main repo, and it appears to have run successfully last on 7th
Aug.

I've just scheduled a build, so hopefully we'll have the site updated in a
few minutes. If it doesn't, we'll have to look into why.. last build
displays a suspicious message at the very end:

remote: Saw GitHub meta-data in .asf.yaml, but not in main/master/trunk or
default branch, not updating...


Best regards,
juan pablo

El dom, 13 ago 2023, 12:11, Arturo Bernal  escribió:

> HI All
>
> There seems to be a delay in the website update reflecting the latest
> release notes and versions. I committed the changes last Friday, but as of
> now,  it doesn't seem to have taken effect.
>
> Could you please check on this and let me know if there's any additional
> action required from my end?
>
> Best regards,
>
> Arturo
>

Re: [VOTE] Release JSPWiki version 2.12.1

[Juan Pablo Santos Rodríguez]

Hi,

my +1

cheers!
juan pablo

El mar, 8 ago 2023, 2:06, Murray Altheim  escribió:

> I will be traveling for the next few days and unable to download or test
> the code, so with my apologies, my vote is:
>
>  0.
>
> Cheers,
>
> Murray
>
> On 8/8/23 06:29, Arturo Bernal wrote:
> >  Good Afternoon everyone,
> >
> >  This is a release vote for Apache JSPWiki, version 2.12.1. The vote
> > will be open for at least 72 hours from now.
> >
> >  It fixes the following issues:
> >
> >  https://issues.apache.org/jira/projects/JSPWIKI/versions/12353279
> >
> >
> https://github.com/apache/jspwiki/commit/5d78b49c6a15f633813147cd7a4a4aa8a1b2cf55
> >
> >  You can see a curated changelog at
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12
> >
> >  Note that we are voting upon the source (tag), binaries are provided
> > for convenience.
> >
> >  Everybody is encouraged to vote.
> >
> >  Source and binary files:
> >  https://dist.apache.org/repos/dist/dev/jspwiki/2.12.1-RC1
> >
> >  Nexus staging repo:
> > https://repository.apache.org/content/repositories/orgapachejspwiki-1031
> >
> >  The tag to be voted upon:
> >  https://github.com/apache/jspwiki/tree/2.12.1-RC1
> >
> >  JSPWiki's KEYS file containing PGP keys we use to sign the release:
> >  https://www.apache.org/dist/jspwiki/KEYS
> >
> >  *** Please download, test and vote:
> >
> >  [ ] +1 Approve the release
> >  [ ]  0 Don't mind
> >  [ ] -1 Disapprove the release (please provide specific comments)
> >
> > Cheers,
> > --
> > Arturo
> >
>
> --
>
> ...
> Murray Altheim= =  ===
> 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
>
>

Workflow documentation [Re: 2.12.1?]

[Juan Pablo Santos Rodríguez]

Hi Murray,

I've drafted some doc at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Workflow%20configuration

It has been mostly taken from the jspwiki.properties file, but I think
it's enough for starters.

Please (anyone) feel free to update that page :-)


cheers,
juan pablo

On Thu, Jun 22, 2023 at 3:12 AM Murray Altheim  wrote:
>
> Hi Juan Pablo,
>
> Sorry for being out of the loop, but could you provide a reference to
> the workflow documentation? That would be very helpful, thank you. I've
> not investigated it previously.
>
> Cheers,
>
> Murray
>
> On 6/22/23 05:11, Juan Pablo Santos Rodríguez wrote:
> > Hi,
> >
> > given that the workflow area is now working as expected, I'd like to
> > release it, with the usual dependency updates and maybe PR #282, which
> > seems pretty close to completion.
> >
> > Sounds reasonable? I know 2.12.0 has been released pretty close, but
> > the workflow approval functionality seems to me like something that
> > should be working ASAP.. WDYT?
> >
> >
> > cheers,
> > juan pablo
> ...
> Murray Altheim= =  ===
> 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
>

[DRAFT] Board report for July/August meeting

[Juan Pablo Santos Rodríguez]

Hi,

as mentioned else-thread, please see below the draft for next board
meeting. As usual, any comment, edit, etc. is more than welcome!

This time we have more than a week for report submission, so there's
plenty of time for review


cheers,
juan pablo


 board-reports/2023-08.txt | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/board-reports/2023-08.txt b/board-reports/2023-08.txt
new file mode 100755
index 000..ae4e115
--- /dev/null
+++ b/board-reports/2023-08.txt
@@ -0,0 +1,35 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related to
+Leading open source WikiWiki engine, feature-rich and built around standard
+JEE components (Java, servlets, JSP).
+
+## Project Status:
+Current project status: Ongoing, with low activity.
+Issues for the board: There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (10 years ago)
+There are currently 15 committers and 9 PMC members in this project.
+The Committer-to-PMC ratio is 5:3.
+
+Community changes, past quarter:
+- Arturo Bernal was added to the PMC on 2023-06-21
+- Arturo Bernal was added as committer on 2023-06-21
+
+## Project Activity:
+2.12.0 release happened this quarter, which fixed some XSS vulnerabilities and
+also uplifted the JDK requirement up to JDK-11. We also got a couple of
+vulnerability reports, which were discarded and, after a query on the dev ML,
+we realized that the workflow approval area wasn't working as expected since a
+lot of releases, so we fixed it and we're preparing a 2.12.1 release.
+
+
+## Community Health:
+Most important thing happening in this area, we finally added a PMC/committer
+to our roster! After being engaged on the MLs for some time and sending some
+PRs, Arturo Bernal joined JSPWiki PMC on June. He'll also be acting as RM for
+2.12.1, so that's another positive thing.
+
+Other than that, we got the usual amount of emails (that is, not too much). No
+unanswered questions, and there is enough people appearing on the ML and
+providing project oversight. Traffic on dev list reflects mostly PRs movement.
\ No newline at end of file

Re: 2.12.1?

[Juan Pablo Santos Rodríguez]

Hi,

At least! I pushed yesterday the aforementioned updates, so we can begin
with the release. Anyone volunteering to drive it? I'd help with whatever
is needed..

Also, late tonight I'll draft a board report for August's meeting, I missed
it for July meeting, so this time we're due to submit it on August.

Finally, Murray, regarding the workflow documentation, there isn't anything
at jspwiki-wiki.a.o right now. User creation and page saves can be subject
of some group approval. There are a bunch of properties at
jspwiki.properties that enable this functionality. I'll also document it if
I get enough time tonight.


Best regards,
juan pablo

El jue, 22 jun 2023, 3:12, Murray Altheim  escribió:

> Hi Juan Pablo,
>
> Sorry for being out of the loop, but could you provide a reference to
> the workflow documentation? That would be very helpful, thank you. I've
> not investigated it previously.
>
> Cheers,
>
> Murray
>
> On 6/22/23 05:11, Juan Pablo Santos Rodríguez wrote:
> > Hi,
> >
> > given that the workflow area is now working as expected, I'd like to
> > release it, with the usual dependency updates and maybe PR #282, which
> > seems pretty close to completion.
> >
> > Sounds reasonable? I know 2.12.0 has been released pretty close, but
> > the workflow approval functionality seems to me like something that
> > should be working ASAP.. WDYT?
> >
> >
> > cheers,
> > juan pablo
> ...
> Murray Altheim= =  ===
> 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
>
>

Re: JSP Wiki ShortURLConstructor

[Juan Pablo Santos Rodríguez]

Resending, including issuer, as it seems isn't subscribed.

Duy, please consider subscribing to the ML [#1], all your mails are being
answered, but there's a chance you've missed a few. You can check them at
[#2].

Best regards,
juan pablo

[#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Mailing%20Lists
[#2] https://lists.apache.org/list.html?u...@jspwiki.apache.org

El mar, 18 jul 2023, 21:38, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> escribió:

> Hi Duy Thàn!
>
> did you also set the wiki/ prefix on your web.xml file? (see note on
> jspwiki.properties, line 450 onwards) Would you mind also testing if
> ShortViewUrlConstructor works for page edits?
>
>
> thanks + best regards,
> juan pablo
>
> On Mon, Jul 17, 2023 at 9:50 AM Thành Duy  wrote:
> >
> > Dear Dev Team,
> >
> > I changed the config to use ShortURLConstructor, But do not work well.
> Edit page still loading but live preview area not working.
> > Can you give me advice or suggestions to fix this problem?
> > Refer to attached file for more detail.
> >
> > Thank you! Regards!!!
> >
> > --
> > FullName: Nguyễn Duy Thành.
> > Shool: ĐHKHTN.
>

Re: JSP Wiki ShortURLConstructor

[Juan Pablo Santos Rodríguez]

Hi Duy Thàn!

did you also set the wiki/ prefix on your web.xml file? (see note on
jspwiki.properties, line 450 onwards) Would you mind also testing if
ShortViewUrlConstructor works for page edits?


thanks + best regards,
juan pablo

On Mon, Jul 17, 2023 at 9:50 AM Thành Duy  wrote:
>
> Dear Dev Team,
>
> I changed the config to use ShortURLConstructor, But do not work well. Edit 
> page still loading but live preview area not working.
> Can you give me advice or suggestions to fix this problem?
> Refer to attached file for more detail.
>
> Thank you! Regards!!!
>
> --
> FullName: Nguyễn Duy Thành.
> Shool: ĐHKHTN.

Re: Jspwiki servlet version

[Juan Pablo Santos Rodríguez]

Hi!

JSPWiki is servlet 3.1 based, which means you need at least tomcat 9 to run
it (or tomcat 8, with some tweaks, see [#1])

IIRC, we do use some methods from servlet 3.1, so downgrading to servlet
3.0 won't be enough to run JSPWiki.


HTH,
juan pablo

p.s.: this mail came through moderation, which probably means you're not
subscribed to the dev ML; subscribing is entirely optional ([#2]), but
mails will be delivered without needing moderation and, more importantly,
you'll receive answers without anyone needing to cc: back (is something
easy to forget)

[#1]
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Getting%20Started#section-Getting+Started-Tomcat8.x

[#2] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Mailing%20Lists


El jue, 13 jul 2023, 16:03, Thành Duy  escribió:

> Dear dev team!
>
> I am using jspwiki 2.11.3. It seem servlet 4.0, right? I want downgrade to
> 3.0. Can I downgrade without problem?
>
> Thank you!!!
> --
> *FullName: Nguyễn Duy Thành.*
> *Shool: ĐHKHTN.*
>

2.12.1?

[Juan Pablo Santos Rodríguez]

Hi,

given that the workflow area is now working as expected, I'd like to
release it, with the usual dependency updates and maybe PR #282, which
seems pretty close to completion.

Sounds reasonable? I know 2.12.0 has been released pretty close, but
the workflow approval functionality seems to me like something that
should be working ASAP.. WDYT?


cheers,
juan pablo

Re: Auto Login in JSPWiki

[Juan Pablo Santos Rodríguez]

Hi,

JSPWiki doesn't have some sort of OAuth login integration, so I'd say
that kind of integration would involve either
a) setting up a POST to the Wiki login page and somehow retrieving the
jsessionid, so you can forward to JSPWiki appending it as a request
param or
b) set up JSPWiki login to use container based authentication and then
use some 3rd aprty oauth realm integration (see f.ex.
https://stackoverflow.com/q/39058200 for some guidance)

it is not much, but HTH
juan pablo


On Wed, Jun 21, 2023 at 6:46 AM Thành Duy  wrote:
>
> Dear Dev Team,
>
> Currently I am developing my application. I have a technical issue. In my
> application I logined. I have a button, when i clicked button in
> my application, it will redirect to JSPWiki server and auto login use user
> info in my application. But i don't know how to make it in JSPWiki.
> Hope you can help me!
> Thank you
> --
> *FullName: Nguyễn Duy Thành.*
> *Shool: ĐHKHTN.*

[ANNOUNCE] Arturo Bernal as new JSPWiki PMC and committer!

[Juan Pablo Santos Rodríguez]

Hi all,

We're glad to announce that the JSPWiki PMC has a new member and
committer, Arturo Bernal.


Welcome!

juan pablo,
on behalf of the JSPWiki PMC

Re: delay on 2.12.0 release vote

[Juan Pablo Santos Rodríguez]

Hi!

made some comments on the PR, let's try to bring back the reverted
config and applying your changes. If it works as expected, I see no
reason to not merging it

cheers,
juan pablo


On Sat, Jun 10, 2023 at 11:35 PM Arturo Bernal
 wrote:
>
> HI Juan Pablo,
>
> I have been exploring possible solutions for this conflict and have proposed 
> a potential fix by adjusting the nested dependencies within the plugin. This 
> was done by suggesting the exclusion of the minimatch dependency from the 
> globlibrary within the wro4j-maven-plugin.
>
> However, please note that I cannot fully guarantee the efficacy of this 
> solution without complete knowledge of the wider system and its dependencies. 
> Exclusions can sometimes lead to runtime issues, particularly if parts of our 
> code are dependent on the excluded libraries.
>
> I have created a pull request (https://github.com/apache/jspwiki/pull/285) 
> with these changes and I recommend thorough testing of these modifications to 
> ensure it doesn't inadvertently cause other issues.
>
> Best regards,
>
>
> Arturo Bernal
> arturobern...@yahoo.com
>
>
>
> > On 9 May 2023, at 00:26, Juan Pablo Santos Rodríguez 
> >  wrote:
> >
> > Hi,
> >
> > finally tonight I was able to begin with the release vote for 2.12.0 and
> > prepare the RC1 artifacts. Unfortunately, I've just seen that the docker
> > images aren't compiling due to an error on the main module while executing
> > mvn -B dependency:go-offline (we do that in order to cache the artifacts
> > download and speed up the docker build); seems that some transitive
> > dependencies on the wro maven plugin aren't playing nicely one with
> > another. I'll try to fix it somewhere this week, possibly tomorrow, so we
> > can start the release vote ASAP with RC2 artifacts. If someone wants to
> > step in and fix it, please do it.
> >
> >
> > thx and apologies for the delay,
> > juan pablo
>

CVE-2022-46907: Apache JSPWiki Cross-site scripting on several plugins

[Juan Pablo Santos Rodríguez]

Severity: moderate

Description:
A carefully crafted request on several JSPWiki plugins could trigger
an XSS vulnerability on Apache JSPWiki, which could allow the attacker
to execute javascript in the victim's browser and get some sensitive
information about the victim.

Mitigation:
Apache JSPWiki users should upgrade to 2.12.0 or later.

Credit:
This issue was discovered by Eugene Lim and Sng Jay Kai from
Government Technology Agency of Singapore

References:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-46907

[ANNOUNCE] Apache JSPWiki 2.12.0 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki 2.12.0.

This is the first release on the 2.12 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.12.0

A curated change log is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/

The Apache JSPWiki Team

[RESULT][VOTE] Release JSPWiki version 2.12.0

[Juan Pablo Santos Rodríguez]

Hi,

with more than 72 hours passed, I'm closing the vote. So far we've got the
following +1 (* noting PMC member), and no other votes:

Murray Altheim
Arturo Bernal
* Dirk Frederickx
* Harry Metske
* Juan Pablo Santos

With this tally, the vote passes, I'll proceed with the release.

Thanks to everyone that participated on the vote!

best regards,
juan pablo


On Sun, May 21, 2023 at 4:38 PM Murray Altheim  wrote:

> Hi Juan Pablo,
>
> I've gone ahead and installed Tomcat 9 and successfully deployed
> JSPWiki 2.12.0. Thanks for the information -- all is good.
>
>+1
>
> Cheers,
>
> Murray
>
> On 5/21/23 21:27, Juan Pablo Santos Rodríguez wrote:
> > Hi Murray!
> >
> > Tomcat 10 onwards support the jakarta namespace instead of javax (the one
> > that JSPWiki compiles to), so JSPWiki cannot run on it without
> > modifications. There's
> > https://issues.apache.org/jira/projects/JSPWIKI/issues/JSPWIKI-1170 to
> > track that, but so far we haven't done anything in that direction.
> >
> > IIRC, Tomcat offers a migration tool, to seamlessly migrate from one
> > namespace to the other, but I haven't tried it. Also, IIRC, you can place
> > your javax war application on some special $TOMCAT folder
> > (webapp-something) and it also translates it to a jakarta-based
> > application, but I haven't tried it.
> >
> > We should document that at jspwiki-wiki.a.org, as of today tomcat 9 or
> > equivalent is a hard requirement to run JSPWiki.
> >
> >
> > HTH,
> > juan pablo
> >
> > El dom, 21 may 2023, 14:14, Murray Altheim 
> escribió:
> >
> >> Here's the relevant log file:
> >>
> >> 21-May-2023 19:25:34.754 INFO [main]
> >> org.apache.catalina.core.ApplicationContext.log ContextListener:
> >> contextInitialized()
> >> 21-May-2023 19:25:34.754 INFO [main]
> >> org.apache.catalina.core.ApplicationContext.log SessionListener:
> >> contextInitialized()
> >> 21-May-2023 19:25:34.755 INFO [main]
> >> org.apache.catalina.core.ApplicationContext.log ContextListener:
> >> attributeAdded('StockTicker', 'async.Stockticker@2baa48e3')
> >> 21-May-2023 19:26:45.627 SEVERE [Catalina-utility-2]
> >> org.apache.catalina.core.StandardContext.listenerStart Error
> >> configuring application listener of class
> >> [org.apache.wiki.auth.SessionMonitor]
> >>   java.lang.NoClassDefFoundError:
> javax/servlet/http/HttpSessionListener
> >>   at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> >>   at
> >> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> >>   at
> >>
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
> >>   at
> >>
> org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2487)
> >>
> >>
> >> On 5/21/23 19:36, Murray Altheim wrote:
> >>> Hi,
> >>>
> >>> Sorry for the late reply, but here's my report (no 'yes' vote, sorry,
> >> see below).
> >>>
> >>> I'm running Ubuntu 23.04 on a Dell XPS 9315. I was able to successfully
> >> build
> >>> JSPWiki 2.12.0 with no issues, using:
> >>>
> >>> Picked up JAVA_TOOL_OPTIONS: -Xms512m -Xmx8192m
> >>> java version "11.0.11" 2021-04-20 LTS
> >>> Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
> >>> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194,
> >> mixed mode)
> >>>
> >>> I deployed the war file to Apache Tomcat/10.1.8 and it failed to run,
> >>>
> >>> FAIL - Application at context path [/JSPWiki] could not be started
> >>>
> >>> with very little helpful in the logs:
> >>>
> >>> 21-May-2023 19:26:04.308 INFO [http-nio-7070-exec-9]
> >> org.apache.catalina.startup.HostConfig.undeploy Undeploying context
> >>> [/ws]
> >>> 21-May-2023 19:26:44.802 INFO [Catalina-utility-2]
> >> org.apache.catalina.startup.HostConfig.deployWAR Deploying web
> >>> application archive [/opt/apache-tomcat-10.1.8/webapps/JSPW
> >>> 21-May-2023 19:26:45.625 INFO [Catalina-utility-2]
> >> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
> >>> scanned for TLDs yet contained no TLDs. Enable debug lo
> >>> 21-May-2023 19:26:45.628 SEVERE [Catalina-utility-2]
> >> org.apache.catalina.core.StandardContext.startInternal One or more
&

Re: [VOTE] Release JSPWiki version 2.12.0

[Juan Pablo Santos Rodríguez]

Hi Murray!

Tomcat 10 onwards support the jakarta namespace instead of javax (the one
that JSPWiki compiles to), so JSPWiki cannot run on it without
modifications. There's
https://issues.apache.org/jira/projects/JSPWIKI/issues/JSPWIKI-1170 to
track that, but so far we haven't done anything in that direction.

IIRC, Tomcat offers a migration tool, to seamlessly migrate from one
namespace to the other, but I haven't tried it. Also, IIRC, you can place
your javax war application on some special $TOMCAT folder
(webapp-something) and it also translates it to a jakarta-based
application, but I haven't tried it.

We should document that at jspwiki-wiki.a.org, as of today tomcat 9 or
equivalent is a hard requirement to run JSPWiki.


HTH,
juan pablo

El dom, 21 may 2023, 14:14, Murray Altheim  escribió:

> Here's the relevant log file:
>
> 21-May-2023 19:25:34.754 INFO [main]
> org.apache.catalina.core.ApplicationContext.log ContextListener:
> contextInitialized()
> 21-May-2023 19:25:34.754 INFO [main]
> org.apache.catalina.core.ApplicationContext.log SessionListener:
> contextInitialized()
> 21-May-2023 19:25:34.755 INFO [main]
> org.apache.catalina.core.ApplicationContext.log ContextListener:
> attributeAdded('StockTicker', 'async.Stockticker@2baa48e3')
> 21-May-2023 19:26:45.627 SEVERE [Catalina-utility-2]
> org.apache.catalina.core.StandardContext.listenerStart Error
> configuring application listener of class
> [org.apache.wiki.auth.SessionMonitor]
>  java.lang.NoClassDefFoundError: javax/servlet/http/HttpSessionListener
>  at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>  at
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
>  at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
>  at
> org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2487)
>
>
> On 5/21/23 19:36, Murray Altheim wrote:
> > Hi,
> >
> > Sorry for the late reply, but here's my report (no 'yes' vote, sorry,
> see below).
> >
> > I'm running Ubuntu 23.04 on a Dell XPS 9315. I was able to successfully
> build
> > JSPWiki 2.12.0 with no issues, using:
> >
> >Picked up JAVA_TOOL_OPTIONS: -Xms512m -Xmx8192m
> >java version "11.0.11" 2021-04-20 LTS
> >Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
> >Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194,
> mixed mode)
> >
> > I deployed the war file to Apache Tomcat/10.1.8 and it failed to run,
> >
> >FAIL - Application at context path [/JSPWiki] could not be started
> >
> > with very little helpful in the logs:
> >
> > 21-May-2023 19:26:04.308 INFO [http-nio-7070-exec-9]
> org.apache.catalina.startup.HostConfig.undeploy Undeploying context
> > [/ws]
> > 21-May-2023 19:26:44.802 INFO [Catalina-utility-2]
> org.apache.catalina.startup.HostConfig.deployWAR Deploying web
> > application archive [/opt/apache-tomcat-10.1.8/webapps/JSPW
> > 21-May-2023 19:26:45.625 INFO [Catalina-utility-2]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
> > scanned for TLDs yet contained no TLDs. Enable debug lo
> > 21-May-2023 19:26:45.628 SEVERE [Catalina-utility-2]
> org.apache.catalina.core.StandardContext.startInternal One or more
> > listeners failed to start. Full details will be found21-May-2023
> 19:26:45.629 SEVERE [Catalina-utility-2]
> > org.apache.catalina.core.StandardContext.startInternal Context
> [/JSPWiki] startup failed due to previous errors
> > 21-May-2023 19:26:45.633 INFO [Catalina-utility-2]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> > application archive [/opt/apache-tomcat-10.1.8/webapps/
> >
> > If I'm running the wrong version of Java or Tomcat or there's something
> obvious,
> > I'm happy to fix that within the next 12 hours, but for now I can't vote
> yes.
> >
> > Cheers,
> >
> > Murray
> >
> > On 5/21/23 15:27, Juan Pablo Santos Rodríguez wrote:
> >> Hi,
> >>
> >> This is a gently reminder for our PMC members: we still need one binding
> >> vote to be able to proceed with the release.
> >>
> >>
> >> Thanks in advance!
> >>
> >> El jue, 18 may 2023, 22:01, Arturo Bernal  .invalid>
> >> escribió:
> >>
> >>>
> >>>   [x] +1 Release these artifacts
> >>>
> >>> Build passed with no issues, running `mvn clean test install site`
> >>> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)Maven
> home:
> >>> /opt/apache-maven-3.8.1Ja

Re: [VOTE] Release JSPWiki version 2.12.0

[Juan Pablo Santos Rodríguez]

Hi,

This is a gently reminder for our PMC members: we still need one binding
vote to be able to proceed with the release.


Thanks in advance!

El jue, 18 may 2023, 22:01, Arturo Bernal 
escribió:

>
>  [x] +1 Release these artifacts
>
> Build passed with no issues, running `mvn clean test install site`
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)Maven home:
> /opt/apache-maven-3.8.1Java version: 17.0.2, vendor: Oracle Corporation,
> runtime:
> /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/HomeDefault
> locale: en_US, platform encoding: UTF-8OS name: "mac os x", version:
> "13.3.1", arch: "x86_64", family: "mac"
>
>
> Checked signatures of dist area files, found no issues.
> Additionally, the default goal of Maven is functioning as expected.
>
>
>
> On Tuesday, May 16, 2023 at 11:07:29 AM GMT+2, Harry Metske <
> harry.met...@gmail.com> wrote:
>
>  +1
>
> Looking good!
>
> cheers,
> Harry
>
>
> On Mon, 15 May 2023 at 12:13, Juan Pablo Santos Rodríguez <
> juanpa...@apache.org> wrote:
>
> > This is a release vote for Apache JSPWiki, version 2.12.0. The vote will
> be
> > open for at least 72 hours from now.
> >
> > You can see a curated changelog at
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12
> >
> > Note that we are voting upon the source (tag), binaries are provided for
> > convenience.
> >
> > Everybody is encouraged to vote.
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/jspwiki/2.12.0-RC2
> >
> > Nexus staging repo: https://repository.apache.org/
> > <
> https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
> > content/repositories/
> > <
> https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
> > orgapachejspwiki-1030
> > <
> https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
> >
> > The tag to be voted upon:
> > https://github.com/apache/jspwiki/tree/2.12.0-RC2
> >
> > JSPWiki's KEYS file containing PGP keys we use to sign the release:
> > https://www.apache.org/dist/jspwiki/KEYS
> >
> > *** Please download, test and vote:
> >
> > [ ] +1 Approve the release
> > [ ]  0 Don't mind
> > [ ] -1 Disapprove the release (please provide specific comments)
> >
>

Re: [VOTE] Release JSPWiki version 2.12.0

[Juan Pablo Santos Rodríguez]

my +1

cheers,
juan pablo


On Mon, May 15, 2023 at 12:13 PM Juan Pablo Santos Rodríguez <
juanpa...@apache.org> wrote:

> This is a release vote for Apache JSPWiki, version 2.12.0. The vote will
> be open for at least 72 hours from now.
>
> You can see a curated changelog at
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Everybody is encouraged to vote.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jspwiki/2.12.0-RC2
>
> Nexus staging repo: https://repository.apache.org/
> <https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
> content/repositories/
> <https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
> orgapachejspwiki-1030
> <https://repository.apache.org/content/repositories/orgapachejspwiki-1030>
>
> The tag to be voted upon:
> https://github.com/apache/jspwiki/tree/2.12.0-RC2
>
> JSPWiki's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/jspwiki/KEYS
>
> *** Please download, test and vote:
>
> [ ] +1 Approve the release
> [ ]  0 Don't mind
> [ ] -1 Disapprove the release (please provide specific comments)
>

[VOTE] Release JSPWiki version 2.12.0

[Juan Pablo Santos Rodríguez]

This is a release vote for Apache JSPWiki, version 2.12.0. The vote will be
open for at least 72 hours from now.

You can see a curated changelog at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12

Note that we are voting upon the source (tag), binaries are provided for
convenience.

Everybody is encouraged to vote.

Source and binary files:
https://dist.apache.org/repos/dist/dev/jspwiki/2.12.0-RC2

Nexus staging repo: https://repository.apache.org/

content/repositories/

orgapachejspwiki-1030


The tag to be voted upon:
https://github.com/apache/jspwiki/tree/2.12.0-RC2

JSPWiki's KEYS file containing PGP keys we use to sign the release:
https://www.apache.org/dist/jspwiki/KEYS

*** Please download, test and vote:

[ ] +1 Approve the release
[ ]  0 Don't mind
[ ] -1 Disapprove the release (please provide specific comments)

delay on 2.12.0 release vote

[Juan Pablo Santos Rodríguez]

Hi,

finally tonight I was able to begin with the release vote for 2.12.0 and
prepare the RC1 artifacts. Unfortunately, I've just seen that the docker
images aren't compiling due to an error on the main module while executing
mvn -B dependency:go-offline (we do that in order to cache the artifacts
download and speed up the docker build); seems that some transitive
dependencies on the wro maven plugin aren't playing nicely one with
another. I'll try to fix it somewhere this week, possibly tomorrow, so we
can start the release vote ASAP with RC2 artifacts. If someone wants to
step in and fix it, please do it.


thx and apologies for the delay,
juan pablo

[DRAFT] 2023/04 Board report

[Juan Pablo Santos Rodríguez]

Hi!

please see below draft for upcoming 2023-04 report. It's due for this
wednesday, so hopefully theres enough time for review?


cheers,
juan pablo

-- Forwarded message -
From: 
Date: Mon, Apr 10, 2023 at 9:37 PM
Subject: [jspwiki-asf-docs] branch master updated: [DRAFT] 2023/04 Board
report
To: comm...@jspwiki.apache.org 


This is an automated email from the ASF dual-hosted git repository.

juanpablo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/jspwiki-asf-docs.git


The following commit(s) were added to refs/heads/master by this push:
 new 171be84  [DRAFT] 2023/04 Board report
171be84 is described below

commit 171be8405e33a779c1f46777a81107874e39efb4
Author: Juan Pablo Santos Rodríguez 
AuthorDate: Mon Apr 10 21:37:03 2023 +0200

[DRAFT] 2023/04 Board report
---
 board-reports/2023-04.txt | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/board-reports/2023-04.txt b/board-reports/2023-04.txt
new file mode 100755
index 000..cb5a36a
--- /dev/null
+++ b/board-reports/2023-04.txt
@@ -0,0 +1,35 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related
to
+Leading open source WikiWiki engine, feature-rich and built around
standard
+JEE components (Java, servlets, JSP).
+
+## Issues:
+There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (10 years ago)
+There are currently 14 committers and 8 PMC members in this project.
+The Committer-to-PMC ratio is 7:4.
+
+Community changes, past quarter:
+- No new PMC members. Last addition was Dave Koelmeyer on 2016-04-06.
+- No new committers. Last addition was Dave Koelmeyer on 2016-04-06.
+
+## Project Activity:
+Quiet period, with small developments pushed into master. Aiming for the
+2.12.0 release, the associated vote should start somewhere this week. This
+release contains a fix for some XSS vulnerabilities that has been sitting
+on master for a while now. We would like to thank Arnout Engelen from the
+Security team for kindly following through this reports and ensuring they
+are fixed and released on a reasonable time span.
+
+This quarter we've also reviewed almost all of our pending PRs, and
+discarded a bunch of dependabot false positives.
+
+Last release was 2.11.3 on 2022-08-02.
+
+## Community Health:
+Traffic on both MLs has decreased compared with last quarter, mostly
+reflecting PRs movement.
+
+There is enough people appearing on the ML and providing project oversight.

Incoming release for 2.12.0?

[Juan Pablo Santos Rodríguez]

Hi!

We have some security fixes sitting on master for a while now. We've also
had another security report for some weeks that seems to resolve to not be
an issue, since we haven't heard back from the reporter from quite a while
now.

Maybe it's a good time to proceed with the release of 2.12.0.

I'd like to merge latest dependabot updates and maybe look at other PRs
that are waiting to be looked at, before proceeding with the release, but
that shouldn't take more than this week.

Anyone wanting anything else for 2.12.0, or feeling that there's rush with
the plan, please do tell so we can adjust the release timeframe.


Cheers,
juan pablo

Re: gulpfile.js, package.json and package-lock.json at jspwiki-war?

[Juan Pablo Santos Rodríguez]

Hi Dirk,

Oh I see, thanks for taking care of it. Integrating gulp build files on
maven via frontend-maven-plugin on the main build should be doable, if
needed. I'm curious to see how the gulp build turns out!


Cheers,
juan pablo

El dom, 26 mar 2023, 21:28, Dirk Frederickx 
escribió:

> Hi Juan
>
> These files should not  have been part of a commit I made some months ago.
> I'd been working locally on gulp.js to replace the wrox based tools for
> building the js & css files.
> But it is still very much work in progress.
>
> I'll remove these files for now.
>
> dirk
>
> On Fri, Mar 24, 2023 at 8:52 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi,
> >
> > I've noticed that we have the files mentioned on subject on the
> jspwiki-war
> > module? How are they
> > used? Are they meant to be incorporated on the maven build? We have a lot
> > of Dependabot PRs
> > and alerts regarding these files and I'm unsure on how to act on them.
> >
> >
> > thanks & best regards,
> > juan pablo
> >
>

gulpfile.js, package.json and package-lock.json at jspwiki-war?

[Juan Pablo Santos Rodríguez]

Hi,

I've noticed that we have the files mentioned on subject on the jspwiki-war
module? How are they
used? Are they meant to be incorporated on the maven build? We have a lot
of Dependabot PRs
and alerts regarding these files and I'm unsure on how to act on them.


thanks & best regards,
juan pablo

[DRAFT] 2023 Board report

[Juan Pablo Santos Rodríguez]

Hi,

Apologies for the rush, this quarter's board report reminder has not been
sent, so I wasn't aware we had to send our quarterly board report.

It's due today, so I'll wait until tonight to include any insights,
comments, or generally speaking anything I've should included but I've
missed.


Thx + best regards,
juan pablo

-- Forwarded message -
De: 
Date: mié, 11 ene 2023 13:57
Subject: [jspwiki-asf-docs] branch master updated: [DRAFT] 2023 Board report
To: comm...@jspwiki.apache.org 


This is an automated email from the ASF dual-hosted git repository.

juanpablo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/jspwiki-asf-docs.git


The following commit(s) were added to refs/heads/master by this push:
 new d15a770  [DRAFT] 2023 Board report
d15a770 is described below

commit d15a7703cb45c468d08f0425e04542342a543c59
Author: Juan Pablo Santos Rodríguez 
AuthorDate: Wed Jan 11 13:56:51 2023 +0100

[DRAFT] 2023 Board report
---
 board-reports/2023-01.txt | 32 
 1 file changed, 32 insertions(+)

diff --git a/board-reports/2023-01.txt b/board-reports/2023-01.txt
new file mode 100644
index 000..d2946ea
--- /dev/null
+++ b/board-reports/2023-01.txt
@@ -0,0 +1,32 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related
to
+Leading open source WikiWiki engine, feature-rich and built around
standard
+JEE components (Java, servlets, JSP).
+
+## Issues:
+There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (9 years ago)
+There are currently 14 committers and 8 PMC members in this project.
+The Committer-to-PMC ratio is 7:4.
+
+Community changes, past quarter:
+- No new PMC members. Last addition was Dave Koelmeyer on 2016-04-06.
+- No new committers. Last addition was Dave Koelmeyer on 2016-04-06.
+
+## Project Activity:
+Again, quiet period, as noted on the previous report, we have switched
+to 2.12.0, which requires JDK-11, upgraded some libraries, and we have
+fixed several XSS vulnerabilities present on some JSPWiki plugins,
+which will warrant a CVE.
+
+We got another vulnerability report, which was rejected.
+
+Last release was 2.11.3 on 2022-08-02.
+
+## Community Health:
+Traffic on both MLs had an increase compared with last quarter, most
+due to last quarter being an almost no activity quarter.
+
+There is enough people to provide project oversight.

Re: CategoryHierarchyPlugin

[Juan Pablo Santos Rodríguez]

Hi,

incredibly late, but somehow this got piled under a ton of other mails and
I missed it :-/

The plugin indeed seems interesting, would you like to send a PR to JSPWiki
with it? :-) some remarks on the code

- classes should contain the Apache License header
- package would need to change to org.apache.wiki.plugin
- displayed texts would need to be i18nized
- an associated unit test would be very nice


cheers,
juan pablo

On Sat, Sep 24, 2022 at 7:55 AM Gary Kephart  wrote:

> Here's a plugin I wrote that you might be interested in. It displays all
> of the categories on a site in a hierarchical format using "%%collapse".
> All it needs is the prefix that you use for categories, and it defaults
> that to "Category." like Wikipedia uses. Visit
> https://encyclopaedia-wot.org/Wiki.jsp?page=Special.Categories to see it
> in action.
>
> Gary
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to
> be governed by lesser men." -- Plato.
>

No more public Jira sign ups

[Juan Pablo Santos Rodríguez]

Hi,

As per https://blogs.apache.org/infra/entry/jira-public-signup-disabled
infra has locked public sign ups, so new accounts have to be requested via
ML. We'd probably want to requests a new ML for this, but for now I think
dev is fine.

Maybe is a good moment to reconsider GH issues instead? Leave current Jira
project as it is, and open new issues on GH? Jira would be still accessible
of course.

I think is pretty common these days to have a GH account, whereas having to
request for a new Jira account through a ML would be far from ideal (IMO).

Still, I don't have a strong opinion on this, so I'm eager to listen other
opinions.


Best regards,
juan pablo

p.s. I'll update the appropriate page over jspwiki-wiki.a.o through the
weekend; if anyone wants to update it before please feel free to do so O:-)

Re: [DRAFT] Board report for 2022/10

[Juan Pablo Santos Rodríguez]

Hi,

before sending the report, just added to it last release date (needed), and
a note on Murray's work on the his ReferenceManager implementation, and
reworked a bit the format on the community health section, hope's that ok


best regards,
juan pablo

On Tue, Oct 11, 2022 at 12:15 AM Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:

> Hi,
>
> please see attached draft for upcoming board report below. I plan to
> submit it by next wednesday, so any other comment, edit, etc. will be very
> welcome.
>
> kind regards,
> juan pablo
>
> -- Forwarded message -
> From: 
> Date: Tue, Oct 11, 2022 at 12:13 AM
> Subject: [jspwiki-asf-docs] branch master updated: [DRAFT] Board report
> for 2022/10
> To: comm...@jspwiki.apache.org 
>
>
> This is an automated email from the ASF dual-hosted git repository.
>
> juanpablo pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/jspwiki-asf-docs.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new f8f0202  [DRAFT] Board report for 2022/10
> f8f0202 is described below
>
> commit f8f0202699121e95d3499c580d4613ef9c5d6a91
> Author: Juan Pablo Santos Rodríguez 
> AuthorDate: Tue Oct 11 00:12:55 2022 +0200
>
> [DRAFT] Board report for 2022/10
> ---
>  board-reports/2022-10.txt | 36 
>  1 file changed, 36 insertions(+)
>
> diff --git a/board-reports/2022-10.txt b/board-reports/2022-10.txt
> new file mode 100755
> index 000..30027ba
> --- /dev/null
> +++ b/board-reports/2022-10.txt
> @@ -0,0 +1,36 @@
> +## Description:
> +The mission of JSPWiki is the creation and maintenance of software
> related to
> +Leading open source WikiWiki engine, feature-rich and built around
> standard
> +JEE components (Java, servlets, JSP).
> +
> +## Issues:
> +There are no issues requiring board attention.
> +
> +## Membership Data:
> +Apache JSPWiki was founded 2013-07-17 (8 years ago)
> +There are currently 14 committers and 8 PMC members in this project.
> +The Committer-to-PMC ratio is 7:4.
> +
> +Community changes, past quarter:
> +- No new PMC members. Last addition was Dave Koelmeyer on 2016-04-06.
> +- No new committers. Last addition was Dave Koelmeyer on 2016-04-06.
> +
> +## Project Activity:
> +Quiet two-month quarter, with no code merged into master. It was
> +discussed the need of upgrading JDK, so next release will be 2.12.0,
> +which will require JDK-11. This change should get into master by
> +the time of the Board meeting.
> +
> +We got one vulnerability report, done directly through github, which
> +was rejected. Still pending to reach the issuer so next reports do
> +get submitted through the appropiate channels.
> +
> +## Community Health:
> +Traffic on both MLs had a decrease compared with last quarter, most
> +probably due to being a quiet quarter. We got one plugin submitted
> +through dev@j.a.o, which should at least get uploaded to
> +jspwiki-wiki.a.o
> +
> +We have a handful of PRs awaiting to be merged.
> +
> +There is enough people to provide project oversight.
>
>

[DRAFT] Board report for 2022/10

[Juan Pablo Santos Rodríguez]

Hi,

please see attached draft for upcoming board report below. I plan to submit
it by next wednesday, so any other comment, edit, etc. will be very welcome.

kind regards,
juan pablo

-- Forwarded message -
From: 
Date: Tue, Oct 11, 2022 at 12:13 AM
Subject: [jspwiki-asf-docs] branch master updated: [DRAFT] Board report for
2022/10
To: comm...@jspwiki.apache.org 


This is an automated email from the ASF dual-hosted git repository.

juanpablo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/jspwiki-asf-docs.git


The following commit(s) were added to refs/heads/master by this push:
 new f8f0202  [DRAFT] Board report for 2022/10
f8f0202 is described below

commit f8f0202699121e95d3499c580d4613ef9c5d6a91
Author: Juan Pablo Santos Rodríguez 
AuthorDate: Tue Oct 11 00:12:55 2022 +0200

[DRAFT] Board report for 2022/10
---
 board-reports/2022-10.txt | 36 
 1 file changed, 36 insertions(+)

diff --git a/board-reports/2022-10.txt b/board-reports/2022-10.txt
new file mode 100755
index 000..30027ba
--- /dev/null
+++ b/board-reports/2022-10.txt
@@ -0,0 +1,36 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related
to
+Leading open source WikiWiki engine, feature-rich and built around
standard
+JEE components (Java, servlets, JSP).
+
+## Issues:
+There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (8 years ago)
+There are currently 14 committers and 8 PMC members in this project.
+The Committer-to-PMC ratio is 7:4.
+
+Community changes, past quarter:
+- No new PMC members. Last addition was Dave Koelmeyer on 2016-04-06.
+- No new committers. Last addition was Dave Koelmeyer on 2016-04-06.
+
+## Project Activity:
+Quiet two-month quarter, with no code merged into master. It was
+discussed the need of upgrading JDK, so next release will be 2.12.0,
+which will require JDK-11. This change should get into master by
+the time of the Board meeting.
+
+We got one vulnerability report, done directly through github, which
+was rejected. Still pending to reach the issuer so next reports do
+get submitted through the appropiate channels.
+
+## Community Health:
+Traffic on both MLs had a decrease compared with last quarter, most
+probably due to being a quiet quarter. We got one plugin submitted
+through dev@j.a.o, which should at least get uploaded to
+jspwiki-wiki.a.o
+
+We have a handful of PRs awaiting to be merged.
+
+There is enough people to provide project oversight.

Re: [GitHub] [jspwiki] juanpablo-santos commented on pull request #228: [SECURITY] Fix Partial Path Traversal Vulnerability

[Juan Pablo Santos Rodríguez]

Hi,

would appreciate some comments on this, either here or at GH. It's a strong
opinion but it's only my opinion, I'd welcome any other POV on how to
tackle this kind of issues, specially if you feel otherwise.


thx + best regards,
juan pablo

On Fri, Sep 23, 2022 at 11:32 PM GitBox  wrote:

>
> juanpablo-santos commented on PR #228:
> URL: https://github.com/apache/jspwiki/pull/228#issuecomment-1256697358
>
>Hi @JLLeitschuh,
>
>speaking for myself, **not** on behalf of the project, while most of
> the time I welcome any PR, I have to say that I find this kind of PRs
> disrespectful and irresponsible. Don't get me wrong, I appreciate your
> security concerns, but I sincerely think this is not the way.
>
>Sending bulk e-mails is very similar to how spam works. Furthermore,
> proposed code fix has been detected mass scaning OSS projects, without a
> check that indeed there is a vulnerability (details on this at the end of
> this comment). As a security researcher/whatever you are expected to do at
> least that. Every other vulnerability report that we have received has done
> that, so sending a security report without checking is somewhat
> disrepectful to other security researchers. How the vulnerability can be
> exploited is also a nice to have, so the people receiving your reports are
> able to fix the issue as fast as possible, but since you have gone the
> public way I suppose it is fine as it is.
>
>You say that you know/hope/think that there is a vulnerability, so you
> choose to disclose publicly because you don't have time to go to every
> project and check how do they manage these kind of issues. Please respect
> everybody else's time, which will probably be as scarce and valuable as
> yours, and play nice. Think of it as if part of your security research
> involves time on those tasks. Same for verifying whatever the tooling you
> use has found. Yes, you would probably not reach as many projects, but
> that's just a matter of quality over quantity. Also, since you are
> targetting GitHub projects, here's a hint: most of them contain a Security
> tab at the top of each repo with further instructions. For ASF projects,
> you can directly follow up with [these instructions](
> https://apache.org/security/); since there are more than 200 ASF
> projects, plus the incubating ones, surely that's worth automating.
>
>Really, full public disclosure does not help anyone: best case
> scenario, there isn't really a security vulnerability, and some mantainer
> will have to write back to someone who thinks that mass e-mailing projects
> is fine, after wasting his/her time looking if the report is really valid.
> Worst case scenario, let's say you find the next log4shell issue; I fail to
> see how it would be a good idea to publicly disclose that. Seriously. Don't
> blame lack of GH infrastructure and just be responsible. Doing otherwise is
> not cool.
>
>As for the proposed one line fix, there's a comparison between a path's
> file and a directory whose path can't be reached or managed by an end-user,
> so I can't see how the reported vulnerability could be exploited, nor the
> need to security-harden it. Would be nice if you could follow up with this,
> most preferably following [these guidelines](
> https://github.com/apache/jspwiki/security/policy).
>
>best regards,
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@jspwiki.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>

Re: Policy on matchEnglishPlurals?

[Juan Pablo Santos Rodríguez]

Hi,

I'd say you've found all the documentation that there is about that :-/
Basically if the jspwiki.translatorReader.matchEnglishPlurals property is
set to true, then pages ending with 's' are considered the same as their
singular form when linking between them. It does not prevent you from
having both kinds of pages - we fall back to the other one if the primary
name does not exist.

Although doing the work, is a bit naive, so it is recommended only for
english wikipages. Don't know if it would be worth implementing for a
custom ReferenceManager, or if it could be implemented with a more complex
logic or if it makes sense to mimic the same logic on the
DefaultReferenceManager..


cheers,
juan pablo

On Mon, Sep 19, 2022 at 10:22 AM Murray Altheim 
wrote:

> Hi,
>
> I'm struggling with the modifications necessary to implement a replacement
> ReferenceManager using a graph backend, and in a somewhat surprising place:
> namely, passing tests related to parsing plurals. I can kinda figure what
> is meant from the various tests, but overall I can't discern a policy on
> how to handle references to wiki page names, how to deal with page creates
> or updates in either direction of a singular-to-plural update, plural-to-
> singular, whether or not to consider an initial link to a singular or
> plural as to the same page, etc.  These kinds of questions can be seen in
> tests like testPluralSingularUpdate1, testPluralSingularUpdate2, and
> testPluralSingularUpdate3 in ReferenceManagerTest.
>
> Is there anywhere documented the actual policy on how to handle singular
> and plural wikiNames in either page names or links? I've only found the
> one paragraph in the properties file.
>
> Cheers,
>
> Murray
>
> ...
> Murray Altheim= =  ===
> 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
>
>

Re: Upgrading jdk requirement?

[Juan Pablo Santos Rodríguez]

Hiya!

been on holidays and with a lot of $dayjob after that, just wanted to close
this, so it doesn't slip through.
Let's say next version will be 2.12.0, instead of 2.11.4, and it will
require JDK-11? As for when to upgrade
the JDK requirement, let's just ask the question every minor release, if
it's reasonable to do so? Or the
other way round, when upgrading the JDK requirement, it would require
increasing at least a minor release?

As a side note, and completely agreeing with the reasons to upgrade to
JDK-11, my experience with JDK-17
has been very similar to what Murray expressed with JDK-11, cleaner and
less verbose code, as compared
with JDK-11; multiline strings, pattern matching, helpful NPEs, records,
etc. are little things that ease your
day to day, and that I've found missing when going back..


kind regards,
juan pablo

On Tue, Aug 9, 2022 at 5:36 PM Jürgen Weber  wrote:

> Actually I never understood the need for get/setters anyway (course I know
> the book). C++ got along well without.
>
> Cheers
>
> Murray Altheim  schrieb am Di., 9. Aug. 2022, 16:12:
>
> > On 2022/08/09 22:55, Jürgen Weber wrote:
> > > Java 11 would be OK. Not more. Enterprises are very conservative.
> >
> > Agreed, my current job is largely upgrading dozens and dozens of JDK 8
> > applications which have had no love for over a decade. I'm not so sure
> > if this is the result of being conservative so much as executive
> > management's typical desire to build New Things rather than maintain
> > Old Things, or possibly The World of Constant Emergencies.
> >
> > > Also, I do not see why a mature product like JSPWiki should be
> > > refactored to use newer Java features.
> > I'm not a fan of using new features simply because they're new, but I
> > have found some of the Java 11 features result in cleaner and less
> > verbose code, e.g., some of the streaming syntax removes a lot of lines
> > of boilerplate. This can be (like many things) abused and make things
> > harder to either read or understand, but on balance I've gotten used to
> > using many of the Java 11 features. Post JDK 11, I've found little of
> > real value so far.
> >
> > On one of my larger personal projects I experimented recently with
> > trying to back-date the code to JDK 8 and found that I'm very much a
> > Java 11 person now, as almost none of the classes compiled as I'd used
> > a lot of the new syntax.
> >
> > I've also previously suggested Lombok, which has for me become somewhat
> > of a standard for all new code*. It removes all the pointless getters and
> > setters, and with @Builder one effectively gets a DSL. Combining Lombok
> > with an enum class really cleans up a lot of ugly use of integer
> contants,
> > such as found in WikiPageEvent. I'd be happy to help out with migrating
> > to Java 11, simply to get rid of that kind of thing...
> >
> > Cheers,
> >
> > Murray
> >
> > * I really wish Lombok were adopted into the Java syntax itself.
> >
> ...
> > Murray Altheim= =
> ===
> > 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
> >
> >
>

Upgrading jdk requirement?

[Juan Pablo Santos Rodríguez]

Hi all,

As noted some days ago, may be out is time to upgrade the jdk requirement?
Currently we're on jdk8, which is quite behind current LTS, and given the
new jdk release cycle, it'll be easy to be in this situation again, so a
couple of questions:

- should we upgrade? To which jdk? Other than requiring an LTS, I'd be okay
with whatever we see fit.

- how often should we upgrade? Staying 1 or 2 lts behind? Every N releases?
Every minor (X.Y.0) release?


Best regards,
juan pablo

Re: ClassCastException on application reboot

[Juan Pablo Santos Rodríguez]

Hiya,

Given there's no jspwiki code in that stack trace, my guess would be either
a jspwiki serialization file has been serialized with one jdk and it's been
tried to be deserialized with another, or something similar with the JSPs
under Tomcat's work directory?

Maybe clearing tomcat's and/or jspwiki's work directory would make that
exception disappear?

Cheers,
juan pablo

El mar, 9 ago 2022 5:14, Murray Altheim  escribió:

> Hi,
>
> Also, just wondering if this has already been noted, if it's just me
> (possibly due to
> Oracle Java 11), or if this is a valid bug. If this is ignorable I'm fine
> with that,
> i.e., it's seemingly not affecting anything I'm doing.
>
> I'm running Ubuntu 22.04.1 LTS on an HP Envy laptop, Intel® Core™ i7-8550U
> CPU @ 1.80GHz × 8,
>
>   ► java -version
> java version "11.0.14" 2022-01-18 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.14+8-LTS-263)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.14+8-LTS-263, mixed
> mode)
>
> On restarting Tomcat I always see this stack trace in the logs:
>
> --  catalina.out stack trace  --
>
> [...]
> 09-Aug-2022 12:06:46.610 INFO [main]
> org.apache.catalina.core.StandardServer.await A valid shutdown command was
> received
> via the shutdown port. Stopping the Server instance.
> 09-Aug-2022 12:06:46.611 INFO [main]
> org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler
> ["http-nio-9627"]
> 09-Aug-2022 12:06:46.613 INFO [main]
> org.apache.catalina.core.StandardService.stopInternal Stopping service
> [Catalina]
> 09-Aug-2022 12:06:46.617 WARNING [main]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches
> Failed to clear soft references
> from ObjectStreamClass$Caches for web application [ROOT]
> java.lang.ClassCastException: class
> java.io.ObjectStreamClass$Caches$1 cannot be cast to class java.util.Map
> (java.io.ObjectStreamClass$Caches$1 and java.util.Map are in module
> java.base of loader 'bootstrap')
> at
> org.apache.catalina.loader.WebappClassLoaderBase.clearCache(WebappClassLoaderBase.java:2325)
> at
>
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches(WebappClassLoaderBase.java:2300)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1669)
> at
> org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1597)
> at
> org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:463)
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at
> org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5515)
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at
> org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1412)
> at
> org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1401)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:986)
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at
> org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1412)
> at
> org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1401)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:986)
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at
> org.apache.catalina.core.StandardService.stopInternal(StandardService.java:497)
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at
> org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:979)
> at
> org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at
> org.apache.catalina.startup.Catalina.stop(Catalina.java:849)
> at
> org.apache.catalina.startup.Catalina.start(Catalina.java:811)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>   

[DRAFT] 2022-08 Board report

[Juan Pablo Santos Rodríguez]

Hi,

please see attached draft for comments, edits, reviews, etc. My intention
is to submit the report by next Thursday/Friday.


Cheers,
juan pablo

-- Forwarded message -
De: 
Date: mar, 9 ago 2022 14:40
Subject: [jspwiki-asf-docs] branch master updated: [DRAFT] 2022-08 Board
report
To: comm...@jspwiki.apache.org 


This is an automated email from the ASF dual-hosted git repository.

juanpablo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/jspwiki-asf-docs.git


The following commit(s) were added to refs/heads/master by this push:
 new 4ad107b  [DRAFT] 2022-08 Board report
4ad107b is described below

commit 4ad107ba7bbb56632a7ac9f7d224efde612af95e
Author: Juan Pablo Santos Rodríguez 
AuthorDate: Tue Aug 9 14:40:12 2022 +0200

[DRAFT] 2022-08 Board report
---
 board-reports/2022-08.txt | 41 +
 1 file changed, 41 insertions(+)

diff --git a/board-reports/2022-08.txt b/board-reports/2022-08.txt
new file mode 100644
index 000..ba4a58e
--- /dev/null
+++ b/board-reports/2022-08.txt
@@ -0,0 +1,41 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related
to
+Leading open source WikiWiki engine, feature-rich and built around
standard
+JEE components (Java, servlets, JSP).
+
+## Issues:
+There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (8 years ago)
+There are currently 14 committers and 8 PMC members in this project.
+The Committer-to-PMC ratio is 7:4.
+
+Community changes, past quarter:
+- No new PMC members. Last addition was Dave Koelmeyer on 2016-04-06.
+- No new committers. Last addition was Dave Koelmeyer on 2016-04-06.
+
+## Project Activity:
+JSPWiki 2.11.3 was released on Aug, 2nd, featuring complete wiki
+syntax pluggability, allowing full Markdown support (except for
+some pending quirks) and Engine Extensions, which allow easier
+integration of 3rd party libraries. Also, 2.11.3 contained fixes
+For 5 CVEs. Work on 2.11.3 has had a slow pace of development,
+but nothing unexpected.
+
+Finally, we got looked into another vulnerability report, which
+was rejected.
+
+## Community Health:
+Traffic on both MLs had an increase compared with last quarter,
+most probable due to 2.11.3 release, and an emeritus pmc member
+coming back to dev@j.a.o
+
+We merged a handful of PRs from a contributor which contained
+code improvements.
+
+2.11.3 release vote showed a couple of community votes, which
+is rather unusual, so we'll keep an eye for future committer/PMC
+members.
+
+There is enough people to provide project oversight.

Re: Is 2.11.3 a drop-in replacement for 2.11.2?

[Juan Pablo Santos Rodríguez]

Hi Murray,

there's also a jspwiki-http (IIRC) artifact which contains the csrf filter.
It's completely pluggable, so if you don't include it, everything will
continue same as before, it'll be safe to upgrade the jars.

However, if you do include it, both JSPs and js files should be upgraded
too (and browser cache cleared).


HTH,
juan pablo

El mar, 9 ago 2022 4:50, Murray Altheim  escribió:

> Hi,
>
> Hopefully a quick question: I've got a local wiki based on the "department
> wiki" distributed with JSPWiki Portable that I use for both personal stuff
> and testing my developments, and I was wondering if I can just drop the
> new 2.11.3 jar files in place of the 2.11.2 files in jspwiki/lib/:
>
>jspwiki-210-adapters-2.11.2.jar
>jspwiki-api-2.11.2.jar
>jspwiki-bootstrap-2.11.2.jar
>jspwiki-cache-2.11.2.jar
>jspwiki-event-2.11.2.jar
>jspwiki-kendra-searchprovider-2.11.2.jar
>jspwiki-main-2.11.2.jar
>jspwiki-markdown-2.11.2.jar
>jspwiki-util-2.11.2.jar
>
> or if there's any dependency or JSP changes that would be required for
> compatibility. I'd prefer not having to rebuild that deployment if it's
> unnecessary as it took quite a lot of time to set up.
>
> Thanks,
>
> Murray
>
> ...
> Murray Altheim= =  ===
> 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
>
>

Re: LinkParsingOperations improvements?

[Juan Pablo Santos Rodríguez]

Hi Murray,

(apologies for the brevity, is really late in here, and won't be
having too much time next few days..)

I extracted the LinkParserOperations to be able to reuse it when
developing other parsers; f.ex., you can see it also at the
MarkdownParser [#1], and at the LinkTag custom tag [#2] or inside the
LinkParser class [#3]. At the time of extracting the operations I went
with the Context b/c I didn't knew if I was to need something other
than the Engine, so going with the Context made more sense to me. In
order to not break other code using it (if ti exists at all), we could
overload those methods so they could also receive an Engine? As for
the StartingComparator, it's a private static class, so it's only used
inside the LinkParserOperations. Probably it was a private static lass
inside the JSPWikiMarkupParser, but moved with the
LinkParserOperations class when it was extracted. Agree with the
linkExists/linkIfExists refactor, don't remember why I didn't that on
the first place :-?

As for making it static, the objects should be freed as soon as you
exit from the block they're created, so garbage collection-wise, they
shouldn't impact on the application. Usually I'm not a big fan of
static methods, as they're usually harder to test.. not in this case,
but usually. Not knowing how would the class take shape, I went the
safe way with creating a new object, and then left it that way once it
was done: memory footprint should also be neligible, so making it
static seemed to me like making only for the sake of it, so I didn't
bother too much then.

Hope this makes a bit clearer the intent of that class :-)

best regards,
juan pablo

[#1]: 
https://github.com/apache/jspwiki/blob/2.11.3/jspwiki-markdown/src/main/java/org/apache/wiki/markdown/extensions/jspwikilinks/attributeprovider/ExternalLinkAttributeProviderState.java#L63
[#2]: 
https://github.com/apache/jspwiki/blob/2.11.3/jspwiki-main/src/main/java/org/apache/wiki/tags/LinkTag.java#L192
[#3]: 
https://github.com/apache/jspwiki/blob/2.11.3/jspwiki-main/src/main/java/org/apache/wiki/parser/LinkParser.java#L473

On Thu, Aug 4, 2022 at 1:19 PM Murray Altheim  wrote:
>
> Hi,
>
> As I've been digging around in the code related to the ReferenceManager,
> I found a curiosity.
>
> I'm not sure of the history surrounding LinkParsingOperations, but it
> seems that we create an instance for every WikiContext, despite the
> fact that both of the two methods that use it actually use it just to
> obtain the WikiEngine. The other eight methods could be static, and
> there's a StartingComparator inner static class that's not actually
> used anywhere else in code so it could be removed (so far as I can see).
>
> The linkIfExists(String) and linkExists(String) methods both do almost
> the same thing, so in theory the latter could simply call the former to
> obtain its boolean result.
>
> Since all the places where these two methods are called (all are within
> JSPWikiMarkupParser) have access to the WikiEngine it could be passed
> in as an argument, and therefore all of the methods of the
> LinkParsingOperations could be made static and turn this into a static
> utility class.
>
> There's clearly no urgency for this but it does seem like we could reduce
> the number of objects created by adopting the above suggestions.
>
> Cheers,
>
> Murray
>
> ...
> Murray Altheim= =  ===
> 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
>

CVE-2022-34158: Apache JSPWiki: User Group Privilege Escalation

[Juan Pablo Santos Rodríguez]

Severity: critical

Description:

A carefully crafted invocation on the Image plugin could trigger an CSRF 
vulnerability on Apache JSPWiki, which could allow a group privilege escalation 
of the attacker's account. Further examination of this issue established that 
it could also be used to modify the email associated with the attacked account, 
and then a reset password request from the login page. 

Mitigation:

Apache JSPWiki users should upgrade to 2.11.3 or later. 

Credit:

This issue was discovered by Huiseong Seo (t0rchwo0d), 

References:

https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-34158

CVE-2022-28732: Apache JSPWiki Cross-site scripting vulnerability on WeblogPlugin

[Juan Pablo Santos Rodríguez]

Severity: moderate

Description:

A carefully crafted request on WeblogPlugin could trigger an XSS vulnerability 
on Apache JSPWiki, which could allow the attacker to execute javascript in the 
victim's browser and get some sensitive information about the victim. 

Mitigation:

Apache JSPWiki users should upgrade to 2.11.3 or later. 

Credit:

This issue was discovered by Wang Ran, from JDArmy, @jd.com 

References:

https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732

CVE-2022-28731: Apache JSPWiki CSRF in UserPreferences.jsp

[Juan Pablo Santos Rodríguez]

Severity: critical

Description:

A carefully crafted request on UserPreferences.jsp could trigger an CSRF 
vulnerability on Apache JSPWiki, which could allow the attacker to modify the 
email associated with the attacked account, and then a reset password request 
from the login page. 

Mitigation:

Apache JSPWiki users should upgrade to 2.11.3 or later. Installations >= 2.7.0 
can also enable user management workflows' manual approval to mitigate the 
issue. 

Credit:

This issue was discovered by Fabrice Perez,  

References:

https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732

CVE-2022-28730: Apache JSPWiki Cross-site scripting vulnerability on AJAXPreview.jsp

[Juan Pablo Santos Rodríguez]

Severity: moderate

Description:

A carefully crafted request on AJAXPreview.jsp could trigger an XSS 
vulnerability on Apache JSPWiki, which could allow the attacker to execute 
javascript in the victim's browser and get some sensitive information about the 
victim.

This vulnerability leverages CVE-2021-40369, where the Denounce plugin 
dangerously renders user-supplied URLs. Upon re-testing CVE-2021-40369, it 
appears that the patch was incomplete as it was still possible to insert 
malicious input via the Denounce plugin. 

Mitigation:

Apache JSPWiki users should upgrade to 2.11.3 or later. 

Credit:

This issue was discovered by Poh Jia Hao, from Star Labs 

References:

https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732

CVE-2022-27166: Apache JSPWiki: XSS vulnerability on XHRHtml2Markup.jsp in JSPWiki 2.11.2

[Juan Pablo Santos Rodríguez]

Severity: moderate

Description:

A carefully crafted request on XHRHtml2Markup.jsp could trigger an XSS 
vulnerability on Apache JSPWiki, which could allow the attacker to execute 
javascript in the victim's browser and get some sensitive information about the 
victim

Credit:

Issue was discovered by Salt, 

References:

https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732

[ANNOUNCE] Apache JSPWiki 2.11.3 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki
2.11.3.

This is the fourth release on the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.3

The full change log is available here:
https://issues.apache.org/jira/browse/JSPWIKI/fixforversion/12351386

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/


The Apache JSPWiki Team

Re: svn commit: r56073 [1/2] - in /release/jspwiki: 2.11.2/ 2.11.3/ 2.11.3/binaries/ 2.11.3/binaries/portable/ 2.11.3/binaries/webapp/ 2.11.3/source/ 2.11.3/wikipages/

[Juan Pablo Santos Rodríguez]

Whew! bullet dogded then :-)

Re. the wrong redirection, the csrf filter redirects to
/error/Forbidden.html, which should take into account the application's
context path, but may be there are some cases this is not true? If you have
located when/where this happens I could also take a look on it


cheers,
juan pablo


El mié, 3 ago 2022 7:28, Dirk Frederickx 
escribió:

> Juan,
>
> Txs.  Indeed, clearing the browser cache solved the problem ;-)
> OK to proceed with the release.
>
> I'll do some further investigation because my local install doesn't work.
> (issue with  the URL resolution on the  response.sendRedirect)
>
> dirk
>
>
> On Wed, Aug 3, 2022 at 12:54 AM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi Dirk,
> >
> > I've committed to the release area and released the repo from staging, so
> > most probably they're on central now. F.ex.,
> > https://repo1.maven.org/maven2/org/apache/jspwiki/jspwiki-api/2.11.3/ is
> > already available and probably syncing to other mirrors.
> >
> > I had similar issues when editing the curated changelog after the
> [RESULT]
> > mail, and the preview pane wasn't showing up, but thought it was related
> to
> > ACLs. Luckily, refreshing the browser's cache seems to fix the issue, and
> > have been able to get the quick search pop-up, proper preview render,
> etc.
> > Latest release did change the js files in order to send the
> csrf-protection
> > field in every ajaxed post request (unless I've missed a few), so
> there's a
> > chance that is what's happening? There are integration tests for edit and
> > quick-searches, and they're both passing at my local (they helped a lot
> > when developing the csrf filter), but if there's an issue then we'll have
> > to run like hell to fix that and release 2.11.4 ASAP. I don't know if
> > there's a procedure to deal with botched releases, but that's what I'd
> do..
> > Would you mind checking if it is caching issue?
> >
> > thanks + best regards,
> > juan pablo
> >
> >
> > El mié, 3 ago 2022 0:11, Dirk Frederickx 
> > escribió:
> >
> > > Juan,
> > >
> > > Is it possible to hold the release?
> > >
> > > There seems to be something broken,  I assume related to the CSRF
> fixes.
> > >
> > > On https://jspwiki-wiki.apache.org/  you get a JS error when entering
> > > something in the quick-search menu.
> > > (Uncaught SyntaxError: Unexpected token < in JSON at position 0 )
> > > I seems like the AJAX requests get blocked.
> > > (same problem with other AJAX requests,  eg when using %%category)
> > >
> > >
> > > On my local install, I do not get that JS error.  Instead,  I see the
> > AJAX
> > > calls get redirected to the Forbidden.html.
> > > But there is a problem with  the generated url used in ::
> > > response.sendRedirect( "/error/Forbidden.html" );
> > >
> > >
> > > Unfortunately, I have no time now to further investigate.
> > >
> > > dirk
> > >
> > >
> > > On Tue, Aug 2, 2022 at 11:24 PM  wrote:
> > >
> > > > Author: juanpablo
> > > > Date: Tue Aug  2 21:24:47 2022
> > > > New Revision: 56073
> > > >
> > > > Log:
> > > > 2.11.3 release
> > > >
> > > > Added:
> > > > release/jspwiki/2.11.3/
> > > > release/jspwiki/2.11.3/binaries/
> > > > release/jspwiki/2.11.3/binaries/portable/
> > > >
> > > >
> > >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.tar.gz
> > > >  (with props)
> > > >
> > > >
> > >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.tar.gz.asc
> > > >  (with props)
> > > >
> > > >
> > >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.tar.gz.sha512
> > > >  (with props)
> > > >
> > > >
> > release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.zip
> > > >  (with props)
> > > >
> > > >
> > >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.zip.asc
> > > >  (with props)
> > > >
> > > >
> > >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.zip.sha512
> > > >  (with props)
> > > > rele

Re: svn commit: r56073 [1/2] - in /release/jspwiki: 2.11.2/ 2.11.3/ 2.11.3/binaries/ 2.11.3/binaries/portable/ 2.11.3/binaries/webapp/ 2.11.3/source/ 2.11.3/wikipages/

[Juan Pablo Santos Rodríguez]

Hi Dirk,

I've committed to the release area and released the repo from staging, so
most probably they're on central now. F.ex.,
https://repo1.maven.org/maven2/org/apache/jspwiki/jspwiki-api/2.11.3/ is
already available and probably syncing to other mirrors.

I had similar issues when editing the curated changelog after the [RESULT]
mail, and the preview pane wasn't showing up, but thought it was related to
ACLs. Luckily, refreshing the browser's cache seems to fix the issue, and
have been able to get the quick search pop-up, proper preview render, etc.
Latest release did change the js files in order to send the csrf-protection
field in every ajaxed post request (unless I've missed a few), so there's a
chance that is what's happening? There are integration tests for edit and
quick-searches, and they're both passing at my local (they helped a lot
when developing the csrf filter), but if there's an issue then we'll have
to run like hell to fix that and release 2.11.4 ASAP. I don't know if
there's a procedure to deal with botched releases, but that's what I'd do..
Would you mind checking if it is caching issue?

thanks + best regards,
juan pablo


El mié, 3 ago 2022 0:11, Dirk Frederickx 
escribió:

> Juan,
>
> Is it possible to hold the release?
>
> There seems to be something broken,  I assume related to the CSRF fixes.
>
> On https://jspwiki-wiki.apache.org/  you get a JS error when entering
> something in the quick-search menu.
> (Uncaught SyntaxError: Unexpected token < in JSON at position 0 )
> I seems like the AJAX requests get blocked.
> (same problem with other AJAX requests,  eg when using %%category)
>
>
> On my local install, I do not get that JS error.  Instead,  I see the AJAX
> calls get redirected to the Forbidden.html.
> But there is a problem with  the generated url used in ::
> response.sendRedirect( "/error/Forbidden.html" );
>
>
> Unfortunately, I have no time now to further investigate.
>
> dirk
>
>
> On Tue, Aug 2, 2022 at 11:24 PM  wrote:
>
> > Author: juanpablo
> > Date: Tue Aug  2 21:24:47 2022
> > New Revision: 56073
> >
> > Log:
> > 2.11.3 release
> >
> > Added:
> > release/jspwiki/2.11.3/
> > release/jspwiki/2.11.3/binaries/
> > release/jspwiki/2.11.3/binaries/portable/
> >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.tar.gz
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.tar.gz.asc
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.tar.gz.sha512
> >  (with props)
> >
> > release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.zip
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.zip.asc
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/portable/jspwiki-portable-2.11.3-woas.zip.sha512
> >  (with props)
> > release/jspwiki/2.11.3/binaries/webapp/
> > release/jspwiki/2.11.3/binaries/webapp/JSPWiki-sources.jar   (with
> > props)
> > release/jspwiki/2.11.3/binaries/webapp/JSPWiki-sources.jar.asc
>  (with
> > props)
> > release/jspwiki/2.11.3/binaries/webapp/JSPWiki-sources.jar.sha512
> >  (with props)
> > release/jspwiki/2.11.3/binaries/webapp/JSPWiki.war   (with props)
> > release/jspwiki/2.11.3/binaries/webapp/JSPWiki.war.asc   (with props)
> > release/jspwiki/2.11.3/binaries/webapp/JSPWiki.war.sha512   (with
> > props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3-javadoc.jar
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3-javadoc.jar.asc
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3-javadoc.jar.sha512
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3-sources.jar
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3-sources.jar.asc
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3-sources.jar.sha512
> >  (with props)
> >
> > release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3.jar
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3.jar.asc
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-adapters-2.11.3.jar.sha512
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-test-adaptees-2.11.3-sources.jar
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-test-adaptees-2.11.3-sources.jar.asc
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-test-adaptees-2.11.3-sources.jar.sha512
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-test-adaptees-2.11.3-tests.jar
> >  (with props)
> >
> >
> release/jspwiki/2.11.3/binaries/webapp/jspwiki-210-test-adaptees-2.11.3-tests.jar.asc
> >  (with props)
> >

[RESULT][VOTE] Release JSPWiki version 2.11.3

[Juan Pablo Santos Rodríguez]

Hi,

+72 hours passed, we have 5 +1 votes
- Arturo Bernal
- Dirk Frederickx*
- Harry Metske*
- Murray Altheim
- Juan Pablo Santos*
(* denoting PMC binding vote)

so the vote passes :-) I'll proceed with the release

There are a couple of post release actions:
- fix missing AL headers, there's already a PR for that
- investigate Oracle JDK builds breaking the build

Thanks to everyone that voted!

cheers,
juan pablo

On Mon, Aug 1, 2022 at 10:24 PM Arturo Bernal
 wrote:

> [x] +1 Release these artifacts
>
> Building OK from tag, with `clean test install`, ´cobertura:cobertura´,
> javadoc:javadoc  targets.
>
> Testing git tag on macOS 12.5 (21.6.0 Darwin Kernel Version 21.6.0: Sat
> Jun 18 17:07:25 PDT 2022; root:xnu-8020.140.41~1/RELEASE_X86_64 x86_64)
> with Java 8, 11, and 17.
>
>
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /opt/apache-maven-3.8.1
> Java version: 1.8.0_275, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /opt/apache-maven-3.8.1
> Java version: 11.0.5, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-11.0.5.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
>
>
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Maven home: /opt/apache-maven-3.8.1
> Java version: 17.0.2, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.5", arch: "x86_64", family: “mac"
>
>
> The mvn apache-rat:check  target fail. There are some files without
> licenses.
>
>
>
> Arturo Bernal
> arturobern...@yahoo.com
>
>
>
> > On 1 Aug 2022, at 15:23, Murray Altheim  wrote:
> >
> > For completeness' sake I installed what seemed to be the missing dev
> > libraries:
> >
> >  libxext-dev
> >  libxrender-dev
> >  libxtst-dev
> >
> > based on:
> >
> >
> https://stackoverflow.com/questions/29741518/error-libxext-so-6-cannot-open-shared-object-file-no-such-file-or-directory
> >
> > ...and tried again to build with Oracle's JDK, this using Ubuntu 22.04.1
> LTS
> > running on an Intel® Core™ i7-8550U CPU @ 1.80GHz × 8 with 16GB memory
> (an
> > HP Envy laptop).
> >
> > The build *still* fails on the Tika module, same stack trace. I'm not
> willing
> > to go down this rabbit hole any further, so end of that story.
> >
> > But going back to OpenJDK 8 I did another successful build, and can
> confirm
> > that the earlier problem was entirely Larry Ellison's fault.
> >
> > Cheers,
> >
> > Murray
> >
> > 
> >
> > FYI, I'm not sure if this is relevant since this isn't our project's
> fault but
> > thought you might be interested to see the warnings:
> >
> > [INFO]
> > [INFO] ---< org.apache.jspwiki:jspwiki-tika-searchprovider
> >---
> > [INFO] Building Apache JSPWiki Tika Search provider 2.11.3
> [22/35]
> > [INFO] [ jar
> ]-
> > [INFO]
> > [INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @
> jspwiki-tika-searchprovider ---
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:3.1.0:enforce (enforce-maven-version) @
> jspwiki-tika-searchprovider ---
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:3.1.0:enforce (enforce-java-version) @
> jspwiki-tika-searchprovider ---
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:3.1.0:enforce (enforcer-validations) @
> jspwiki-tika-searchprovider ---
> > [INFO]
> > [INFO] --- maven-remote-resources-plugin:3.0.0:process
> (process-resource-bundles) @ jspwiki-tika-searchprovider ---
> > [INFO] Preparing remote bundle org.apache:apache-jar-resource-bundle:1.4
> > [INFO] Copying 3 resources from 1 bundle.
> > [WARNING] Failed to build parent project for
> commons-codec:commons-codec:jar:1.15
> > [WARNING] Invalid project model for artifact
> [commons-codec:commons-codec:1.15]. It will be ignored by the remote
> resources Mojo.
> > [WARNING] Failed to build parent project for
> commons-io:commons-io:jar:2.11.0
> > [WARNING] Invalid project model for artifact
> [commons-io:commons-io:2.11.0]. It will be ignored by the remote resources
> Mojo.
> > [WARNING] Failed to build parent project for
> org.apache.logging.log4j:log4j-api:jar:2.18.0
> > [WARNING] Invalid project model for artifact
> [log4j-api:org.apache.logging.log4j:2.18.0]. It will be ignored by the
> remote resources Mojo.
> > [WARNING] Failed to build parent project for
> org.apache.commons:commons-lang3:jar:3.12.0
> > [WARNING] Invalid project model for artifact
> [commons-lang3:org.apache.commons:3.12.0]. It will be ignored by the remote
> resources Mojo.
> > [WARNING] Failed to build parent project for
> 

Re: [VOTE] Release JSPWiki version 2.11.3

[Juan Pablo Santos Rodríguez]

Hi Murray,

Would you mind sharing the stacktrace with the error? JSPWiki is
successfully building with jdk-8, jdk-11 and jdk-17 at
https://ci-builds.apache.org/job/JSPWiki/job/ci/job/master (mvn clean
package for jdks 11 & 17, the same + sonarqube analysis for jdk-8).


Thx in advance,
juan pablo


El lun, 1 ago 2022 12:14, Murray Altheim  escribió:

> -1 or -1 or -1. Explanation follows...
>
> I didn't have Java 8 installed on the laptop I have with me (I'm in Japan,
> not
> at home in New Zealand), so I tried building it with Java 11 first:
>
>   ► java -version
> java version "11.0.14" 2022-01-18 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.14+8-LTS-263)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.14+8-LTS-263, mixed
> mode)
>
> 1st try:
>
> ...
> [INFO] Apache JSPWiki AWS Kendra Search provider .. SUCCESS [
> 11.955 s]
> [INFO] Apache JSPWiki test extensions not using public api  SUCCESS [
> 0.517 s]
> [INFO] Apache JSPWiki adapters for pre-public api . SUCCESS [
> 2.446 s]
> [INFO] Apache JSPWiki Main War  FAILURE [
> 43.885 s]
> [INFO] Apache JSPWiki portable  SKIPPED
> [INFO] jspwiki-it-builder . SKIPPED
>
> 2nd try:
>
> ...
> [INFO] Apache JSPWiki AWS Kendra Search provider .. SUCCESS [
> 4.328 s]
> [INFO] Apache JSPWiki test extensions not using public api  SUCCESS [
> 0.813 s]
> [INFO] Apache JSPWiki adapters for pre-public api . SUCCESS [
> 3.025 s]
> [INFO] Apache JSPWiki Main War  FAILURE [
> 44.743 s]
> [INFO] Apache JSPWiki portable  SKIPPED
> [INFO] jspwiki-it-builder . SKIPPED
>
>
> Then I built jspwiki-main on its own successfully and "mvn install test
> -rf"'d
> from there, with this failure:
>
> ...
> [INFO] Apache JSPWiki Main War  SUCCESS [
> 40.523 s]
> [INFO] Apache JSPWiki portable  FAILURE [
> 10.504 s]
> [INFO] jspwiki-it-builder . SKIPPED
> [INFO] jspwiki-selenide-tests . SKIPPED
>
> ...so: I'm not finding this very stable in Java 11. There were a ton of
> warnings
> but ultimately I wasn't able to build it in one go.
>
> Summary #1: Now, I realise before that JSPWiki is a Java 8 application. If
> it's
> meant to be buildable using Java 11, then I must vote -1. But maybe that's
> not
> fair.
>
> So, I went ahead and installed Java 8:
>
>   ► java -version
> java version "1.8.0_202"
> Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
> Java HotSpot(TM) Server VM (build 25.202-b08, mixed mode)
>
> But failed again on the build (with a new terminal):
>
> ...
> [INFO] Apache JSPWiki markdown support  SUCCESS [
> 8.529 s]
> [INFO] Apache JSPWiki Tika Search provider  FAILURE [
> 6.852 s]
> [INFO] Apache JSPWiki AWS Kendra Search provider .. SKIPPED
> [INFO] Apache JSPWiki test extensions not using public api  SKIPPED
>
> Summary #2: so, even with Java 8 installed I wasn't able to build JSPWiki,
> with
> just "mvn install test" from the download.
>
> I tried yet a third time with Java 8 but am still failing when trying to
> build
> jspwiki-tika-searchprovider. :-(
>
> Cheers,
>
> Murray
>
> On 2022/08/01 17:29, Harry Metske wrote:
> > +1
> >
> > On Sat, 30 Jul 2022 at 14:58, Juan Pablo Santos Rodríguez <
> > juanpa...@apache.org> wrote:
> >
> >> This is a release vote for Apache JSPWiki, version 2.11.3. The vote
> will be
> >> open for at least 72 hours from now.
> >>
> >> It fixes the following issues:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351386
> >>
> >> You can see a curated changelog at
> >> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
> >>
> >> Note that we are voting upon the source (tag), binaries are provided for
> >> convenience.
> >>
> >> Everybody is encouraged to vote.
> >>
> >> Source and binary files:
> >> https://dist.apache.org/repos/dist/dev/jspwiki/2.11.3-RC1
> >>
> >> Nexus staging repo:
> >>
> https://repository.apache.org/content/repositories/orgapachejspwiki-1028
> >>
> >> The tag to be voted upon:
> >> https://github.com/apache/jspwiki/tree/2.11.3-RC1
> >>
> >> JSPWiki's KEYS file containing PGP keys we use to sign the release:
> 

Re: [VOTE] Release JSPWiki version 2.11.3

[Juan Pablo Santos Rodríguez]

and my +1

cheers,
juan pablo

On Sat, Jul 30, 2022 at 2:58 PM Juan Pablo Santos Rodríguez <
juanpa...@apache.org> wrote:

> This is a release vote for Apache JSPWiki, version 2.11.3. The vote will
> be open for at least 72 hours from now.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351386
>
> You can see a curated changelog at
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Everybody is encouraged to vote.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jspwiki/2.11.3-RC1
>
> Nexus staging repo:
> https://repository.apache.org/content/repositories/orgapachejspwiki-1028
>
> The tag to be voted upon:
> https://github.com/apache/jspwiki/tree/2.11.3-RC1
>
> JSPWiki's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/jspwiki/KEYS
>
> *** Please download, test and vote:
>
> [ ] +1 Approve the release
> [ ]  0 Don't mind
> [ ] -1 Disapprove the release (please provide specific comments)
>

[VOTE] Release JSPWiki version 2.11.3

[Juan Pablo Santos Rodríguez]

This is a release vote for Apache JSPWiki, version 2.11.3. The vote will be
open for at least 72 hours from now.

It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351386

You can see a curated changelog at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

Note that we are voting upon the source (tag), binaries are provided for
convenience.

Everybody is encouraged to vote.

Source and binary files:
https://dist.apache.org/repos/dist/dev/jspwiki/2.11.3-RC1

Nexus staging repo:
https://repository.apache.org/content/repositories/orgapachejspwiki-1028

The tag to be voted upon:
https://github.com/apache/jspwiki/tree/2.11.3-RC1

JSPWiki's KEYS file containing PGP keys we use to sign the release:
https://www.apache.org/dist/jspwiki/KEYS

*** Please download, test and vote:

[ ] +1 Approve the release
[ ]  0 Don't mind
[ ] -1 Disapprove the release (please provide specific comments)

Re: GraphReferenceManager

[Juan Pablo Santos Rodríguez]

Hi Murray,

Just a quick note, current wiki syntax allows a second | in order to
support link attributes, e.g., [Page|MyPage|title='Page']. Markdown syntax
allows the same thing using [](){}, IIRC, so perhaps
[Subject|Predicate::Object] (or something like that) could be used instead?


cheers,
juan pablo


El vie, 29 jul 2022 4:39, Murray Altheim  escribió:

> On 2022/07/29 6:01, Juan Pablo Santos Rodríguez wrote:
> > Hi Murray,
> >
> > ahh ok, now I see, so I guess we could start by making the reference
> > manager pluggable through a wiki property, so anyone wishing to use it
> can
> > do so easily.
>
> Hi Juan Pablo,
>
> The one pseudo-proposal I'm considering adding to the syntax would be to
> support normal intra-wiki links, but also optionally permit a second
> vertical bar character '|' to create a triple/tuple, e.g.:
>
>  [Subject|Predicate|Object]
>
> so that one could type a link to a page using another page. E.g.,
>
> [ThisPage|IsPreviousToPage|ThatPage]
> [ThatPage|HasPreviousPage|ThisPage]
> [ThisPage|HasParentPage|ThatPage]
> [ThisPage|HasCategory|ThatPage]
> [ErnestHemingway|IsA|Writer]
> [TheCat|SitsOn|TheMat]
>
> I did something similar back around 2005 with a wiki plugin that did
> exactly this, but with this proposal it'd be integrated as link syntax
> rather than as a plugin.
>
> This allows you to make a relationship between two pages (or a page and an
> external URL) that is typed by another page. That predicate page could in
> theory (in my system it always is) part of a predicate hierarchy. But I
> won't lead the team down that ontological rabbit hole. But for a teaser,
> one could create the predicates for first order predicate logic and begin
> to make statements between wiki pages (as "Terms) that describe what they
> mean. [This was part of the core of my unfinished Ph.D. work at that time.]
>
> So taking Cyc's definition of its 'genls' (inheritance) predicate:
>
>(isa genls TransitiveBinaryPredicate)
>(isa genls ReflexiveBinaryPredicate)
>(arg1Isa genls Collection)
>(arg2Isa genls Collection)
>(arg1Genl genls Thing)
>(arg2Genl genls Thing)
>
> one could express that as wiki pages with only minor syntactical changes:
>
>[IsA|Genls|TransitiveBinaryPredicate]
>[IsA|Genls|ReflexiveBinaryPredicate]
>[Arg1Isa|Genls|Collection]
>[Arg2Isa|Genls|Collection]
>[Arg1Genl|Genls|Thing]
>[Arg2Genl|Genls|Thing]
>
> But like I said, I won't go any further down that rabbit hole.
>
> > Setting aside when to switch to JDK-11 (or whatever version we see fit),
> > the graphmanager could be compiled with Java 11, having the rest of the
> > project compiling with Java 8. The markdown module has been in a similar
> > situation in the past, where it has been compiling with Java 8, and the
> > rest of the project with Java 6 or 7, so that shouldn't be a stopper..
> >
> > As for the number of pages, jspwiki-wiki has almost 400 pages, but there
> > are other wikis out there with higher number of pages; f.ex.,
> > https://encyclopaedia-wot.org has almost 4000 pages,
> > https://www.ecyrd.com/ButtUgly/wiki has around 3200 and
> http://ldapwiki.com/
> > almost 16400
>
> That probably shouldn't be an issue. I've got a test corpus of around 1200
> files that I could copy a few times to do a test at the 16K level and find
> out how long things take to process. I would be interested in knowing if
> there are any stats for that 16400 page wiki I could compare with...  The
> ingest/accession (import/process metadata) on 1200 files with my digital
> library software is about 40 seconds, but that's also moving and writing
> files and creating an archive file for each. I might try to create a
> benchmark unit test to see how performance rates just for the reference
> manager.
>
> I'd still rather avoid Java serialisation/deserialisation if it turns out
> the difference between that and simply reading the source files isn't that
> huge. A lot cleaner design for sure. With high-frequence and multi-core
> CPUs, VMs and SSDs a lot of things that used to take a lot of time simply
> don't. I bought a 12 core, 24 thread i9 recently and my compile times
> (when coupled with command line optimisations) went from 90-120 seconds
> down to 15. For something like the reference manager where it's all reads
> and no writes (if we avoid serialisation on shutdown), then I think the
> performance even on 16K files should be reasonable. Interesting to test in
> any case.
>
> My time comes in spurts so I'm not sure how long this will take. I've
> currently got the bones of it, the easy bits, the rest is coming along...
>
> Cheers

Re: GraphReferenceManager

[Juan Pablo Santos Rodríguez]

Hi Murray,

ahh ok, now I see, so I guess we could start by making the reference
manager pluggable through a wiki property, so anyone wishing to use it can
do so easily.

Setting aside when to switch to JDK-11 (or whatever version we see fit),
the graphmanager could be compiled with Java 11, having the rest of the
project compiling with Java 8. The markdown module has been in a similar
situation in the past, where it has been compiling with Java 8, and the
rest of the project with Java 6 or 7, so that shouldn't be a stopper..

As for the number of pages, jspwiki-wiki has almost 400 pages, but there
are other wikis out there with higher number of pages; f.ex.,
https://encyclopaedia-wot.org has almost 4000 pages,
https://www.ecyrd.com/ButtUgly/wiki has around 3200 and http://ldapwiki.com/
almost 16400


HTH,
juan pablo

On Tue, Jul 26, 2022 at 3:02 PM Murray Altheim  wrote:

>
>
> On 26/07/22 6:30 am, Juan Pablo Santos Rodríguez wrote:
> > Hi Murray!
> >
> > nice to see you on the dev list again :-)
>
> Yes, thanks, good to see you as well. Many years...  ..  .
>
> > lots of interesting points on your email, my POV on them:
> >
> > - re. GraphReferenceManager: I fail to see how it works, would you mind
> > sharing a concrete example? it is not clear to me if it needs a syntax
> > change or not, or if the current syntax would be used for a different
> > meaning? Would making the reference manager more "pluggable-friendly"
> > (i.e., selecting the implementation through a property file instead of
> > using classmapping-extra.xml) something helpful for you? You also mention
> > some possibility of an unsynchronized set of links on
> > DeafultReferenceManager, would you mind ellaborating a bit on it? If it's
> > fixable, I'd like to address it, rather than dropping the
> de/serialization,
> > it helps with faster startups on large wikis.
>
> The GraphReferenceManager wouldn't require any syntax changes at all,
> it's entirely focused on altering how the links are captured and stored.
> So there are four link types:
>
> 1. normal intra-wiki links, e.g., [PageName]
> 2. links to Attachments on the same wiki
> 3. links to external URLs
> 4. links to uncreated pages
> 5. interwiki links (currently I'm not attempting to support them)
>
> Currently the DefaultReferenceManager maintains two maps, m_refersTo and
> m_referredBy. These store the various links, and ignore the external
> links and uncreated pages are obtained dynamically by iterating through
> all the links.
>
> But this storage of links doesn't in any way represent the actual
> structure of the links on the wiki, which form a graph. So what I'm
> suggesting is to actually store link types 1-4 (5 will come later) as an
> actual graph structure.
>
> The GraphReferenceManager begins by creating vertices for all the pages,
> then adds edges (links) for all the links between pages, with external
> URLs and uncreated links (targets) isntantiated as graph nodes. So if
> multiple links connect to the same external target URL, or to the same
> uncreated page, they'd connect to the same graph vertex (node).
>
> If a page is created, the graph is queried for an uncreated link that
> matches and that link is replaced by the actual (new) vertex/node.
>
> One can traverse the graph in various ways, and it's possible to
> traverse at a set depth, e.g., "I want all nodes that are within three
> steps from this one" et cetera.
>
> Part of my interest in developing this is that I've had experience in
> the past with commercial link managers (such as the Arbortext suite of
> tools), which typically store things in traditional databases, so the
> graph storage is not native but synthetic. I've worked a fair bit with
> Neo4j and thought that approaching a reference manager implementation
> with a native graph database (or at least structure in-memory) would be
> an interesting project.
>
> I guess that raises the issue of what kind of scale (page count) do we
> know of in the JSPWiki world? What's a reasonable high-end wiki page
> count that my reference manager should be able to support easily? Rather
> than serialising (using Java serialisation) the Maps, I'd more likely
> use either a graph database or serialise to a proper graph syntax that's
> natively supported by JGraphT. Reading an XML file from disk and
> rebuilding the graph on modern hardware is pretty trivial nowadays.
>
> > - re. JGraphT, I've checked their repo and it's dual-licensed under EPL
> > 2.0, so it could be brought as a dependency; maybe it would need a note
> on
> > the NOTICE file, but that should be all, I've to check that license on
> > detail to see what it requires to be used. However, t

Re: GraphReferenceManager

[Juan Pablo Santos Rodríguez]

Hi Murray!

nice to see you on the dev list again :-)

lots of interesting points on your email, my POV on them:

- re. GraphReferenceManager: I fail to see how it works, would you mind
sharing a concrete example? it is not clear to me if it needs a syntax
change or not, or if the current syntax would be used for a different
meaning? Would making the reference manager more "pluggable-friendly"
(i.e., selecting the implementation through a property file instead of
using classmapping-extra.xml) something helpful for you? You also mention
some possibility of an unsynchronized set of links on
DeafultReferenceManager, would you mind ellaborating a bit on it? If it's
fixable, I'd like to address it, rather than dropping the de/serialization,
it helps with faster startups on large wikis.

- re. JGraphT, I've checked their repo and it's dual-licensed under EPL
2.0, so it could be brought as a dependency; maybe it would need a note on
the NOTICE file, but that should be all, I've to check that license on
detail to see what it requires to be used. However, that dependency
requires Java 11 to run, so as of today, on the convenience binaries, the
GraphReferenceManager and associated classes would not be shippable with
the main war. Which leds me to the next point

- re. Java 11: probably deserves an specific thread on itself, but right
now there aren't specific plans for it. Which does not mean we're not
tkaing that into account.. Given the pace of the JDK releases may be even
going to JDK-17 would seem reasonable, next Java LTS is due september 2023,
which is not that far. Maybe post-2.11.3 release seems like a good moment
to discuss this topic?

- re. Lombok, would be +1 from me

- re, plugins and graph reference manager package: if you plan to include
them on JSPWiki :-) then the org.apache.wiki package should be the way to
go, would be their final package in any case.


cheers,
juan pablo

On Fri, Jul 22, 2022 at 4:16 AM Murray Altheim  wrote:

> Hi,
>
> I've been busy on my own projects but under the neocortext.net domain I
> will possibly soon be releasing some open source code, mostly related to
> digital libraries and ontologies. But there is some JSPWiki related code
> as well, as I've been incorporating JSPWiki into some of this other work.
>
> I'm working on a potential replacement DefaultReferenceManager. My first
> iteration proved not different enough from the existing code to warrant
> the update; yes, it removed some of the strangeness (and eliminated the
> serialization/deserialization, which I didn't find useful and created the
> possibility of an unsynchronized set of links), but I didn't find it very
> elegant, mostly just a cleanup but no real innovation.
>
> So rather than using Sets or Maps, I thought a better and certainly more
> interesting approach would use JGraphT to implement a proper graph
> structure
> of links between Pages, Attachments, as well as external links. With some
> default predicates that could be expanded so that wiki links could take the
> form of subject-predicate-object, i.e., actual tuples. The implementation
> is
> called GraphReferenceManager.
>
> A link in this system could look like:
>
>[Object]   # where 'Object' is the target page, the
> implicit 'Subject' being the page
> containing the link (typical existing link)
>[Predicate|Object] # where 'Predicate' expresses the meaning of
> the link. Such predicates are wiki pages,
> with the three existing links hardwired:
> inter-page, attachment, and external links
>[Subject|Predicate|Object] # frees the link from its parent page, so
> links could be expressed anywhere
>
> I wouldn't introduce any changes to the link parser at first, so this
> extended syntax is only a proposal, and the GraphReferenceManager doesn't
> conceptionally require the syntax changes, i.e., I'd use hardwired values
> for the predicates until such point as predicates were supported in wiki
> syntax.
>
> This work raises some questions:
>
>1. would anyone have any issues with introducing JGraphT into the
> JSPWiki
>   set of dependencies?
>
>2. would anyone have any issues with introducing Lombok into the JSPWiki
>   set of dependencies? I'd rather use factories and builders than
>   constructors, and would also like to avoid explicit getters and
>   setters. Something like a DSL might be nice.
>
>3. at what point is it planned to bump JSPWiki from Java 8 to say,
>   Java 11? For my day job I've been doing a fair bit of remediation
> work
>   on legacy apps, bumping them *up* to Java 8. But the number of
>   features I've grown accustomed to in Java 11 makes these features a
>   bit painful to lose.
>
>4. would the team prefer I develop the reference manager under the
>   

Incoming 2.11.3 vote+release

[Juan Pablo Santos Rodríguez]

Hi!

Don't know for others, but I plan to do some minor dependency updates
throughout the weekend, having in mind starting a release vote next
Monday/Tuesday, if nothing steps in.

This release should fix a number of security issues, so every additional
testing that can be done in order to ensure a successful release will be
most welcome. If you encounter something not working as expected, please
shout out!


Best regards,
juan pablo

Estimating memory requirements for JSPWiki

[Juan Pablo Santos Rodríguez]

Hi,

some of the last pushes introduced a profile that allows to measure the
memory taken by different JSPWiki objects, which comes handy f.ex., if
trying to customize your cache. To activate it, from the root module,
execute

mvn test -Dtest=MemoryProfiling -pl jspwiki-main

(note that the test property with that specific value executes a test AND
activates a profile which loads a java agent, so the test can't be executed
standalone from an IDE - preceding maven execution is needed).

For the latest push, the execution yields the following numbers

===
Plain Engine, without pages/attachments, search indexes, references, etc.:
 4.898.192 bytes
Engine, with default set of wiki pages: ..
 5.579.008 bytes
Page: 
   670.352 bytes
Attachment: ..
   671.368 bytes
Guest session on plain engine: ...
   671.888 bytes
Acl: .
   104 bytes
Acl entry: ...
   112 bytes
---

Please note that this test doesn't take into account page contents or
attachments themselves, only their associated Page and Attachment java
objects. Also, the java agent loaded requires Java 8 to be run.

The second number should give a very good estimate of how much memory is
JSPWiki consuming on your (production) system, just tweak the test at [#1]
and share your numbers!


cheers,
juan pablo

[#1]:
https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/test/java/org/apache/wiki/MemoryProfiling.java

Re: Where do ajax post calls get started?

[Juan Pablo Santos Rodríguez]

Hi,

answering to self, in case it is helpful for others, there are several
"new Request().." invocations on the *js filesthat perform the calls.
As a bonus, all  fields whose name begins with "wiki" is
automatically loaded into the Wiki object so you can do things like:

[...]
data: { page: Wiki.PageName, wikimarkup: "[{Groups}]()",
'X-XSRF-TOKEN': wiki.CsrfProtection },


best regards,
juan pablo

On Fri, Jul 1, 2022 at 5:13 PM Juan Pablo Santos Rodríguez
 wrote:
>
> Hi,
>
> I'm writing a csrf prevention filter for post requests on JSPWiki. So far 
> everything is going fine looking for posts requests via ajax: preview is 
> started by an AJAX POST call to AJAXPreview.jsp, but I can't find where the 
> call is started. The only place that seems to be calling is jspwiki-edit.js 
> file, but that's a get.
>
> Something similar happens with calls to AJAXSearch.jsp. There's also a couple 
> of ajax[json|html] functions at jspwiki-common.js but I don't see where/when 
> are they called.
>
> I'll keep looking, but any pointers in the meantime would be most welcomed :-)
>
>
> Cheers,
> juan pablo
>
>

Where do ajax post calls get started?

[Juan Pablo Santos Rodríguez]

Hi,

I'm writing a csrf prevention filter for post requests on JSPWiki. So far
everything is going fine looking for posts requests via ajax: preview is
started by an AJAX POST call to AJAXPreview.jsp, but I can't find where the
call is started. The only place that seems to be calling is jspwiki-edit.js
file, but that's a get.

Something similar happens with calls to AJAXSearch.jsp. There's also a
couple of ajax[json|html] functions at jspwiki-common.js but I don't see
where/when are they called.

I'll keep looking, but any pointers in the meantime would be most welcomed
:-)


Cheers,
juan pablo

[DRAFT] Board report for 2022/04

[Juan Pablo Santos Rodríguez]

Hi,

please see below draft for upcoming board meeting. As usual, any
comments, edits, etc. are more than welcome.


cheers,
juan pablo

+## Description:
+The mission of JSPWiki is the creation and maintenance of software related to
+Leading open source WikiWiki engine, feature-rich and built around standard
+JEE components (Java, servlets, JSP).
+
+## Issues:
+There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (8 years ago)
+There are currently 14 committers and 8 PMC members in this project.
+The Committer-to-PMC ratio is 7:4.
+
+Community changes, past quarter:
+- No new PMC members. Last addition was Dave Koelmeyer on 2016-04-06.
+- No new committers. Last addition was Dave Koelmeyer on 2016-04-06.
+
+## Project Activity:
+JSPWiki 2.11.2 was released on Feb, 24th, featuring some Markdown support
+improvements and a couple of fixed CVEs. Work on 2.11.3 is under way,
+although this quarter has seen a slower development pace.
+
+2.11.3 contains further Markdown support improvements, being usable right
+now. We still have two finish it, but as of this release, the wiki syntax
+will be completely pluggable.
+
+Another new feature that is being released with 2.11.3 is the Engine
+Lifecycle Extensions, another JSPWiki extension point, that allows custom
+components to be aware of Engine's initialization and shutdown, without
+having to deep dive on Engine's internals. This allows, among other things,
+to have smoother custom components installations.
+
+Finally, 4 reported vulnerabilities will be fixed in 2.11.3. Aside from
+that, we got another vulnerability report that was looked into and rejected.
+
+## Community Health:
+Traffic on both MLs had an increase compared with last quarter, although
+development has been slower.
+
+We merged a PR from a contributor which fixed some italian texts.
+
+There is enough people to provide project oversight.
+

Re: Markdown support inside JSPWiki

[Juan Pablo Santos Rodríguez]

Hi Dirk!

finally had some time to work on this. Latest push on master should
load a Markdown specific Wiki.Snips.js file ([#1]) when
jspwiki.syntax=markdown is provided as a wiki property :-) I finally
went with separate files instead of overwritting the snips b/c I
thought this way is easier to extend in the case anyone wants to
develop support for another wiki syntax (btw, throughout the week I'll
try to update [#2] with a link to Markdown support and a new section
on developing an extension for supporting another wiki syntax)

However, right now, the plain editor should be working only for a big
part of the Markdown syntax, as there were sections I didn't knew how
to approach them:

*  separators
JSPWiki syntax allows to set some css class/style by using the %%.. %%
directives which render span elements. On Markdown you do this by
adding a {.your_css_class} constructs at the end of the paragraph, and
the Markdown engine infers where to start applying it (ussually, the
start of the paragraph). To explicit only a section of a paragraph (a
span) you have to add an empty html comment, some like my text
here{.bg-info} (f.ex, on the sign: snip). There are a lot of places on
the Wiki.Snips file that rely on this separator. It's ugly for a
Markdown file, but I haven't found any other way to note where to
begin..

*nScope property on tabs: and font: snips
In these cases, the ending element of the value on the nScope contains
some variable text, so I've thrown a \\w+ in hopes that this would
automagically catch that variable part, but I'm afraid it is not
enough.

Something similar occurs on scope property of fontDlg:, colorDlg: and
iconDlg: snips

* suggest property on *Dlg: snips
The suggest: property usually contains an element with one or several
regular expressions. I haven't touched any of those as a) I don't
understand most of them, b) not sure where or how they're used, and c)
also a) again.

Something similar happens on linkPart2:, linkPart3:, linkDlg: and
pluginDlg: snips, with the lback and match properties

* lipstick: snips
Lastly, I think I've managed to correctly implement the lipstick
element: but anoher pair of eyes would be more than welcome. Alas,
properly speaking, another pair of eyes looking at the whole file
would be more than welcome.

Would you mind taking a look at those issues? O:-) I'd like to focus
on providing initial sets of Markdown pages by using some sort of
yet-to-be-codified jspwiki-to-markdown conversor. Not a complete one,
but something enough to convert the markup on the available wiki
pages..


cheers,
juan pablo

[#1]: 
https://github.com/apache/jspwiki/blob/master/jspwiki-markdown/src/main/javascript/Wiki.Snips.Markdown.js
[#2]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki%20Syntax

On Mon, Jan 17, 2022 at 11:57 PM Dirk Frederickx
 wrote:
>
> Hi Juan,
>
> >> inline feedback,
>
>
> On Mon, Jan 17, 2022 at 12:43 AM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi Dirk!,
> >
> > I've been looking at the source, and I'm not sure I'm following.
> > Wiki.Snip.js seems to be responsible of the wiki syntax displayed by
> > the editor, right?
> >
> >>> Yes, right.   Wiki.Snip.js is the right file.  (not the
> Snipe.Command.js)
>
> >
> > I was thinking of providing one Wiki.Snip.js via
> > wiki:IncludeResources. The specific file would be selected depending
> > on a property on jspwiki-custom.properties file, something like
> >
> > >>> That would be an option,  but then you'd need to move the Wiki.Snip.js
> outside of the Haddock-edit.js file.
> (change the wro-haddock.xml build file)  and load it separately.
>
>
> <%
> > final String editor = engine.getWikiProperties().get(
> > "jspwiki.syntax.editor" ); // or default to something
> > %>
> > [...]
> > //<![CDATA[
> > <wiki:IncludeResources type="editor"/>
> > <%-- outputs something like
> > Wiki.Snips = {... }
> > --%>
> > //]]>
> >
> > In order to be loaded through wiki:IncludeResources, current
> > Wiki.Snip.js file would move to the jspwiki-main module, being
> > minified there; the jspwiki-markdown module would also hold a
> > Markdown.Wiki.Snip.js, following the same structure, but with Markdown
> > snippets.
> >
> > >>> Better is to keep it then separately;
> >>> In plain.jsp you could do this
> 
> ->this is a reduced haddock-edit.js
> 
> 
> 
> 
> 
> 
>
>
> > Other 3rd party syntax extensions would hold their js file too, but
> > only one would be loaded, based on a property on
> > jspwiki-custom.properties file. This "pluggability" would be the
> > important thing to me when implementing support for othe

Introducing Engine lifecycle extensions

[Juan Pablo Santos Rodríguez]

Hi all,

latest push on master introduces engine lifecycle extensions as
another JSPWiki extension point. It allows custom components (plugins,
filters, etc.) to be aware of Engine's initialization and shutdown,
without having to deep dive on Engine's internals.

Examples of EngineLifecycleExtension's use cases:

* Appending a plugin's classpath to jspwiki.plugin.searchPath, so it
can be used as a drop-in, without further configuration on the JSPWiki
instance.
* Setting up that expensive singleton, or disposing resources, without
having to use or register a WikiEventListener.
* Providing default parameters or setup for a custom extension.

They don't provide too much value on themselves, but are perfect
companions for custom plugins, filters, etc. As such, Engine lifecycle
extensions are expected to be usually bundled with another custom
component.

As a concrete example, the markdown module uses an
EngineLifecycleExtension to set up all the required properties if
jspwiki.syntax=markdown is provided on the jspwiki[-custom].properties
file. So, instead of providing

jspwiki.renderingManager.markupParser=org.apache.wiki.parser.markdown.MarkdownParser
jspwiki.renderingManager.renderer=org.apache.wiki.render.markdown.MarkdownRenderer
jspwiki.renderingManager.renderer.wysiwyg=org.apache.wiki.render.markdown.MarkdownRenderer
jspwiki.syntax.decorator=org.apache.wiki.htmltowiki.syntax.markdown.MarkdownSyntaxDecorator

on the jspwiki[-custom].properties file, now the same can be
accomplished by providing

jspwiki.syntax=markdown

which is not only less configuration, but much more expressive in
terms of what we do want to achieve by setting that/those properties.

The 
https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToWriteAnEngineLifecycleExtension
page contains more details on how to code your own engine lifecycle
extension.


best regards,
juan pablo

[CVE-2022-24948] Apache JSPWiki Cross-site scripting vulnerability on User Preferences screen

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.1

Description
A carefully crafted user preferences for submission could trigger an
XSS vulnerability on Apache JSPWiki, related to the user preferences
screen, which could allow the attacker to execute javascript in the
victim's browser and get some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.2 or later.

Credit
This issue was discovered by Paulos Yibelo, from Octagon Networks.

[CVE-2022-24947] Apache JSPWiki CSRF Account Takeover

[Juan Pablo Santos Rodríguez]

Severity
Critical

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.1

Description
Apache JSPWiki user preferences form is vulnerable to CSRF attacks,
which can lead to account takeover.

Mitigation
Apache JSPWiki users should upgrade to 2.11.2 or later. Installations
>= 2.7.0 can also enable user management workflows' manual approval to
mitigate the issue.

Credit
This issue was discovered initially by Cristian Borlovan from Ounce
Labs Security (ref. JSPWIKI-79), and later on and independently from
this by Paulos Yibelo, from Octagon Networks.

[ANNOUNCE] Apache JSPWiki 2.11.2 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki 2.11.2.

This is the third release on the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.2

The full change log is available here:
https://issues.apache.org/jira/browse/JSPWIKI/fixforversion/12351120

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/

The Apache JSPWiki Team

[RESULT][VOTE] Release JSPWiki version 2.11.2

[Juan Pablo Santos Rodríguez]

Hi,

more than 72 hours have passed, here's the vote tally:
* Dirk Frederick: +1
* Harry Metske +1
* Juan Pablo Santos +1
(all binding votes)

so the vote passes :-) I'll proceed with the remaining release steps.


best regards,
juan pablo

On Tue, Feb 22, 2022 at 10:11 PM Dirk Frederickx
 wrote:
>
> +1
>
> Tx
> dirk
>
> On Tue, Feb 22, 2022 at 9:59 AM Harry Metske  wrote:
>
> > +1
> >
> > thanks,
> > Harry
> >
> >
> > On Mon, 21 Feb 2022 at 23:12, Juan Pablo Santos Rodríguez <
> > juanpa...@apache.org> wrote:
> >
> > > This is a release vote for Apache JSPWiki, version 2.11.2. The vote
> > > will be open for at least 72 hours from now.
> > >
> > > It fixes the following issues:
> > >
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351120
> > >
> > > You can see a curated changelog at
> > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
> > >
> > > Note that we are voting upon the source (tag), binaries are provided
> > > for convenience.
> > >
> > > Everybody is encouraged to vote.
> > >
> > > Source and binary files:
> > > https://dist.apache.org/repos/dist/dev/jspwiki/2.11.2-RC1
> > >
> > > Nexus staging repo:
> > > https://repository.apache.org/content/repositories/orgapachejspwiki-1026
> > >
> > > The tag to be voted upon:
> > > https://github.com/apache/jspwiki/tree/2.11.2-RC1
> > >
> > > JSPWiki's KEYS file containing PGP keys we use to sign the release:
> > > https://www.apache.org/dist/jspwiki/KEYS
> > >
> > > *** Please download, test and vote:
> > >
> > > [ ] +1 Approve the release
> > > [ ]  0 Don't mind
> > > [ ] -1 Disapprove the release (please provide specific comments)
> > >
> >

Re: [VOTE] Release JSPWiki version 2.11.2

[Juan Pablo Santos Rodríguez]

My +1,


best regards,
juan pablo

El lun., 21 feb. 2022 23:12, Juan Pablo Santos Rodríguez <
juanpa...@apache.org> escribió:

> This is a release vote for Apache JSPWiki, version 2.11.2. The vote
> will be open for at least 72 hours from now.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351120
>
> You can see a curated changelog at
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
>
> Note that we are voting upon the source (tag), binaries are provided
> for convenience.
>
> Everybody is encouraged to vote.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jspwiki/2.11.2-RC1
>
> Nexus staging repo:
> https://repository.apache.org/content/repositories/orgapachejspwiki-1026
>
> The tag to be voted upon:
> https://github.com/apache/jspwiki/tree/2.11.2-RC1
>
> JSPWiki's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/jspwiki/KEYS
>
> *** Please download, test and vote:
>
> [ ] +1 Approve the release
> [ ]  0 Don't mind
> [ ] -1 Disapprove the release (please provide specific comments)
>

[VOTE] Release JSPWiki version 2.11.2

[Juan Pablo Santos Rodríguez]

This is a release vote for Apache JSPWiki, version 2.11.2. The vote
will be open for at least 72 hours from now.

It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12351120

You can see a curated changelog at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

Note that we are voting upon the source (tag), binaries are provided
for convenience.

Everybody is encouraged to vote.

Source and binary files:
https://dist.apache.org/repos/dist/dev/jspwiki/2.11.2-RC1

Nexus staging repo:
https://repository.apache.org/content/repositories/orgapachejspwiki-1026

The tag to be voted upon:
https://github.com/apache/jspwiki/tree/2.11.2-RC1

JSPWiki's KEYS file containing PGP keys we use to sign the release:
https://www.apache.org/dist/jspwiki/KEYS

*** Please download, test and vote:

[ ] +1 Approve the release
[ ]  0 Don't mind
[ ] -1 Disapprove the release (please provide specific comments)

Re: Markdown support inside JSPWiki

[Juan Pablo Santos Rodríguez]

Hi Dirk!,

I've been looking at the source, and I'm not sure I'm following.
Wiki.Snip.js seems to be responsible of the wiki syntax displayed by
the editor, right?

I was thinking of providing one Wiki.Snip.js via
wiki:IncludeResources. The specific file would be selected depending
on a property on jspwiki-custom.properties file, something like

<%
final String editor = engine.getWikiProperties().get(
"jspwiki.syntax.editor" ); // or default to something
%>
[...]
//<![CDATA[
<wiki:IncludeResources type="editor"/>
<%-- outputs something like
Wiki.Snips = {... }
--%>
//]]>

In order to be loaded through wiki:IncludeResources, current
Wiki.Snip.js file would move to the jspwiki-main module, being
minified there; the jspwiki-markdown module would also hold a
Markdown.Wiki.Snip.js, following the same structure, but with Markdown
snippets.

Other 3rd party syntax extensions would hold their js file too, but
only one would be loaded, based on a property on
jspwiki-custom.properties file. This "pluggability" would be the
important thing to me when implementing support for other wiki
syntaxes, so there's no need to overwrite JSPs or provide templates
that overwrite a few JSPs for markdown (or other wiki syntaxes).

That's was what I was heading, and I still have to make a POC to see
if this is feasible (I think it should, but have to make the POC).

Re-reading your e-mail, it seems that your approach is different.
Given that you know way more on the editor / js in general, I feel
your approach is most probably the way to go. How would the wiki
syntax displayed by the editor be chosen?


best regards,
juan pablo

On Fri, Jan 14, 2022 at 12:51 PM Dirk Frederickx
 wrote:
>
> Hi Pablo,
>
> Good to see how this is progressing.
>
> Happy to help on building the markdown support into the editor.
> The SNIP editor is build to be pluggable,  and this would be a good test
> case.
> You should only provide a specific "Markdown.Snipe.Command.js" file.
>
> Would you have a specific markdown editor JSP file or not ?
>
>
> BR,
>  dirk
>
> On Thu, Jan 13, 2022 at 2:52 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi,
> >
> > last push completed markdown support on the WYIWYG editor. Right now
> > there's a markdown parser, a markdown renderer, a WYIWYG editor
> > renderer, and an html from the WYIWYG editor to markdown syntax
> > converter. [#1] has a bit more info on this.
> >
> > The only item left, in order to have full Markdown support inside
> > JSPWiki, is making the plain editor able to also output Markdown
> > syntax when using the "snips" functionality, but I have no idea on
> > what's the best way to accomodate this requirement. Right now the
> > aforementioned parser, renderers, etc. are pluggable, so if anyone
> > would want to write an extension to provide, say JIRA wiki markup
> > support, it is possible to do so.
> >
> > Ideally, markdown support on the plain editor should be pluggable as
> > well and allow third party wiki syntaxes.
> >
> > I've thought of providing the appropiate wiki syntax to the js files
> > the same way I18N texts are passed, using the IncludeResources tag on
> > the commonheader.jsp file, but I'm neither sure which files should be
> > provided, nor javascript is one of my strong suits. Or maybe if it
> > should be output a javascript object with the appropiate syntax, and
> > modify whatever js files are required to read the markup snips (or
> > whatever is needed) from this object?
> >
> > Dirk, WDYT?
> >
> >
> > best regards,
> > juan pablo
> >
> > [#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=Markdown%20Support
> >

Markdown support inside JSPWiki

[Juan Pablo Santos Rodríguez]

Hi,

last push completed markdown support on the WYIWYG editor. Right now
there's a markdown parser, a markdown renderer, a WYIWYG editor
renderer, and an html from the WYIWYG editor to markdown syntax
converter. [#1] has a bit more info on this.

The only item left, in order to have full Markdown support inside
JSPWiki, is making the plain editor able to also output Markdown
syntax when using the "snips" functionality, but I have no idea on
what's the best way to accomodate this requirement. Right now the
aforementioned parser, renderers, etc. are pluggable, so if anyone
would want to write an extension to provide, say JIRA wiki markup
support, it is possible to do so.

Ideally, markdown support on the plain editor should be pluggable as
well and allow third party wiki syntaxes.

I've thought of providing the appropiate wiki syntax to the js files
the same way I18N texts are passed, using the IncludeResources tag on
the commonheader.jsp file, but I'm neither sure which files should be
provided, nor javascript is one of my strong suits. Or maybe if it
should be output a javascript object with the appropiate syntax, and
modify whatever js files are required to read the markup snips (or
whatever is needed) from this object?

Dirk, WDYT?


best regards,
juan pablo

[#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=Markdown%20Support

[ JDBC | XML] user databases not allowing empty wiki names

[Juan Pablo Santos Rodríguez]

Hi,

with last push, both JDBCUserDatabase and XMLUserDatabase will not
allow empty or null wiki names on the getWikiNames() method.
Previously it was only not allowing null wiki names.

In XMLUserDatabase, the reasoning behind this change is that JDom
returns an empty string when querying for missing attributes, so
checking for null at getWikiNames was resulting in unreachable code.
Not sure if it's intended or a bug (seems to me like the second, as an
empty wiki name may repeat and doesn't male much sense), but this
change inlines with the logic of the UI on the registration form,
which mandates a not empty value for the wiki name. As for the
JDBCUserDatabase, the method seems to have been developed from the
former (there was a log message noting XMLUserDatabase instead of
JDBCUserDatabase on the null check), so the same change has been made
there.

Most probably this change will not affect anyone, either regular
JSPWiki or custom 3rd party code developers, but as it is a change in
the method behaviour, I've thought at least dropping a line here.

If it's desired, we can change the logic of the method to return the
login name if there is no wiki name, or whatever seems reasonable - I
came across that piece of code and thought of adjusting to what it
probably meant to do.


best regards,
juan pablo

Re: [jspwiki] 02/03: Merge branch 'master' of https://github.com/apache/jspwiki

[Juan Pablo Santos Rodríguez]

Hi,

I had a rather big push in the works, so I've verified those commits; as their 
content seemed ok to me, I've proceeded with the push.


best regards,
juan pablo

On 2022/01/12 07:15:14 Dirk Frederickx wrote:
> Hi,
> 
> I wanted to push a single update (XSS vuln.) to the repo this morning,  but
> it seems that other (local) changes were merged as well :-(
> 
> I've no time to further check this now;  but will validate this evening.
> 
> Sorry for the inconvenience,
> dirk
> 
> 
> On Wed, Jan 12, 2022 at 8:10 AM  wrote:
> 
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > brushed pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/jspwiki.git
> >
> > commit 6e5da6210062e8db785163ad5c77c5512b952ccf
> > Merge: de8e6bb 8d9660b
> > Author: brushed 
> > AuthorDate: Wed Jan 12 08:05:35 2022 +0100
> >
> > Merge branch 'master' of https://github.com/apache/jspwiki
> >
> >  ChangeLog.md   |  29 ++-
> >  LICENSE|   1 +
> >  .../src/main/java/org/apache/wiki/api/Release.java |   6 +-
> >  jspwiki-bom/pom.xml| 222
> > +
> >  .../WikiBootstrapServletContextListenerTest.java   |   2 +-
> >  .../src/test/resources/ini/jspwiki.properties  |  19 +-
> >  .../htmltowiki/HtmlStringToWikiTranslator.java |   2 +
> >  .../apache/wiki/htmltowiki/SyntaxDecorator.java|  19 +-
> >  .../htmltowiki/XHtmlElementToWikiTranslator.java   |  30 ++-
> >  .../wiki/htmltowiki/syntax/MarkupHelper.java   | 111 +++
> >  .../wiki/htmltowiki/syntax/jspwiki/ADecorator.java | 136 +++--
> >  .../htmltowiki/syntax/jspwiki/HrDecorator.java |   1 +
> >  .../htmltowiki/syntax/jspwiki/ImageDecorator.java  |   1 +
> >  .../syntax/jspwiki/JSPWikiSyntaxDecorator.java |  16 +-
> >  .../htmltowiki/syntax/jspwiki/MarkupHelper.java|  35 
> >  .../syntax/jspwiki/PlainTextCssDecorator.java  |   9 +-
> >  .../jspwiki/PlainTextCssSpecialDecorator.java  |   5 +-
> >  .../syntax/jspwiki/PlainTextDecorator.java |   2 +-
> >  .../wiki/references/DefaultReferenceManager.java   |  57 +++---
> >  .../src/main/resources/ini/jspwiki.properties  |  17 ++
> >  jspwiki-markdown/pom.xml   |   5 +
> >  .../wiki/parser/markdown/MarkdownDocument.java |   3 +
> >  .../main/java/org/apache/wiki/util/XmlUtil.java|  19 +-
> >  pom.xml|  17 +-
> >  24 files changed, 554 insertions(+), 210 deletions(-)
> >
> 

[DRAFT] 2022-01 board report

[Juan Pablo Santos Rodríguez]

Hi,

as usual, please see below draft for this quarter's board report. Any
edits, comments, etc. are more than welcome.

The report is due to next Wednesday, so apologies on sending the draft
this late, I'll try to have it prepared with more time for next
report.


cheers,
juan pablo

+++ b/board-reports/2022-01.txt
@@ -0,0 +1,38 @@
+## Description:
+The mission of JSPWiki is the creation and maintenance of software related to
+Leading open source WikiWiki engine, feature-rich and built around standard
+JEE components (Java, servlets, JSP).
+
+## Issues:
+There are no issues requiring board attention.
+
+## Membership Data:
+Apache JSPWiki was founded 2013-07-17 (8 years ago)
+There are currently 14 committers and 8 PMC members in this project.
+The Committer-to-PMC ratio is 7:4.
+
+Community changes, past quarter:
+- No new PMC members. Last addition was Dave Koelmeyer on 2016-04-06.
+- No new committers. Last addition was Dave Koelmeyer on 2016-04-06.
+
+## Project Activity:
+After almost a year since last release, this quarter we managed to finally
+release 2.11.0. A few days after that, we had to release 2.11.1, to address
+recent log4j2 rce vulnerability.
+
+Aside from the releases, dev activity has been focused on providing support
+for markdown inside JSPWiki. Currently we have a parser and a renderer, and
+we need to add support for both plain and WYSIWYG editors. For the latter,
+there's a refactor ongoing, which should be completed soon.
+
+2 vulnerability disclosures were published and fixed in 2.11.0, we have a
+couple more which need investigation.
+
+Finally there was a discuss thread on moving from jira to github issues,
+but got nowhere, so we'll stick with jira for now.
+
+## Community Health:
+Traffic on both MLs had an increase compared with last quarter, due to both
+releases and the increased number of commits that were pushed this quarter.
+There is enough people to provide project oversight.
+

[ANNOUNCE] Apache JSPWiki 2.11.1 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki 2.11.1.

This is the second release on the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki
groupId, version 2.11.1

The full change log is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12350872

Apache JSPWiki contains a mitigation to log4j's CVE-2021-44228 by
upgrading to log4j 2.16.0
as well as a few other improvements and bug fixes. A curated change
log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to
get involved visit the project website at http://jspwiki.apache.org/


The Apache JSPWiki Team

[RESULT][VOTE] Release JSPWiki version 2.11.1

[Juan Pablo Santos Rodríguez]

Hi,

as 72h have just passed, here's the vote tally:

* David Vittor [+1]
* Harry Metske [+1]
* Juan Pablo Santos [+1]

That's three +1 binding votes, so it passes, I'll proceed with the
remaining release steps :-)


thanks,
juan pablo


On Thu, Dec 16, 2021 at 11:03 PM David Vittor  wrote:
>
> +1 from me.
>
> Kind regards,
> David V
>
> On Thu, Dec 16, 2021 at 4:19 AM Harry Metske  wrote:
>
> > +1
> >
> > thanks,
> > Harry
> >
> >
> >
> > Op wo 15 dec. 2021 om 17:57 schreef Juan Pablo Santos Rodríguez <
> > juanpa...@apache.org>
> >
> > > This is a release vote for Apache JSPWiki, version 2.11.1. The vote
> > > will be open for at least 72 hours from now.
> > >
> > > It fixes the following issues:
> > >
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12350872
> > >
> > > You can see a curated changelog at
> > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
> > >
> > > Note that we are voting upon the source (tag), binaries are provided
> > > for convenience.
> > >
> > > Everybody is encouraged to vote.
> > >
> > > Source and binary files:
> > > https://dist.apache.org/repos/dist/dev/jspwiki/2.11.1-RC1
> > >
> > > Nexus staging repo:
> > > https://repository.apache.org/content/repositories/orgapachejspwiki-1025
> > >
> > > The tag to be voted upon:
> > > https://github.com/apache/jspwiki/tree/2.11.1-RC1
> > >
> > > JSPWiki's KEYS file containing PGP keys we use to sign the release:
> > > https://www.apache.org/dist/jspwiki/KEYS
> > >
> > > *** Please download, test and vote:
> > >
> > > [ ] +1 Approve the release
> > > [ ]  0 Don't mind
> > > [ ] -1 Disapprove the release (please provide specific comments)
> > >
> >

Re: [VOTE] Release JSPWiki version 2.11.1

[Juan Pablo Santos Rodríguez]

My +1


best regards,
juan pablo

On Wed, Dec 15, 2021 at 5:57 PM Juan Pablo Santos Rodríguez
 wrote:
>
> This is a release vote for Apache JSPWiki, version 2.11.1. The vote
> will be open for at least 72 hours from now.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12350872
>
> You can see a curated changelog at
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
>
> Note that we are voting upon the source (tag), binaries are provided
> for convenience.
>
> Everybody is encouraged to vote.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jspwiki/2.11.1-RC1
>
> Nexus staging repo:
> https://repository.apache.org/content/repositories/orgapachejspwiki-1025
>
> The tag to be voted upon:
> https://github.com/apache/jspwiki/tree/2.11.1-RC1
>
> JSPWiki's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/jspwiki/KEYS
>
> *** Please download, test and vote:
>
> [ ] +1 Approve the release
> [ ]  0 Don't mind
> [ ] -1 Disapprove the release (please provide specific comments)

[VOTE] Release JSPWiki version 2.11.1

[Juan Pablo Santos Rodríguez]

This is a release vote for Apache JSPWiki, version 2.11.1. The vote
will be open for at least 72 hours from now.

It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12350872

You can see a curated changelog at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

Note that we are voting upon the source (tag), binaries are provided
for convenience.

Everybody is encouraged to vote.

Source and binary files:
https://dist.apache.org/repos/dist/dev/jspwiki/2.11.1-RC1

Nexus staging repo:
https://repository.apache.org/content/repositories/orgapachejspwiki-1025

The tag to be voted upon:
https://github.com/apache/jspwiki/tree/2.11.1-RC1

JSPWiki's KEYS file containing PGP keys we use to sign the release:
https://www.apache.org/dist/jspwiki/KEYS

*** Please download, test and vote:

[ ] +1 Approve the release
[ ]  0 Don't mind
[ ] -1 Disapprove the release (please provide specific comments)

[SECURITY] Apache JSPWiki affected by Apache Log4J CVE-2021-44228

[Juan Pablo Santos Rodríguez]

Hi all,

apologies for the cross-posting, please see below notice on how to
mitigate recent Log4J's RCE on existing JSPWiki 2.11.0 installations.

*
2021-12-13, Apache JSPWiki affected by Apache Log4J CVE-2021-44228

Severity: Critical

Versions Affected: 2.11.0

Description: Apache JSPWiki, 2.11.0 release is using a bundled version
of the Apache Log4J library vulnerable to Remote Code Execution. For
full impact and additional detail consult the Log4J security page.

Apache JSPWiki releases prior to 2.11.0 use Log4J 1.2.17 which may be
vulnerable for installations using non-default logging configurations
that include the JMS Appender, see
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
for discussion.

Mitigation: Any of the following are enough to prevent this
vulnerability for Apache JSPWiki installations:
* Upgrade to upcoming Apache JSPWiki 2.11.1, which will include an
updated version of the log4j2 dependency. Alternatively, you can build
2.11.1-git-02 from master branch which also includes the updated
dependency.
* Manually update the version of Log4J2 on your runtime classpath and
restart your JSPWiki application.
* Adding the -Dlog4j2.formatMsgNoLookups=true to the JVM launching the
application (f.ex., adding it to the CATALINA_OPTS variable under
tomcat).

As noted above, an upcoming release of Apache JSPWiki 2.11.1 with the
updated library is to be expected this week.

References: https://logging.apache.org/log4j/2.x/security.html

**

best regards,
juan pablo

Re: textToHtml methods from WikiEngine + ReferringPagesPlugin [was: Re: [ANNOUNCE] Apache JSPWiki 2.11.0 released]

[Juan Pablo Santos Rodríguez]

Hi Gary,

Glad that you were able to make it work :-)

To avoid this kind of situations onwards I was thinking of tweaking the
workDir property so that the generated work dir would be calculated as
jspwiki.workDir + '/' + jspwiki.applicationName. Did you set up this last
property in any of your 3 wikis?

@all, do you think that would this be an improvement?


Best regards,
juan pablo


El mié., 8 dic. 2021 8:22, Gary Kephart  escribió:

> Yes, that was it. When I redefined the working directory on each of the
> JSPWiki instances to separate directories, everything started working.
>
> Gary
>
> On 12/7/2021 11:05 PM, Gary Kephart wrote:
>
> A closer look at Wildfly's server log showed this:
>
> 2021-12-07 14:37:35,215 ERROR
> [org.apache.wiki.search.LuceneSearchProvider] (JSPWiki Lucene Indexer)
> Unable to start lucene: java.nio.channels.OverlappingFileLockException
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1107)
> at java.nio.channels.FileChannel.tryLock(FileChannel.java:1155)
> at
> org.apache.lucene.store.NativeFSLock.obtain(NativeFSLockFactory.java:217)
> at org.apache.lucene.store.Lock.obtain(Lock.java:77)
> at org.apache.lucene.index.IndexWriter.(IndexWriter.java:702)
> at
> org.apache.wiki.search.LuceneSearchProvider.getIndexWriter(LuceneSearchProvider.java:537)
> at
> org.apache.wiki.search.LuceneSearchProvider.doFullLuceneReindex(LuceneSearchProvider.java:228)
> at
> org.apache.wiki.search.LuceneSearchProvider$LuceneUpdater.startupTask(LuceneSearchProvider.java:775)
> at
> org.apache.wiki.WikiBackgroundThread.run(WikiBackgroundThread.java:111)
>
> but then later on, I see this:
>
> 2021-12-07 15:43:02,676 INFO
> [org.apache.wiki.search.LuceneSearchProvider] (ServerService Thread Pool --
> 124) Lucene enabled, cache will be in:
> C:\Users\gary_kephart\AppData\Local\Temp\lucene
> 2021-12-07 15:43:02,677 INFO
> [org.apache.wiki.search.LuceneSearchProvider] (ServerService Thread Pool --
> 74) Lucene enabled, cache will be in:
> C:\Users\GARY_K~1\AppData\Local\Temp\lucene
> 2021-12-07 15:43:02,680 WARN  [org.apache.wiki.WikiBackgroundThread]
> (JSPWiki Lucene Indexer) Starting up background thread: JSPWiki Lucene
> Indexer.
> 2021-12-07 15:43:02,680 WARN  [org.apache.wiki.WikiBackgroundThread]
> (JSPWiki Lucene Indexer) Starting up background thread: JSPWiki Lucene
> Indexer.
> 2021-12-07 15:43:02,682 INFO
> [org.apache.wiki.ajax.WikiAjaxDispatcherServlet] (ServerService Thread Pool
> -- 124) WikiAjaxDispatcherServlet registering
> search=org.apache.wiki.search.SearchManager$JSONSearch@315cce50
> perm=("org.apache.wiki.auth.permissions.PagePermission","*:*","view")
> 2021-12-07 15:43:02,683 INFO
> [org.apache.wiki.ajax.WikiAjaxDispatcherServlet] (ServerService Thread Pool
> -- 74) WikiAjaxDispatcherServlet registering
> search=org.apache.wiki.search.SearchManager$JSONSearch@4fcdc468
> perm=("org.apache.wiki.auth.permissions.PagePermission","*:*","view")
> 2021-12-07 15:43:02,686 WARN  [org.apache.wiki.WikiBackgroundThread]
> (WatchDog for 'OC Politizone') Starting up background thread: WatchDog for
> 'OC Politizone'.
> 2021-12-07 15:43:02,687 WARN  [org.apache.wiki.WikiBackgroundThread]
> (WatchDog for 'Campaigner Wiki') Starting up background thread: WatchDog
> for 'Campaigner Wiki'.
> 2021-12-07 15:43:02,688 INFO
> [org.apache.wiki.search.LuceneSearchProvider] (JSPWiki Lucene Indexer)
> Starting Lucene reindexing, this can take a couple of minutes...
> 2021-12-07 15:43:02,689 INFO
> [org.apache.wiki.search.LuceneSearchProvider] (JSPWiki Lucene Indexer)
> Starting Lucene reindexing, this can take a couple of minutes...
>
> Note that "OC Politizone" is another JSPWiki that I'm running on my local
> Wildfly, as is "Campaigner Wiki". The first one is running JSPWiki
> v2.11.0-M6 and the second one is running JSPWiki v2.10.2, while the
> Encyclopaedia WoT is running JSPWiki 2.11.0.
> Could this be causing the problem? Three different JSPWikis, with three
> different versions, all trying to use the same lucene temp folder?
>
> Gary
>
> On 12/7/2021 4:15 PM, Gary Kephart wrote:
>
> Juan Pablo,
>
> I found a folder named "lucene" in the working directory and delete that,
> then stopped and restarted Wildfly. No change, sadly, in either the search
> or WikiCategory.
>
> Yes, I will gladly add our site once we get this working.
>
> Gary
>
> On 12/7/2021 2:27 PM, Juan Pablo Santos Rodríguez wrote:
>
> Hi Gary,
>
> lucene index files are stored insi

Re: textToHtml methods from WikiEngine + ReferringPagesPlugin [was: Re: [ANNOUNCE] Apache JSPWiki 2.11.0 released]

[Juan Pablo Santos Rodríguez]

Hi Gary,

lucene index files are stored inside a dir called 'lucene-dir' inside
JSPWiki's working directory (/tmp or c:\temp if you haven't customised
the jspwiki.workDir property inside your jspwiki[-custom]-properties
file). Latest JSPWiki bundles lucene-backwards-codecs, which are
supposed to upgrade the Lucene indexes seamlessly, but if it isn't the
case, we should take a look at it to see what else is needed /
happening.

on a side note, once you're comfortable with the migration to JSPWiki,
would you like/mind adding your site to
https://jspwiki-wiki.apache.org/Wiki.jsp?page=JSPWikiSites ? :-)


best regards,
juan pablo

On Tue, Dec 7, 2021 at 5:29 PM Gary Kephart  wrote:
>
> Juan,
>
> Attached is a log file. I don't see anything unusual like an exception
> being thrown. I'm unfamiliar with Lucene beyond knowing it's for
> searching. But it is interesting that the site search is also not
> working. It returns no search results. I'm not sure which files are the
> Lucene index files.
>
> I'm updating from 2.11.0.M6, however, that may not matter as this is the
> first time I've tried to get it running on my local machine. Before, I
> just went ahead and put it on my host and dealt with the issues there.
> But now it's time for me to switch my website from just an Apache
> website to JSPWiki (I had both before and you could access the JSPWiki
> from the Apache website, see http://encyclopaedia-wot.org/) and so I'm
> testing this on my local machine for the first time before I put it on
> my hosted account.
>
> Gary
>
> On 12/7/2021 2:54 AM, Juan Pablo Santos Rodríguez wrote:
> > Hi Gary,
> >
> > cc'ing dev@j.a.o, as others migth find this interesting / being able
> > to help too..
> >
> > Had to look in the ChangeLog.md file, indeed the textToHtml methods
> > were moved to RenderingManager on 2.11.0-M7-git-05.
> >
> > As for the ReferringPagesPlugin, do you see something unusual in the
> > log? Can you set it to debug level to see if something stands out? My
> > guess would be to stop the application, delete the Lucene index files,
> > and start the application again
> >
> > >From which version are you upgrading from?
> >
> >
> > best regards,
> > juan pablo
> >
> >
> > On Tue, Dec 7, 2021 at 8:33 AM Gary Kephart  wrote:
> >> Juan,
> >>
> >> I think I figured this out:
> >>
> >>   RenderingManager rm = engine.getManager(RenderingManager.class);
> >>   String htmlText = rm.getHTML(context, text.toString());
> >>
> >> However, I'm having problems with the ReferringPagesPlugin . It's not
> >> returning anything. All I get is "...nobody " even on the WikiCategories
> >> page.
> >>
> >> Thanks,
> >> Gary
> >>
> >> On 12/6/2021 10:26 PM, Gary Kephart wrote:
> >>> Juan,
> >>>
> >>> I'm recompiling my plugins and all is well except for this line:
> >>>
> >>>  String a = engine.textToHTML(context, wlink);
> >>>
> >>> What's the new way of doing this? This is in the old ImageMapPlus
> >>> plugin that I downloaded and recompiled to work for M6.
> >>>
> >>> Gary
> >>>
> >>> On 11/23/2021 3:13 AM, Juan Pablo Santos Rodríguez wrote:
> >>>> The Apache JSPWiki team is pleased to announce the release of JSPWiki
> >>>> 2.11.0.
> >>>>
> >>>> This is the first release after eight milestones on the 2.11 series of
> >>>> Apache JSPWiki,
> >>>> a feature-rich and extensible WikiWiki engine built around the
> >>>> standard JEE
> >>>> components.
> >>>>
> >>>> The release is available here:
> >>>> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads
> >>>>
> >>>> JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
> >>>> version 2.11.0
> >>>>
> >>>> The full change log is available here:
> >>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12345152
> >>>>
> >>>>
> >>>> A curated change log is also available here:
> >>>> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
> >>>>
> >>>> We welcome your help and feedback. For more information on how to
> >>>> report problems, and to get involved visit the project website at
> >>>> http://jspwiki.apache.org/
> >>>>
> >>>>
> >>>> The Apache JSPWiki Team
> >>>>
> >>>
> >>
> >> --
> >> Gary Kephart
> >> Facebook: gary.kephart
> >> Twitter: @garykephart
> >>
> >> "The penalty that good men pay for not being interested in politics is to 
> >> be governed by lesser men." -- Plato.
> >>
>
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to be 
> governed by lesser men." -- Plato.

textToHtml methods from WikiEngine + ReferringPagesPlugin [was: Re: [ANNOUNCE] Apache JSPWiki 2.11.0 released]

[Juan Pablo Santos Rodríguez]

Hi Gary,

cc'ing dev@j.a.o, as others migth find this interesting / being able
to help too..

Had to look in the ChangeLog.md file, indeed the textToHtml methods
were moved to RenderingManager on 2.11.0-M7-git-05.

As for the ReferringPagesPlugin, do you see something unusual in the
log? Can you set it to debug level to see if something stands out? My
guess would be to stop the application, delete the Lucene index files,
and start the application again

>From which version are you upgrading from?


best regards,
juan pablo


On Tue, Dec 7, 2021 at 8:33 AM Gary Kephart  wrote:
>
> Juan,
>
> I think I figured this out:
>
>  RenderingManager rm = engine.getManager(RenderingManager.class);
>  String htmlText = rm.getHTML(context, text.toString());
>
> However, I'm having problems with the ReferringPagesPlugin . It's not
> returning anything. All I get is "...nobody " even on the WikiCategories
> page.
>
> Thanks,
>Gary
>
> On 12/6/2021 10:26 PM, Gary Kephart wrote:
> > Juan,
> >
> > I'm recompiling my plugins and all is well except for this line:
> >
> > String a = engine.textToHTML(context, wlink);
> >
> > What's the new way of doing this? This is in the old ImageMapPlus
> > plugin that I downloaded and recompiled to work for M6.
> >
> > Gary
> >
> > On 11/23/2021 3:13 AM, Juan Pablo Santos Rodríguez wrote:
> >> The Apache JSPWiki team is pleased to announce the release of JSPWiki
> >> 2.11.0.
> >>
> >> This is the first release after eight milestones on the 2.11 series of
> >> Apache JSPWiki,
> >> a feature-rich and extensible WikiWiki engine built around the
> >> standard JEE
> >> components.
> >>
> >> The release is available here:
> >> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads
> >>
> >> JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
> >> version 2.11.0
> >>
> >> The full change log is available here:
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12345152
> >>
> >>
> >> A curated change log is also available here:
> >> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
> >>
> >> We welcome your help and feedback. For more information on how to
> >> report problems, and to get involved visit the project website at
> >> http://jspwiki.apache.org/
> >>
> >>
> >> The Apache JSPWiki Team
> >>
> >
> >
>
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to be 
> governed by lesser men." -- Plato.
>

[CVE-2021-44140] Apache JSPWiki Arbitrary file deletion on logout

[Juan Pablo Santos Rodríguez]

Severity
Critical

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M8

Description
Remote attackers may delete arbitrary files in a system hosting a
JSPWiki instance by using a carefuly crafted http request on logout,
given that those files are reachable to the user running the JSPWiki
instance.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0 or later.

Credit
This issue was discovered by haby0 (forha...@gmail.com) from Duxiaoman
Financial Security Team, who also proposed the fix for this issue.

[ANNOUNCE] Apache JSPWiki 2.11.0 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki
2.11.0.

This is the first release after eight milestones on the 2.11 series of
Apache JSPWiki,
a feature-rich and extensible WikiWiki engine built around the standard JEE
components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.0

The full change log is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12345152

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/


The Apache JSPWiki Team

[RESULT][VOTE] Release JSPWiki version 2.11.0 (RC2)

[Juan Pablo Santos Rodríguez]

Hi,

more than 72 hours have passed and we have 3 binding votes from:

* David Vittor
* Dirk Frederickx
* Juan Pablo Santos

so the vote passes :-D I'll proceed with the release of 2.11.0


best regards,
juan pablo

On Sun, Nov 21, 2021 at 8:35 PM Dirk Frederickx 
wrote:

> +1
>
>
>
> On Fri, Nov 19, 2021 at 3:03 AM David Vittor  wrote:
>
> > +1
> >
> > On Fri, Nov 19, 2021 at 10:54 AM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> > > my +1
> > >
> > >
> > > best regards,
> > > jp
> > >
> > > On Fri, Nov 19, 2021 at 12:51 AM Juan Pablo Santos Rodríguez <
> > > juanpa...@apache.org> wrote:
> > >
> > > > This is a release vote for Apache JSPWiki, version 2.11.0. The vote
> > will
> > > > be open for at least 72 hours from now.
> > > >
> > > > It fixes the following issues:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12345152
> > > >
> > > > You can see a curated changelog at
> > > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
> > > >
> > > > Note that we are voting upon the source (tag), binaries are provided
> > for
> > > > convenience.
> > > >
> > > > Everybody is encouraged to vote.
> > > >
> > > > Source and binary files:
> > > > https://dist.apache.org/repos/dist/dev/jspwiki/2.11.0-RC2
> > > >
> > > > Nexus staging repo:
> > > >
> > https://repository.apache.org/content/repositories/orgapachejspwiki-1023
> > > >
> > > > The tag to be voted upon:
> > > > https://github.com/apache/jspwiki/tree/2.11.0-RC2
> > > >
> > > > JSPWiki's KEYS file containing PGP keys we use to sign the release:
> > > > https://www.apache.org/dist/jspwiki/KEYS
> > > >
> > > > *** Please download, test and vote:
> > > >
> > > > [ ] +1 Approve the release
> > > > [ ]  0 Don't mind
> > > > [ ] -1 Disapprove the release (please provide specific comments)
> > > >
> > >
> >
>

Re: [VOTE] Release JSPWiki version 2.11.0 (RC2)

[Juan Pablo Santos Rodríguez]

my +1


best regards,
jp

On Fri, Nov 19, 2021 at 12:51 AM Juan Pablo Santos Rodríguez <
juanpa...@apache.org> wrote:

> This is a release vote for Apache JSPWiki, version 2.11.0. The vote will
> be open for at least 72 hours from now.
>
> It fixes the following issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12345152
>
> You can see a curated changelog at
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11
>
> Note that we are voting upon the source (tag), binaries are provided for
> convenience.
>
> Everybody is encouraged to vote.
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/jspwiki/2.11.0-RC2
>
> Nexus staging repo:
> https://repository.apache.org/content/repositories/orgapachejspwiki-1023
>
> The tag to be voted upon:
> https://github.com/apache/jspwiki/tree/2.11.0-RC2
>
> JSPWiki's KEYS file containing PGP keys we use to sign the release:
> https://www.apache.org/dist/jspwiki/KEYS
>
> *** Please download, test and vote:
>
> [ ] +1 Approve the release
> [ ]  0 Don't mind
> [ ] -1 Disapprove the release (please provide specific comments)
>