I have a problem with the full text search database generation in javaHelp. In order to generate the db I have to execute a command from a batch file:
java -cp jhall.jar com.sun.java.help.search.Indexer -db .\JavaHelpSearch .\html
This only works if the batch file is in the same directory of the html directory containing the files to index. I have tried to execute the batch file from an external location using absolute paths:
java -cp jhall.jar com.sun.java.help.search.Indexer -db C:\help\JavaHelpSearch C:\help\html
The db generation give no erros, but if I search a word in the javaHelp window I get the following error:
Failed to create URL from file:/C:/help/myHelp.hs|C:/help/html/myhtml.html
I have spent a lot of time facing this problem, without success. What I really need is to call the Indexer class directly from my Java application, but the same problem happens there.
Related
I'm trying to automate the build process of my Scala application for producing a msi installer.
When doing so, windows claims that certain files cannot be found. Here is the command that gets run
[21:39:01.842] Running C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe in C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage6105194214114584024\images\win-msi.image\krystalbull
and further down, i start seeing errors like this:
C:\Users\runneradmin\AppData\Local\Temp\jdk.jpackage6105194214114584024\config\bundle.wxf(56) : error LGHT0103 : The system cannot find the file 'C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage6105194214114584024\images\win-msi.image\krystalbull\app\classes\com\krystal\bull\gui\FileMenu$anon$2.class'.
C:\Users\runneradmin\AppData\Local\Temp\jdk.jpackage6105194214114584024\config\bundle.wxf(71) : error LGHT0103 : The system cannot find the file 'C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage6105194214114584024\images\win-msi.image\krystalbull\app\classes\com\krystal\bull\gui\dialog\ViewEventDialog$anon$10$anon$21$anonfun$lessinit$greater$1.class'.
C:\Users\runneradmin\AppData\Local\Temp\jdk.jpackage6105194214114584024\config\bundle.wxf(81) : error LGHT0103 : The system cannot find the file 'C:\Users\RUNNER~1\AppData\Local\Temp\jdk.jpackage6105194214114584024\images\win-msi.image\krystalbull\app\classes\com\krystal\bull\gui\SettingsMenu$anon$5.class'.
You can see more instances of this error in the build log here:
https://github.com/bitcoin-s/krystal-bull/runs/2697961906?check_suite_focus=true#step:8:11
My question is this:
What are the limitations in the windows file system or the program candle.exe that prevent the pre-processor from reading Scala files that include things like $anon$
Is there a valid syntax guide somewhere?
Will I need to manually rename all of these files?
I have successfully crawled a website using Nutch and now I want to create a warc from the results. However, running both the warc and commoncrawldump commands fail. Also, running bin/nutch dump -segement .... works successfully on the same segment folder.
I am using nutch v-1.17 and running:
bin/nutch commoncrawldump -outputDir output/ -segment crawl/segments
The error from hadoop.log is ERROR tools.CommonCrawlDataDumper - No segment directories found in my/path/
despite having just ran a crawl there.
Inside the segments folder were segments from a previous crawl that were throwing up the error. They did not contain all the segment data as I believe the crawl was cancelled/finished early. This caused the entire process to fail. Deleting all those files and starting anew fixed the issue.
I have an OpenShift origin (OKD) cluster setup on AWS. Jenkins being used for CICD pipeline deployment. Based in OpenShift docs, I am trying to use Source to Image (S2I) to convert my Java source code to image using redhat-openjdk-18/openjdk18-openshift image. I used following commands
Create new build
$ oc new-build --binary=true --name=bookstore --image-stream=openjdk18-openshift
--> Found image 24d98bd (7 days old) in image stream "cicd/openjdk18-openshift" under tag "latest" for "openjdk18-openshift"
Java Applications
-----------------
Platform for building and running plain Java applications (fat-jar and flat classpath)
Tags: builder, java
* A source build using binary input will be created
* The resulting image will be pushed to image stream "bookstore:latest"
* A binary build was created, use 'start-build --from-dir' to trigger a new build
--> Creating resources with label build=bookstore ...
imagestream "bookstore" created
buildconf
Start Build
$ oc start-build bookstore --from-dir=./ocp --follow
Uploading directory "ocp" as binary input for the build ...
build "bookstore-1" started
Receiving source from STDIN as archive ...
pulling image error : open /etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such file or directory
error: build error: unable to get registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift#sha256:38dab2c3f60ade6857cc2a592184c964d3a51e2d3b5ef07def4b8ad4215d2bbf
As shown above, I get build error: unable to get registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift error while running the start-build command.
Thanks, Graham for the input. I was able to solve this by creating empty file on all nodes (master and worker) nodes
$ sudo vi /etc/rhsm/ca/redhat-uep.pem
I have two machines named: ubuntu1 and ubuntu2.
In ubuntu1, I started the master node in Spark Standalone Cluster and ubuntu2 I started with a worker (slave).
I am trying to execute the example workCount available on github.
When I submit the application, the worker send an error message
java.io.FileNotFoundException: File file:/home/ubuntu1/demo/test.txt does not exist.
My command line is
./spark-submit --master spark://ubuntu1-VirtualBox:7077 --deploy-mode cluster --clas br.com.wordCount.App -v --name"Word Count" /home/ubuntu1/demo/wordCount.jar /home/ubuntu1/demo/test.txt
The file test.txt has only to stay in one machine ?
Note: The master and the worker are in different machine.
Thank you
I got the same problem while loading the JSON file. I recognized by default windows storing file format as Textfile regardless of the name. identify the file format then you can load easily.
example: think you saved the file as test.JSON. but by default windows adding .txt to it.
check that and try to run again.
I hope your problem will get resolved with this idea.
Thank you.
You should put your file on hdfs by going to the folder and typing :
hdfs dfs -put <file>
Otherwise each node has to have access to it by having the same path folder existing on each machine.
Don't forget to change file:/ to hdfs:/ after you do that
I have been trying to use a home grown test tool and after doing an update to Centos 6.4, I am no longer able to run the tcl based tool. I am getting the following error and I have no internet access on this server. Kindly advise how do I solve this problem?
Thanks
"XpUtils::iload -d /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1 tclblend" failed:
couldn't load file "/usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1/libtclblend.so": libjava.so: cannot open shared object file: No such file or directory
while executing
"error "\"XpUtils::iload -d $dir tclblend\" failed:\n $errMsg""
(procedure "loadtclblend" line 168)
invoked from within
"loadtclblend /usr/local/testtool/repo/package/linux-glibc2.3-x86_64/lib/tcljava1.4.1"
("package ifneeded java 1.4.1" script)
invoked from within
"package require java"
("eval" body line 1)
invoked from within
"eval package require $pkg"
("foreach" body line 2)
invoked from within
"foreach pkg $pkgList {
set ::${pkg}Version [eval package require $pkg]
}"
(file "/usr/local/testtool/testtool" line 165)
If you read the error message trace, you'll see that it says that this is all caused by:
libjava.so: cannot open shared object file: No such file or directory
The first steps would then be to ensure that you've got a version of Java actually installed, to check that it includes the file libjava.so, and that the file has been indexed by the system shared library catalog.
It might also be worth checking that all its dependencies are also present and that you've got the architecture for the Tcl library and the Java library matched (e.g., both 32-bit) as those can cause odd failures when they go wrong.