You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Murray Altheim <mu...@altheim.com> on 2022/08/09 02:50:02 UTC
Is 2.11.3 a drop-in replacement for 2.11.2?
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 <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: Is 2.11.3 a drop-in replacement for 2.11.2?
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
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 <mu...@altheim.com> 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 <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ ===
> ===
> = =
> ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
>
Re: Policy on matchEnglishPlurals?
Posted by Murray Altheim <mu...@altheim.com>.
On 2022/09/23 6:18, Juan Pablo Santos Rodríguez wrote:
> 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..
The matchEnglishPlurals feature is only meant for English wiki pages, but
given that the localisation of the wiki itself isn't actually taken into
account at all by the current code (i.e., the code for this isn't aware of
the localisation), this is clearly a setting that a wiki admin explicitly
makes understanding that their wiki is predominantly English. E.g., if the
wiki were in German with the flag set true it wouldn't work properly.
I hadn't thought about the notion of not conforming to the same rules as the
existing DefaultReferenceManager, not supporting the matchEnglishPlurals, or
supporting it differently. But the latter is not a bad alternative.
I can get almost all of the existing tests to pass, but not all. If I make
one slight change in the code the tests that didn't pass will pass, but that
breaks a different set of tests. This suggests that it might be either very
difficult or impossible to mimic the existing behaviour with a different
implementation, and of course any programmatic handling of English plurals
is never going to be 100% correct anyway. So I think I might aim for a
reasonable compromise and just call that Victory. I've spent probably too
much time on this already, as it's quite a difficult implementation and
there's still a fair bit of graph-related work to start.
Cheers,
Murray
> On Mon, Sep 19, 2022 at 10:22 AM Murray Altheim <mu...@altheim.com>
> 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.
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: Policy on matchEnglishPlurals?
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
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 <mu...@altheim.com>
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 <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ ===
> ===
> = =
> ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
>
Policy on matchEnglishPlurals?
Posted by Murray Altheim <mu...@altheim.com>.
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 <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
progress on GraphRenderingManager
Posted by Murray Altheim <mu...@altheim.com>.
Hi,
My last iteration of the GraphReferenceManager resulted in a manager far
too tightly wound into the existing JSPWiki code, where I had long ago
realised that the LinkManager (the actual manager that handles the
building and maintenance of the graph) really only needs to receive
WikiPageEvents.
The actual GraphReferenceManager would then no longer maintain the maps
of the existing DefaultReferenceManager, and effectively hand off its
functionality largely to the LinkManager in order to still comply with
the methods of the ReferenceManager API, and would effectively become
mostly an empty shell class, not doing much of anything. So my next
version will be quite a bit lighter in terms of hooks.
But I note that apart from modifying the contents of classmappings.xml
or classmappings-extra.xml, one thing I'd like to request is that the
functionality we currently have for several managers to configure the
choice of implementing class in jspwiki.properties be extended to the
ReferenceManager implementation. There'd seemingly be no downside to
this as the default would for most deployments be the existing class,
with this proposed configuration akin to:
jspwiki.referenceProvider = DefaultReferenceManager
This would be the sufficient hook I'd need to consider replacement of
the existing ReferenceManager (noting that my implementation is JDK 11
so I can't integrate it directly into jspwiki-main).
----
There would be a new enum for the various link types in the graph:
// not recognised as a link
INVALID("Invalid"),
// recognised as a link
INTERWIKI("Interwiki"),
IMAGE("Image"),
INTERNAL("Internal"),
EXTERNAL("External"),
ATTACHMENT("Attachment"),
UNCREATED("Uncreated"),
// parsed but not recognised as a link
ACCESS_RULE("AccessRule"),
PLUGIN("Plugin"),
METADATA("Metadata"),
VARIABLE("Variable");
[you may now understand my interest in the LinkParsingOperations class]
I've played with a variety of different JGraphT visualisations in the
jungrapht-visualization library for the default set of JSPWiki pages:
http://altheim.com/murray/yk/visualised.png
http://altheim.com/murray/yk/visualised-zoom.png
As part of this plan, there would be no "uncreated pages" any longer, as
all links-to-nowhere end up as fully-fledged graph nodes. So when a user
attempts to traverse to an uncreated page, the engine wouldn't simply
provide an edit link, it could also show the existing link sources.
The ability to traverse the graph from any node (at any depth, and
filtering on any link type) would provide a lot of additional
functionality.
Cheers,
Murray
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: ClassCastException on application reboot
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
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 <mu...@altheim.com> 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)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)
>
> ----
>
> Cheers,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ ===
> ===
> = =
> ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
>
ClassCastException on application reboot
Posted by Murray Altheim <mu...@altheim.com>.
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)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476)
----
Cheers,
Murray
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu