Thanks. I forgot to my last mail that the output stack trace is indeed triggered by our own code (as you aready may have seen in the referenced code anyway).
On Tue, Jan 27, 2015 at 2:56 PM, Johan Mörén johan.moren@gmail.com wrote:
Hi i could for some reason not debug the Prop class. But i see that MainOptions.getClass().getProtectedDomain().getCodeSource() returns the String
wrap:mvn:org.basex/basex/8.0-SNAPSHOT$Export-Package=org.basex*;version=8.0&Bundle-SymbolicName=BaseX-8.0-SNAPSHOT
This is the command we use to install the BaseX library into our application server. The osgi-container Apache Karaf. I guess that this URL is later used but then the scheme "wrap" is not recognised.
Regards, Johan Mörén
On Mon Jan 26 2015 at 7:53:42 PM Christian Grün christian.gruen@gmail.com wrote:
Hi Johan,
I haven't come across this exception before. Maybe you can find out which value is bound to the LOCATION variable in your environment [1]?
Thanks in advance, Christian
[1] https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/ba...
On Mon, Jan 26, 2015 at 4:17 PM, Johan Mörén johan.moren@gmail.com wrote:
We run the script that uses this functionality embedded in a java application. I noticed now that the first time the code runs after a cold start. This log message appears.
java.nio.file.FileSystemNotFoundException: Provider "wrap" not installed at java.nio.file.Paths.get(Paths.java:147) at org.basex.util.Prop.homePath(Prop.java:142) at org.basex.util.Prop.<clinit>(Prop.java:96) at org.basex.core.StaticOptions.<clinit>(StaticOptions.java:20) at org.basex.core.Context.<init>(Context.java:77) at org.basex.core.Context.<init>(Context.java:69) at
se.kb.mimer.util.xquery.XQueryClient.extractPackageFilesData(XQueryClient.java:16) ....
The script still produces the expected output. I guess that this is a handled exception inside BaseX that get printed out to the log with INFO level. Am i right?
Regards, Johan
On Mon Jan 26 2015 at 2:24:41 PM Christian Grün christian.gruen@gmail.com wrote:
Hi Johan,
Just wanted to report back that it works really well.
Glad to hear it works.
It is about 50% slower than running the md5 command on the command line of my mac.
My final solution is close to the one you proposed [1]: I decided to use a little buffer as well, because it was faster than calling md.update() for each single byte.
Using nio channels gives us better performance:
String path = ... RandomAccessFile raf = new RandomAccessFile(path, "r"); FileChannel ch = raf.getChannel(); ByteBuffer buf = ByteBuffer.allocate(IO.BLOCKSIZE); final MessageDigest md = MessageDigest.getInstance("md5"); do { final int n = ch.read(buf); if(n == -1) break; md.update(buf.array(), 0, n); buf.flip(); } while(true); System.out.println(Token.string(Token.hex(md.digest(), true)));
But I am not sure how smoothly this would integrate in our remaining streaming architecture, as we are also streaming main-memory objects. I'll keep it in mind, though.
Cheers, Christian
[1]
https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/ba...