You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Claude Warren <cl...@xenei.com> on 2013/04/03 00:14:53 UTC
same code returns 2 different readers
I am running some test cases.
When I run the tests (TestReaderEvent) from within Jean (2.10.1) it works
fine. When I run it using the testing jar from a different project (using
the same setup) it does not.
Under Jena 2.10.1 The call calls are:
model.getReader("N-TRIPLE")
ModelCom.getReader("N-TRIPLE")
RDFReaderFImpl.getReader("N-TRIPLE")
String className = langToClassName.getProperty(lang) returns
"com.hp.hpl.jena.rdf.model.impl.NTripleReader"
under a different project the calls are:
model.getReader("N-TRIPLE")
ModelCom.getReader("N-TRIPLE")
RDFReaderFImpl.getReader("N-TRIPLE")
String className = langToClassName.getProperty(lang) returns
"com.hp.hpl.jena.n3.N3JenaWriter.JenaReadersWriters$RDFReaderRIOT_TTL"
>From what I can gather the reader class names are loaded in an
RDFReaderFImpl static block:
static { // static initializer - set default readers
langToClassName = new Properties();
for (int i = 0; i<LANGS.length; i++) {
langToClassName.setProperty(
LANGS[i],
JenaRuntime.getSystemProperty(PROPNAMEBASE +
LANGS[i],
DEFAULTREADERS[i]));
}
}
The only thing I can figure is taht the JenaRuntime.getSystemProperty() is
returning a different value, but in debugging it is simpley calling
System.getProperty( propName, default) and returning that value (no
exception thrown).
Does anybody have any idea why this is happening and what I need to do to
get both sets of code to use the
com.hp.hpl.jena.rdf.model.impl.NTripleReader as the other reader does not
pass the tests.
Thanks,
Claude
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: same code returns 2 different readers
Posted by Claude Warren <cl...@xenei.com>.
Checking back the mappings are:
N3 -> JenaReadersWriters$RDFReaderRIOT_TTL
N-TRIPLE -> JenaReadersWriters$RDFReaderRIOT_NT
RDF/XML -> JenaReadersWriters$RDFReaderRIOT_RDFXML
So TTL for N-TRIPLE was a typo.
-- Claude
On Thu, Apr 4, 2013 at 1:34 PM, Claude Warren <cl...@xenei.com> wrote:
> Thanks for the quick response.
>
> I suspect the TTL for N-TRIPLE was a typo. I will delve into it again
> this evening but I think we can assume that the issue is closed.
>
> -- Claude
>
>
> On Thu, Apr 4, 2013 at 1:19 PM, Andy Seaborne <an...@apache.org> wrote:
>
>> (from memory) The TestReaderEvent tests that read start and read end
>>> markers are recorded in the listeners. The RIOT reader is not doing
>>> this.
>>>
>>
>> You're right - except for RDF/XML (where the intergration is inverted,
>> RIOt wrappers an old style Jena reader) it is not sending events. Now,
>> "was" - fixed.
>>
>> Your test case passes for me now.
>>
>>
>> I suppose I should build a test for the reader implementations that will
>>> test this functionality.
>>>
>>
>> > Attached is a minimal test case example.
>>
>>>
>>> The archive contains a java test as well as a pom.xml
>>>
>>> If the ARQ is included in the POM the tests fail, if the ARQ is not in
>>> the POM the tests pass.
>>>
>>
>> In your original message you said that you were getting the TTL reader
>> for NT. Was that just a typo? and now
>>
>>
>> ModelCom.getReader("N-TRIPLE")
>> RDFReaderFImpl.getReader("N-**TRIPLE")
>> String className = langToClassName.getProperty(**lang) returns
>> "com.hp.hpl.jena.n3.**N3JenaWriter.**JenaReadersWriters$**
>> RDFReaderRIOT_TTL"
>>
>> been sorted out?
>>
>> A) The class name is wrong
>> B) It's not an N-Triples syntax reader.
>>
>> Andy
>>
>>
>>> -- Claude
>>>
>>
>>
>
>
> --
> I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
> Identity: https://www.identify.nu/user.php?claude@xenei.com
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: same code returns 2 different readers
Posted by Claude Warren <cl...@xenei.com>.
Thanks for the quick response.
I suspect the TTL for N-TRIPLE was a typo. I will delve into it again this
evening but I think we can assume that the issue is closed.
-- Claude
On Thu, Apr 4, 2013 at 1:19 PM, Andy Seaborne <an...@apache.org> wrote:
> (from memory) The TestReaderEvent tests that read start and read end
>> markers are recorded in the listeners. The RIOT reader is not doing this.
>>
>
> You're right - except for RDF/XML (where the intergration is inverted,
> RIOt wrappers an old style Jena reader) it is not sending events. Now,
> "was" - fixed.
>
> Your test case passes for me now.
>
>
> I suppose I should build a test for the reader implementations that will
>> test this functionality.
>>
>
> > Attached is a minimal test case example.
>
>>
>> The archive contains a java test as well as a pom.xml
>>
>> If the ARQ is included in the POM the tests fail, if the ARQ is not in
>> the POM the tests pass.
>>
>
> In your original message you said that you were getting the TTL reader for
> NT. Was that just a typo? and now
>
>
> ModelCom.getReader("N-TRIPLE")
> RDFReaderFImpl.getReader("N-**TRIPLE")
> String className = langToClassName.getProperty(**lang) returns
> "com.hp.hpl.jena.n3.**N3JenaWriter.**JenaReadersWriters$**
> RDFReaderRIOT_TTL"
>
> been sorted out?
>
> A) The class name is wrong
> B) It's not an N-Triples syntax reader.
>
> Andy
>
>
>> -- Claude
>>
>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: same code returns 2 different readers
Posted by Andy Seaborne <an...@apache.org>.
> (from memory) The TestReaderEvent tests that read start and read end
> markers are recorded in the listeners. The RIOT reader is not doing this.
You're right - except for RDF/XML (where the intergration is inverted,
RIOt wrappers an old style Jena reader) it is not sending events. Now,
"was" - fixed.
Your test case passes for me now.
> I suppose I should build a test for the reader implementations that will
> test this functionality.
> Attached is a minimal test case example.
>
> The archive contains a java test as well as a pom.xml
>
> If the ARQ is included in the POM the tests fail, if the ARQ is not in
> the POM the tests pass.
In your original message you said that you were getting the TTL reader
for NT. Was that just a typo? and now
ModelCom.getReader("N-TRIPLE")
RDFReaderFImpl.getReader("N-TRIPLE")
String className = langToClassName.getProperty(lang) returns
"com.hp.hpl.jena.n3.N3JenaWriter.JenaReadersWriters$RDFReaderRIOT_TTL"
been sorted out?
A) The class name is wrong
B) It's not an N-Triples syntax reader.
Andy
>
> -- Claude
Re: same code returns 2 different readers
Posted by Claude Warren <cl...@xenei.com>.
Attached is a minimal test case example.
The archive contains a java test as well as a pom.xml
If the ARQ is included in the POM the tests fail, if the ARQ is not in the
POM the tests pass.
-- Claude
Re: same code returns 2 different readers
Posted by Claude Warren <cl...@xenei.com>.
I was running this in my local copy of the Jena 2.10.1
code immediately after synchronizing with the repository, so it should be
the most recent code.
I'll check again tonight. Perhaps I copied the file names from the wrong
tests.
I'll create a simple example this evening. -- there really is not much to
it since most of the code is in the Jena core test code base.
Just to be clear in my mind. NTripleReader is the older code and
JenaReadersWriters$**RDFReaderRIOT_TTL (while it is the wrong reader) is
the newer code.
I am beginning to think that TestReaderEvent should also be run against the
readers to ensure that they are correctly reporting events. Perhaps it
does not belong on the model test at all.
-- Claude
On Wed, Apr 3, 2013 at 8:48 AM, Andy Seaborne <an...@apache.org> wrote:
> Hi Claude,
>
> On 02/04/13 23:14, Claude Warren wrote:
>
>> I am running some test cases.
>>
>> When I run the tests (TestReaderEvent) from within Jean (2.10.1) it works
>> fine. When I run it using the testing jar from a different project (using
>> the same setup) it does not.
>>
>>
> The latest snapshot build of 2.10.1? Things will have changed in this
> area when the new writers were integrated into the codebase and subsequent
> clearing up.
>
>
> Under Jena 2.10.1 The call calls are:
>> model.getReader("N-TRIPLE")
>> ModelCom.getReader("N-TRIPLE")
>> RDFReaderFImpl.getReader("N-**TRIPLE")
>> String className = langToClassName.getProperty(**lang) returns
>> "com.hp.hpl.jena.rdf.model.**impl.NTripleReader"
>>
>
> jena-arq is not on the classpath (the new readers are current on jena-arq
> while the old ones are still around, initialized via reflection in IO_Ctl)
>
>
>
>> under a different project the calls are:
>> model.getReader("N-TRIPLE")
>> ModelCom.getReader("N-TRIPLE")
>> RDFReaderFImpl.getReader("N-**TRIPLE")
>> String className = langToClassName.getProperty(**lang) returns
>> "com.hp.hpl.jena.n3.**N3JenaWriter.**JenaReadersWriters$**
>> RDFReaderRIOT_TTL"
>>
>
> Odd - that class does not exist.
>
> org.apache.jena.riot.adapters.**JenaReadersWriters$**RDFReaderRIOT_TTL
>
> but it is the wrong reader (TTL not NT)
>
>
> From what I can gather the reader class names are loaded in an
>> RDFReaderFImpl static block:
>>
>> static { // static initializer - set default readers
>> langToClassName = new Properties();
>> for (int i = 0; i<LANGS.length; i++) {
>> langToClassName.setProperty(
>> LANGS[i],
>> JenaRuntime.getSystemProperty(**PROPNAMEBASE
>> +
>> LANGS[i],
>> DEFAULTREADERS[i]));
>> }
>> }
>>
>
> yes - but the table will have been reset by (1) initialization finding
> jena-arq on the class path (see IO_Ctl) and (2) any calls to
> IO_Jena.resetReaders -- some testing may do this.
>
> A quick check of the RIOT set/reset code does not suggest it's setting the
> wrong name - at least in current development.
>
> Could you give a complete example?
>
>
>
>> The only thing I can figure is taht the JenaRuntime.getSystemProperty(**)
>> is
>> returning a different value, but in debugging it is simpley calling
>> System.getProperty( propName, default) and returning that value (no
>> exception thrown).
>>
>> Does anybody have any idea why this is happening and what I need to do to
>> get both sets of code to use the
>> com.hp.hpl.jena.rdf.model.**impl.NTripleReader as the other reader does
>> not
>> pass the tests.
>>
>
> We need to fix the fact it's the wrong reader, TTL not NT.
>
> Andy
>
>
>> Thanks,
>> Claude
>>
>>
>>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: same code returns 2 different readers
Posted by Andy Seaborne <an...@apache.org>.
Hi Claude,
On 02/04/13 23:14, Claude Warren wrote:
> I am running some test cases.
>
> When I run the tests (TestReaderEvent) from within Jean (2.10.1) it works
> fine. When I run it using the testing jar from a different project (using
> the same setup) it does not.
>
The latest snapshot build of 2.10.1? Things will have changed in this
area when the new writers were integrated into the codebase and
subsequent clearing up.
> Under Jena 2.10.1 The call calls are:
> model.getReader("N-TRIPLE")
> ModelCom.getReader("N-TRIPLE")
> RDFReaderFImpl.getReader("N-TRIPLE")
> String className = langToClassName.getProperty(lang) returns
> "com.hp.hpl.jena.rdf.model.impl.NTripleReader"
jena-arq is not on the classpath (the new readers are current on
jena-arq while the old ones are still around, initialized via reflection
in IO_Ctl)
>
> under a different project the calls are:
> model.getReader("N-TRIPLE")
> ModelCom.getReader("N-TRIPLE")
> RDFReaderFImpl.getReader("N-TRIPLE")
> String className = langToClassName.getProperty(lang) returns
> "com.hp.hpl.jena.n3.N3JenaWriter.JenaReadersWriters$RDFReaderRIOT_TTL"
Odd - that class does not exist.
org.apache.jena.riot.adapters.JenaReadersWriters$RDFReaderRIOT_TTL
but it is the wrong reader (TTL not NT)
> From what I can gather the reader class names are loaded in an
> RDFReaderFImpl static block:
>
> static { // static initializer - set default readers
> langToClassName = new Properties();
> for (int i = 0; i<LANGS.length; i++) {
> langToClassName.setProperty(
> LANGS[i],
> JenaRuntime.getSystemProperty(PROPNAMEBASE +
> LANGS[i],
> DEFAULTREADERS[i]));
> }
> }
yes - but the table will have been reset by (1) initialization finding
jena-arq on the class path (see IO_Ctl) and (2) any calls to
IO_Jena.resetReaders -- some testing may do this.
A quick check of the RIOT set/reset code does not suggest it's setting
the wrong name - at least in current development.
Could you give a complete example?
>
> The only thing I can figure is taht the JenaRuntime.getSystemProperty() is
> returning a different value, but in debugging it is simpley calling
> System.getProperty( propName, default) and returning that value (no
> exception thrown).
>
> Does anybody have any idea why this is happening and what I need to do to
> get both sets of code to use the
> com.hp.hpl.jena.rdf.model.impl.NTripleReader as the other reader does not
> pass the tests.
We need to fix the fact it's the wrong reader, TTL not NT.
Andy
>
> Thanks,
> Claude
>
>
Re: same code returns 2 different readers
Posted by Claude Warren <cl...@xenei.com>.
(from memory) The TestReaderEvent tests that read start and read end
markers are recorded in the listeners. The RIOT reader is not doing this.
I suppose I should build a test for the reader implementations that will
test this functionality.
-- Claude
On Wed, Apr 3, 2013 at 8:40 AM, Dave Reynolds <da...@gmail.com>wrote:
> Hi Claude,
>
>
> On 02/04/13 23:14, Claude Warren wrote:
>
>> I am running some test cases.
>>
>> When I run the tests (TestReaderEvent) from within Jean (2.10.1) it works
>> fine. When I run it using the testing jar from a different project (using
>> the same setup) it does not.
>>
>> Under Jena 2.10.1 The call calls are:
>> model.getReader("N-TRIPLE")
>> ModelCom.getReader("N-TRIPLE")
>> RDFReaderFImpl.getReader("N-**TRIPLE")
>> String className = langToClassName.getProperty(**lang) returns
>> "com.hp.hpl.jena.rdf.model.**impl.NTripleReader"
>>
>> under a different project the calls are:
>> model.getReader("N-TRIPLE")
>> ModelCom.getReader("N-TRIPLE")
>> RDFReaderFImpl.getReader("N-**TRIPLE")
>> String className = langToClassName.getProperty(**lang) returns
>> "com.hp.hpl.jena.n3.**N3JenaWriter.**JenaReadersWriters$**
>> RDFReaderRIOT_TTL"
>>
>>
>> From what I can gather the reader class names are loaded in an
>> RDFReaderFImpl static block:
>>
>> static { // static initializer - set default readers
>> langToClassName = new Properties();
>> for (int i = 0; i<LANGS.length; i++) {
>> langToClassName.setProperty(
>> LANGS[i],
>> JenaRuntime.getSystemProperty(**PROPNAMEBASE
>> +
>> LANGS[i],
>> DEFAULTREADERS[i]));
>> }
>> }
>>
>> The only thing I can figure is taht the JenaRuntime.getSystemProperty(**)
>> is
>> returning a different value, but in debugging it is simpley calling
>> System.getProperty( propName, default) and returning that value (no
>> exception thrown).
>>
>> Does anybody have any idea why this is happening and what I need to do to
>> get both sets of code to use the
>> com.hp.hpl.jena.rdf.model.**impl.NTripleReader as the other reader does
>> not
>> pass the tests.
>>
>
> As I understand it the RIOT processors are wired into Jena when you use
> ARQ or TDB. It looks like you can unwire them with: IO_Jena#resetJenaReaders
>
> It would probably be helpful to say in what way the RIOT reader doesn't
> pass your tests. It seems more likely that the RIOT reader is correct (at
> least relative to the new specs from the RDF WG) than the old reader.
>
> Dave
>
>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: same code returns 2 different readers
Posted by Dave Reynolds <da...@gmail.com>.
Hi Claude,
On 02/04/13 23:14, Claude Warren wrote:
> I am running some test cases.
>
> When I run the tests (TestReaderEvent) from within Jean (2.10.1) it works
> fine. When I run it using the testing jar from a different project (using
> the same setup) it does not.
>
> Under Jena 2.10.1 The call calls are:
> model.getReader("N-TRIPLE")
> ModelCom.getReader("N-TRIPLE")
> RDFReaderFImpl.getReader("N-TRIPLE")
> String className = langToClassName.getProperty(lang) returns
> "com.hp.hpl.jena.rdf.model.impl.NTripleReader"
>
> under a different project the calls are:
> model.getReader("N-TRIPLE")
> ModelCom.getReader("N-TRIPLE")
> RDFReaderFImpl.getReader("N-TRIPLE")
> String className = langToClassName.getProperty(lang) returns
> "com.hp.hpl.jena.n3.N3JenaWriter.JenaReadersWriters$RDFReaderRIOT_TTL"
>
>
> From what I can gather the reader class names are loaded in an
> RDFReaderFImpl static block:
>
> static { // static initializer - set default readers
> langToClassName = new Properties();
> for (int i = 0; i<LANGS.length; i++) {
> langToClassName.setProperty(
> LANGS[i],
> JenaRuntime.getSystemProperty(PROPNAMEBASE +
> LANGS[i],
> DEFAULTREADERS[i]));
> }
> }
>
> The only thing I can figure is taht the JenaRuntime.getSystemProperty() is
> returning a different value, but in debugging it is simpley calling
> System.getProperty( propName, default) and returning that value (no
> exception thrown).
>
> Does anybody have any idea why this is happening and what I need to do to
> get both sets of code to use the
> com.hp.hpl.jena.rdf.model.impl.NTripleReader as the other reader does not
> pass the tests.
As I understand it the RIOT processors are wired into Jena when you use
ARQ or TDB. It looks like you can unwire them with: IO_Jena#resetJenaReaders
It would probably be helpful to say in what way the RIOT reader doesn't
pass your tests. It seems more likely that the RIOT reader is correct
(at least relative to the new specs from the RDF WG) than the old reader.
Dave