Error "Cannot find module class from EXPath repository" when starting previous monex 0.9.6 installation under eXist 3.1.1
Closed this issue · 6 comments
I've encountered the same glitch on two machines when opening monex for the first time after starting eXist 3.1.1 on an existing database (initialized under 3.1.0) where monex 0.9.6 had been installed. I got this error when starting monex (via http://localhost:8080/exist/apps/monex/index.html):
/db/apps/monex/modules/view.xqlexerr:ERROR error found while loading module indexes: Error while loading module indexes.xqm: error found while loading module console: Cannot find module class from EXPath repository: org.exist.console.xquery.ConsoleModule
The default package manager tells me 0.9.6 is installed, and the 0.9.6 jars are on disk:
$ cd /Users/joe/Library/Application Support/org.exist/expathrepo/monex-0.9.6
$ ls content
exist-monex-0.9.6.jar websocket-api-9.3.9.v20160517.jar websocket-server-9.3.9.v20160517.jar
jetty-util-ajax-9.3.9.v20160517.jar websocket-common-9.3.9.v20160517.jar websocket-servlet-9.3.9.v20160517.jar
monex's modules/indexes.xqm imports the module here: https://github.com/wolfgangmm/monex/blob/master/modules/indexes.xqm#L15
Restarting the database doesn't help. The only thing that fixes the issue is installing monex again (I installed 0.9.7, since this update was available in the package manager).
At the same time, the following query returns true():
xquery version "3.1";
some $module in util:registered-modules() satisfies $module eq "http://exist-db.org/xquery/console"I wonder why 3.1.1 would fail to recognize java modules installed under 3.1.0?
Some more tests:
xquery version "3.1";
import module namespace console = "http://exist-db.org/xquery/console" at "java:org.exist.console.xquery.ConsoleModule";
console:log("blah")This query raises the same exerr:ERROR error:
Cannot compile xquery: exerr:ERROR error found while loading module console: Cannot find module class from EXPath repository: org.exist.console.xquery.ConsoleModule
Adding the at clause raises a different error:
xquery version "3.1";
import module namespace console = "http://exist-db.org/xquery/console" at "java:org.exist.console.xquery.ConsoleModule";
console:log("blah")Cannot compile xquery: err:XPST0081 No namespace defined for prefix console [at line 5, column 1]
we had this issue when moving an instance (v 3.1.1) and it is propably because of the files
webapp/WEB-INF/data/fs/db/apps/monex/.exist/classpath.txt
webapp/WEB-INF/data/expathrepo/monex-0.9.7/.exist/classpath.txt
which contians absolute pathes to the jar files. it is not possible to move an instance right now.
(please give me an hint, when i should open a new issue for this, but it seems to be the same symptom here)
@mathias-goebel Hmm, I'm not sure that would cause the issue here. I'm working with the macOS DMG installer, which puts the data directory outside the typical $EXIST_HOME/webapp/WEB-INF directory, in ~/Library/Application Support/org.exist. This has the advantage of allowing upgrades of the application binaries while keeping the database as is (without backup/restore). So I would expect the two files you cited to still refer to the monex 0.9.6 editions of the jars.
When you say "it is not possible to move an instance", are you saying that you're trying to move the EXIST_HOME directory from one location on disk (or computer) to another? I can see how these absolute paths could make that difficult. I think eXist's expathrepo system is responsible for that absolute path phenomenon, so probably best to file an issue in the main exist repo for that. Have you tried backup/restore? I wonder if that process accounts for the change in path/context.
ok, thanks.
yes i tried to move the folder on the local machine.
i started eXist-db/exist#1382
I just found this in webapp/WEB-INF/logs/expath-repo.log from the other night when I observed this on the 2nd machine:
2017-03-23 00:57:44,814 [Thread-3] DEBUG (Logger.java [fine]:38) - Trying to resolve 'expath-pkg.xml' within '/Users/joe/Library/Application Support/org.exist/expathrepo/monex-0.9.6'
2017-03-23 00:57:44,816 [Thread-3] TRACE (Logger.java [finer]:33) - Content dir '/Users/joe/Library/Application Support/org.exist/expathrepo/monex-0.9.6/content' (exists:true/isdir:true), and '/Users/joe/Library/Application Support/org.exist/expathrepo/monex-0.9.6/monex' (exists:false/isdir:false)
2017-03-23 00:57:44,934 [Thread-3] DEBUG (Logger.java [fine]:38) - Trying to resolve 'exist.xml' within '/Users/joe/Library/Application Support/org.exist/expathrepo/monex-0.9.6'
2017-03-23 00:57:44,936 [Thread-3] DEBUG (Logger.java [fine]:38) - Trying to resolve '.exist/classpath.txt' within '/Users/joe/Library/Application Support/org.exist/expathrepo/monex-0.9.6'
2017-03-23 00:57:44,949 [Thread-3] WARN (ClasspathHelper.java [scanPackages]:90) - Package http://exist-db.org/apps/monex is not compatible with this version of eXist. To avoid conflicts, Java libraries shipping with this package are not loaded.
2017-03-23 00:57:47,173 [Thread-3] INFO (Deployment.java [installAndDeploy]:191) - Application package http://exist-db.org/apps/monex already installed. Skipping.
I think the key bit here is:
http://exist-db.org/apps/monex is not compatible with this version of eXist. To avoid conflicts, Java libraries shipping with this package are not loaded
This led me to inspect monex's expath-pkg.xml from 0.9.6:
<dependency processor="http://exist-db.org" semver-min="3.0.2" semver-max="3.1.0"/>So as soon as eXist 3.1.1 tried to start up and found monex was only compatible with versions 3.0.2-3.1.0, eXist refused to load it.
I think this explains the problem.
Solutions:
- Monex-specific: Shall we change semver-max to eXist 3.99.99 (or something just beneath 4.0), since according to the semver principles, the only changes to 3.x will be bug fixes and improvements, but no API changes?
- eXist: Is there any way eXist do a better job reporting to the user what packages weren't loaded due to version dependencies? Is there some way we can lead users to take the necessary action?
since 0.9.8 no longer includes the semver-max value. I think its good to close this here?