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
|