Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching parser backend is not threadsafe #50

Open
tcollier opened this issue Mar 24, 2016 · 0 comments
Open

Switching parser backend is not threadsafe #50

tcollier opened this issue Mar 24, 2016 · 0 comments

Comments

@tcollier
Copy link

I've written a gem that is using MultiXml to parse a response from a 3rd party API. Due to some peculiarities of the response XML, this gem is forced to use the Ox backend. The client using this gem also has other dependencies which use MultiXml, though I'm not sure which back-end they prefer. Given that different backends result in different parsing behavior (see #30), I foresee disaster if I force all dependencies to use Ox (or if one of the dependencies forces my gem to use a backend other than Ox).

The naive solution would be to wrap calls to MultiXml.parse in my gem like so

def parse_xml(xml)
  orig_parser = MultiXml.parser
  MultiXml.parser = :ox
  parsed = MultiXml.parse(xml)
  MultiXml.parser = orig_parser
  parsed
end

Unfortunately, this won't work for me, because the client application is running in a multithreaded environment (Rails with Puma) and this approach is not thread-safe.

What I need is a thread safe way to tell my gem to use Ox when parsing without affecting other gems' usage of MultiXml.

One solution would be to add a :parser option to MultiXml.parse, which would override the globally configured parser for that particular case. Usage could look like

MutliXml.parse(xml, parser: :ox)

That is just a suggested solution, I know there are other ways to solve this problem too.

tcollier pushed a commit to tcollier/multi_xml that referenced this issue Mar 24, 2016
Accept new :parser option in MultiXml.parse and use that value instead of
the globally configurated parser.

This allows different gems to use different parsing backends within the same
application.

Fixes sferik#50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant