Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Stack trace if res_id present in OpenURL #7
I've just been testing Umlaut with Annee Philologique as the source: http://www.annee-philologique.com/
The OpenURLs it produces include a res_id which appears to be the base URL of our resolver (or rather the base URL we have configured: the OpenURLs are routed to us via the UK OpenURL Router service, but that is immaterial).
If there is anything in this field, Umlaut throws a wobbly. I have created some bit.ly shortcuts which show the behaviour on a few Umlaut installations I know of:
I tried Johns Hopkins SFX as well, and it does not have problems: http://bit.ly/WDg7RS
There is a mention of res_id in section 4.5 of the Z39.88-2004 KEV implementation guidelines at http://alcme.oclc.org/openurl/docs/implementation_guidelines/KEV_Guidelines-20041209.pdf so I suspect it is a problem with Umlaut or the openurl library.
The problem occurs whatever is in the res_id field. In our case it was "http://openurl.ac.uk/ukfed:dur.ac.uk" but I tried just with "rr" and that produced the same error. The error screen starts:
NoMethodError in ResolveController#index undefined method `add_identifier' for nil:NilClass
There is nothing in the Application Trace. The Framework Trace starts:
openurl (0.4.2) lib/openurl/context_object.rb:387:in
but you will probably see something similar if you try the example URL for your own servers.
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
We don’t care about the res_id value: it was appearing in OpenURLs from L’annee philologique (a relatively new resource) but we weren’t wanting to use it. It just meant Umlaut could not resolve the link.
In the case of “L’annee philologique” the res_id value was set to the base URL which we had configured as our resolver address in their system, so it was equal to http://openurl.ac.uk/ukfed:dur.ac.uk which in turn redirects to our actual resolver. It is of no interest to us, but we hadn’t much choice about the fact they were generating that key-value pair, hence the problem.
will get this fixed soon.(thanks @scotdaltonhttps://github.com/scotdalton for the failing test).
res_id will probably just be ignored (rather than raise) in openurl gem, and umlaut.
Out of curiosity, @mephillips-durhamhttps://github.com/mephillips-durham , what is res_id actually being used for, if anything, in your environment?
oh man, the openurl code (possibly over 10 years old by now) is really a mess. It's hard to figure out what's going on and how to fix it, but i'm noticing things that really need to be changed for security reasons (profligate use of 'eval') anyhow, related to all this. sigh.
Okay, fixed in openurl gem, released openurl gem as 0.4.3. No changes needed in umlaut itself.
Will make 0.4.3 the minimal pre-req for future umlaut releases.
In the meantime, you just need to add to your app Gemfile:
To use the new openurl gem, and avoid this bug.
If you end up doing a big refactoring exercise, could you bear in mind the desire to handle repeatable fields in OpenURLs? As I understand it, Umlaut won’t be able to access them as the OpenURL library does not keep them. I am thinking particularly of rft.au.
[OK, forget that for the moment: I see you’ve nailed the bug. Congratulations!]
I believe that openurl handles multiple rft.au fine, but Umlaut does not
This annoys me too, but it requires work in Umlaut, not in Openurl, and
The fact that the core umlaut/openurl code is,at this point, probably
On 4/17/2013 12:13 PM, Matthew Phillips wrote: