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 <[email protected]> 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/[email protected] LinkedIn: http://www.linkedin.com/in/claudewarren
