On 14/11/11 20:20, Simon Helsen wrote:
Andy,
thanks, I was digging through the code paths both in the latest as well
as the version we currently still have deployed (arq 2.8.5) and it seems
that the only difference is that in 2.8.5, the readImpl of JenaReadRIOT
calls the resolve here:
*private**void*readImpl(Model model, Tokenizer tokenizer, String base)
{
// The reader has been checked, if possible, by now or
// constructed correctly by code here.
*if*( base != *null*)
base = IRIResolver./resolveGlobalToString/(base) ;
*try*{
model.notifyEvent( GraphEvents./startRead/);
readWorker(model, tokenizer, base) ;
}
...
whereas in the latest, there is no resolution of the base at all at that
stage:
*private**void*readImpl(Model model, Tokenizer tokenizer, String base)
{
*try*{
model.notifyEvent( GraphEvents./startRead/);
readWorker(model, tokenizer, base) ;
}
...
Now, deeper down, both create an IRIResolverNormal object, so I am
guessing it is safe if I patch our current version to remove the call to
resolveGlobalToString. Any comments? (and before you ask, this is
because we are currently not yet upgrading the jena stack, but I need to
fix this since it leads to concurrency errors during our indexing process)
thanks
Simon
Better would be to patch IRIresolver and add "synchronized" to every
static function that uses "globalResolver". Deleting the code from
readImpl means that you've change the behaviour of reading when the base
is provided. Maybe your code always sets an absolute base ... but safer
to fix IRIResolver IMO. I don't think globalResolver isn't let out of
IRIResolver in v2.8.5
Andy
