Hi,
In my ongoing attempts to use various Java libraries, without writing any Java myself, I have trying Apache Tika. (http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the tika jar on the classpath I hoped the following would work:
import module namespace tika = "java:org.apache.tika.Tika"; declare namespace File="java:java.io.File"; let $file :=File:new("xx.pdf") return tika:parse($file)
It generates the error Signature 'org.apache.tika.Tika.parse' is ambiguous
Which maybe it is from some perspectives :-). I hoped some type information might be available in the $file variable to resolve this, but it appears not. I was wondering about the possibility of using Java type at the XQuery level e.g. let $file as java:java.io.File :=File:new("xx.pdf")
Is there any way to avoid writing the couple of line Java class shim for this and similar cases?
Regards /Andy
Or maybe better with a pragma e.g.
return tika:parse( (# basex:java-type java:java.io.File #){$file} )
On Thu, Jan 2, 2014 at 5:42 PM, Andy Bunce bunce.andy@gmail.com wrote:
Hi,
In my ongoing attempts to use various Java libraries, without writing any Java myself, I have trying Apache Tika. (http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the tika jar on the classpath I hoped the following would work:
import module namespace tika = "java:org.apache.tika.Tika"; declare namespace File="java:java.io.File"; let $file :=File:new("xx.pdf") return tika:parse($file)
It generates the error Signature 'org.apache.tika.Tika.parse' is ambiguous
Which maybe it is from some perspectives :-). I hoped some type information might be available in the $file variable to resolve this, but it appears not. I was wondering about the possibility of using Java type at the XQuery level e.g. let $file as java:java.io.File :=File:new("xx.pdf")
Is there any way to avoid writing the couple of line Java class shim for this and similar cases?
Regards /Andy
Yet another solution (probably the one I prefer) would be to write your own Java class, exposing exactly the API you need, taking care of the interface between XQuery and Java, and deferring actual hard work to the library.
Regards,
Yes and I have now done that for this case. However when prototyping it is sometimes nice to quickly try things out to see what might work without the burden of firing up a Java IDE, managing the source etc.
Regards /Andy
On Fri, Jan 3, 2014 at 11:05 AM, Florent Georges fgeorges@fgeorges.orgwrote:
Yet another solution (probably the one I prefer) would be to write your own Java class, exposing exactly the API you need, taking care of the interface between XQuery and Java, and deferring actual hard work to the library.
Regards,
-- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
On 3 January 2014 11:25, Andy Bunce wrote:
Or maybe better with a pragma e.g.
return tika:parse( (# basex:java-type java:java.io.File #){$file} )
On Thu, Jan 2, 2014 at 5:42 PM, Andy Bunce bunce.andy@gmail.com wrote:
Hi,
In my ongoing attempts to use various Java libraries, without writing
any
Java myself, I have trying Apache Tika. (http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the
tika
jar on the classpath I hoped the following would work:
import module namespace tika = "java:org.apache.tika.Tika"; declare namespace File="java:java.io.File"; let $file :=File:new("xx.pdf") return tika:parse($file)
It generates the error Signature 'org.apache.tika.Tika.parse' is ambiguous
Which maybe it is from some perspectives :-). I hoped some type information might be available in the $file variable to resolve this,
but it
appears not. I was wondering about the possibility of using Java type at the XQuery level e.g. let $file as java:java.io.File :=File:new("xx.pdf")
Is there any way to avoid writing the couple of line Java class shim for this and similar cases?
Regards /Andy
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Hi Andy,
It generates the error Signature 'org.apache.tika.Tika.parse' is ambiguous
Which maybe it is from some perspectives :-).
In the latest snapshot, I have updated the error feedback to:
Several implementations found for 'Q{org.apache.tika.Tika}parse#1'.
But a better solution would be to choose the function that comes closest to the given XQuery arguments. It won’t be possible to find a mapper that meets all requirements (and past versions of BaseX have demonstrated that this is a difficult problem), but Michael Kay has also put lots of thoughts on this [1], and we could check if his distance calculations could also be applied to the BaseX java mapper.
For now, it’s in fact best to go with the additional Java indirection layer.
Christian
[1] http://www.saxonica.com/documentation/extensibility/functions/choosing-overl...
I hoped some type information might be available in the $file variable to resolve this, but it appears not. I was wondering about the possibility of using Java type at the XQuery level e.g. let $file as java:java.io.File :=File:new("xx.pdf")
Is there any way to avoid writing the couple of line Java class shim for this and similar cases?
Regards /Andy
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
basex-talk@mailman.uni-konstanz.de
-
Andy Bunce -
Christian Grün -
Florent Georges