Hi,
It probably has been asked before but I found nothing on this topic.
Whenever I try to start basex or basexclient on my Fedora 31 linux distribution, I get this output:
BaseX 9.3.1 [Client] Probeer 'help' om informatie te krijgen. [ERROR] Failed to construct terminal; falling back to unsupported java.lang.NumberFormatException: For input string: "0x100" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:580) at java.lang.Integer.valueOf(Integer.java:766) at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59) at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:233) at jline.UnixTerminal.<init>(UnixTerminal.java:64) at jline.UnixTerminal.<init>(UnixTerminal.java:49) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at jline.TerminalFactory.getFlavor(TerminalFactory.java:209) at jline.TerminalFactory.create(TerminalFactory.java:100) at jline.TerminalFactory.get(TerminalFactory.java:184) at jline.TerminalFactory.get(TerminalFactory.java:190) at jline.console.ConsoleReader.<init>(ConsoleReader.java:240) at jline.console.ConsoleReader.<init>(ConsoleReader.java:232) at jline.console.ConsoleReader.<init>(ConsoleReader.java:220) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.basex.util.ConsoleReader$JLineConsoleReader.<init>(ConsoleReader.java:146) at org.basex.util.ConsoleReader.get(ConsoleReader.java:55) at org.basex.BaseX.console(BaseX.java:166) at org.basex.BaseX.<init>(BaseX.java:152) at org.basex.BaseXClient.<init>(BaseXClient.java:35) at org.basex.BaseXClient.main(BaseXClient.java:22)
'basex help' gives this output:
Gestopt bij /home/bengbers/, 1/5: [XPDY0002] element(help): Context is undeclared.
Am I missing something?
Cheers, Ben
On Mon, Feb 10, 2020 at 11:47:55AM +0100, Ben Engbers scripsit:
Whenever I try to start basex or basexclient on my Fedora 31 linux distribution, I get this output:
[error message snipped]
Am I missing something?
I'm having no issues on Fedora 31, so I can at least say it's not inherent to the distro. But then again I'm using the gui; let's check.
08:03 bin % ./basex /home/graydon/bin/basex/basex/.basex: writing new configuration file. BaseX 9.3.1 [Standalone] Try 'help' to get more information.
That's from inside the basex bin directory.
How are you installing basex? I always use the zip version and just unpack it in $HOME/bin. Does the gui -- initialized from the basexgui script -- run for you?
-- Graydon
Op 10-02-2020 om 14:07 schreef Graydon:
On Mon, Feb 10, 2020 at 11:47:55AM +0100, Ben Engbers scripsit:
Whenever I try to start basex or basexclient on my Fedora 31 linux distribution, I get this output:
[error message snipped]
Am I missing something?
I'm having no issues on Fedora 31, so I can at least say it's not inherent to the distro. But then again I'm using the gui; let's check.
The GUI works fine (always has). It was only last week that I first had to use the basexclient.
08:03 bin % ./basex /home/graydon/bin/basex/basex/.basex: writing new configuration file. BaseX 9.3.1 [Standalone] Try 'help' to get more information.
That's from inside the basex bin directory.
How are you installing basex? I always use the zip version and just unpack it in $HOME/bin. Does the gui -- initialized from the basexgui script -- run for you?
-- Graydon
I added the directory, containing basex/bin, to my path. 'basexserver &', 'basexserver stop' and 'basexserverstop' execute without returning errors. This is the output from basexhttp (this is the first time I tried this):
BaseX 9.3.1 [HTTP Server] SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/bengbers/Programs/basex/lib/slf4j-simple-1.7.26.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/bengbers/Programs/basex/lib/slf4j-simple-1.7.13.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/bengbers/Programs/basex/lib/slf4j-simple-1.7.28.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/bengbers/Programs/basex/lib/slf4j-simple-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory] [main] INFO org.eclipse.jetty.util.log - Logging initialized @432ms to org.eclipse.jetty.util.log.Slf4jLog [main] INFO org.eclipse.jetty.util.TypeUtil - JVM Runtime does not support Modules java.lang.UnsupportedOperationException
Did you add something to CLASSPATH?
Ben
On Mon, Feb 10, 2020 at 02:28:08PM +0100, Ben Engbers scripsit:
Op 10-02-2020 om 14:07 schreef Graydon:
[snip]
The GUI works fine (always has). It was only last week that I first had to use the basexclient.
So we may suppose you have a good copy.
[big snip]
Did you add something to CLASSPATH?
I have not. (And indeed appear to have no local CLASSPATH value at all.)
Generally doing things to CLASSPATH with containerized Java programs seems to be a way to cause chaos because now the containerized app doesn't know what it's loading. (This view may be a function of me not knowing very much about Java.)
What it looks like you've got going on is a situation where basex uses modules and the java it's getting doesn't, but that doesn't explain why the gui runs fine. It makes me suspect that you're having an interaction with httpd somehow.
-- Graydon
Op 10-02-2020 om 14:59 schreef Graydon:
On Mon, Feb 10, 2020 at 02:28:08PM +0100, Ben Engbers scripsit:
What it looks like you've got going on is a situation where basex uses modules and the java it's getting doesn't, but that doesn't explain why the gui runs fine. It makes me suspect that you're having an interaction with httpd somehow.
-- Graydon
The only thing that might use hhtpd somehow, is my RBaseX-package (I have again rewritten large portions, cleaned up the classes, added tests and so on). I can't think of anything else that uses httpd. And even after rebooting, basex/basexclient still give errors.
What else should I try?
Ben
On Mon, Feb 10, 2020 at 03:32:07PM +0100, Ben Engbers scripsit:
What else should I try?
In general, it looks like this is your environment rather than the package, but it'd be nice to be able to prove it.
Grab a fresh copy of current stable basex via the zip archive, unpack that in some other directory entirely -- ideally belonging to a different user, no reason you can't create a test user if you have root on the machine -- and see what it does there?
-- Graydon (who will admit to being rather baffled)
Op 10-02-2020 om 15:40 schreef Graydon:
In general, it looks like this is your environment rather than the package, but it'd be nice to be able to prove it.
Grab a fresh copy of current stable basex via the zip archive, unpack that in some other directory entirely -- ideally belonging to a different user, no reason you can't create a test user if you have root on the machine -- and see what it does there?
-- Graydon (who will admit to being rather baffled)
I created a new user, copied and unpacked Basex931.zip. Out of the box, everything works fine. :-)
I switched back to my personal account. There I get the same errors as before ;-(. What surprises me however is that despite the errors, basex is fully operational.
So you are right, it is my environment that causes the error.
The only real difference between regular and test-account, is that for the regular account, I have added in CLASSPATH an entry for lucene-stemmers-3.4.0.jar
Could it be that this jar causes the error?
Ben
On Tue, Feb 11, 2020 at 10:01:42AM +0100, Ben Engbers scripsit: [snip -- weirdness is the environment, rather than BaseX]
The only real difference between regular and test-account, is that for the regular account, I have added in CLASSPATH an entry for lucene-stemmers-3.4.0.jar
Could it be that this jar causes the error?
That is a question for the nice folks at BaseX!
My guess -- stress "guess" -- is that lucene-stemmers is presumably Apache Lucene, which BaseX might well use -- writing your own stemmer seems like unnecessary suffering, and BaseX does do word stemming as part of the full-text capability -- and since current Apache Lucene is version 8.4.1 -- https://lucene.apache.org/ -- it seems likely you could be running into an error between a Lucene that BaseX expects to be using and the (way-old) version 3.4.0 on the CLASSPATH getting loaded instead.
But I don't know.
Can you take lucene-stemmers-3.4.0.jar off your CLASSPATH and see what happens?
-- Graydon
Op 11-02-2020 om 13:05 schreef Graydon:
My guess -- stress "guess" -- is that lucene-stemmers is presumably Apache Lucene, which BaseX might well use -- writing your own stemmer seems like unnecessary suffering, and BaseX does do word stemming as part of the full-text capability -- and since current Apache Lucene is version 8.4.1 -- https://lucene.apache.org/ -- it seems likely you could be running into an error between a Lucene that BaseX expects to be using and the (way-old) version 3.4.0 on the CLASSPATH getting loaded instead.
But I don't know.
Can you take lucene-stemmers-3.4.0.jar off your CLASSPATH and see what happens?
-- Graydon
If you want to use stemming in Dutch (as I do), http://docs.basex.org/wiki/Full-Text tells that in addition to the already present stemming-support, you have to add http://files.basex.org/maven/org/apache/lucene-stemmers/3.4.0/lucene-stemmer... to your CLASSPATH. I have removed that jar from the CLASSPATH but that didn't make any difference. At a later time, I'll gradually will remove all java-stuff from my PATH and see what happens.
Ben
Hi Ben (and thanks Graydon),
the Lucene jar file is just a harmless library that consists of some stemmers without additional dependencies.
As it has already been assumed, the errors must arise from custom settings in the local system; I have no immediate idea what that could be.
Cheers, Christian
On Tue, Feb 11, 2020 at 1:56 PM Ben Engbers Ben.Engbers@be-logical.nl wrote:
Op 11-02-2020 om 13:05 schreef Graydon:
My guess -- stress "guess" -- is that lucene-stemmers is presumably Apache Lucene, which BaseX might well use -- writing your own stemmer seems like unnecessary suffering, and BaseX does do word stemming as part of the full-text capability -- and since current Apache Lucene is version 8.4.1 -- https://lucene.apache.org/ -- it seems likely you could be running into an error between a Lucene that BaseX expects to be using and the (way-old) version 3.4.0 on the CLASSPATH getting loaded instead.
But I don't know.
Can you take lucene-stemmers-3.4.0.jar off your CLASSPATH and see what happens?
-- Graydon
If you want to use stemming in Dutch (as I do), http://docs.basex.org/wiki/Full-Text tells that in addition to the already present stemming-support, you have to add http://files.basex.org/maven/org/apache/lucene-stemmers/3.4.0/lucene-stemmer... to your CLASSPATH. I have removed that jar from the CLASSPATH but that didn't make any difference. At a later time, I'll gradually will remove all java-stuff from my PATH and see what happens.
Ben
basex-talk@mailman.uni-konstanz.de
-
Ben Engbers -
Christian Grün -
Graydon