You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2013/01/13 20:09:24 UTC
Need a small sax parser for m-s-u
We switched to SAX parsing in m-s-u, and we just had an interesting
issue (https://jira.codehaus.org/browse/SUREFIRE-950)
which basically happens because some plugin sets org.xml.sax.driver to
point to a variable that is only present in that plugins classloader,
when m-s-u later tries to instantiate a sax parser it blows up.
This happens because the standard instantiation algorithm in
org.xml.sax.helpers.XMLReaderFactory.createXMLReader() is
not good enough for us. To my knowledge there is no standard way to
determine what implementation is in use for different JDK's,
so the best option is probably to shade in a nice small version of a
sax parser from somewhere.
I tried shading in xerces, which works nicely, but is hardly "small".
Anyone have any other suggestions ?
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Need a small sax parser for m-s-u
Posted by Jesse Glick <jg...@cloudbees.com>.
On 01/13/2013 02:09 PM, Kristian Rosenvold wrote:
> Anyone have any other suggestions?
http://piccolo.sourceforge.net/ is old but claims to be what you asked for. Central does not seem to have the most “recent” release unfortunately.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Need a small sax parser for m-s-u
Posted by Kristian Rosenvold <kr...@gmail.com>.
find . -name *.jar | xargs -L 1 unzip -l | grep "services/org.xml"
inside my jdk/jre installation
seems to indicate the JDK itself does not use the SPI mechanism, which
is further backed
by the default implementation in XMLReaderFactory being hardcoded.
Setting the system property to null forces the default implementation
on sun java, but is not thread safe.
Looking for a list of parsers or maintaining a map of jdk->parser
mapping seems like the best option,
unless there is something nice we can shade in. I'm not sure if
shading in something like xerces just
sets sets org.xml.sax.driver to point at the shaded version (being
lazy, could find out ;)
If we did shade in something I'm thinking we'd use "new" instead of
XMLReaderFactory, since it's all private stuff anyway. Hopefully this
would not disturb anyone's environment....(?)
Kristian
2013/1/13 Benson Margulies <bi...@gmail.com>:
> Well, you could scan for the JRE's builtin SPI file and pass the class
> name you acquire to
> http://docs.oracle.com/javase/6/docs/api/org/xml/sax/helpers/XMLReaderFactory.html.
>
> It is rather annoying that these classes don't let you say 'give me
> the stock JRE method, ignore the system property'.
>
> Or you could write down a list consisting of the class name used in
> the Oracle JRE and the class name used in the IBM JDK, and try them in
> order.
>
>
> On Sun, Jan 13, 2013 at 2:09 PM, Kristian Rosenvold
> <kr...@gmail.com> wrote:
>> We switched to SAX parsing in m-s-u, and we just had an interesting
>> issue (https://jira.codehaus.org/browse/SUREFIRE-950)
>> which basically happens because some plugin sets org.xml.sax.driver to
>> point to a variable that is only present in that plugins classloader,
>> when m-s-u later tries to instantiate a sax parser it blows up.
>>
>> This happens because the standard instantiation algorithm in
>> org.xml.sax.helpers.XMLReaderFactory.createXMLReader() is
>> not good enough for us. To my knowledge there is no standard way to
>> determine what implementation is in use for different JDK's,
>> so the best option is probably to shade in a nice small version of a
>> sax parser from somewhere.
>>
>> I tried shading in xerces, which works nicely, but is hardly "small".
>> Anyone have any other suggestions ?
>>
>> Kristian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Need a small sax parser for m-s-u
Posted by Chris Graham <ch...@gmail.com>.
Yes, be really careful with shading and similar XML stuff, the IBM JRE has
a lot of XML processing in it built in, and it can clash.
-Chris
On Mon, Jan 14, 2013 at 6:39 AM, Benson Margulies <bi...@gmail.com>wrote:
> Well, you could scan for the JRE's builtin SPI file and pass the class
> name you acquire to
>
> http://docs.oracle.com/javase/6/docs/api/org/xml/sax/helpers/XMLReaderFactory.html
> .
>
> It is rather annoying that these classes don't let you say 'give me
> the stock JRE method, ignore the system property'.
>
> Or you could write down a list consisting of the class name used in
> the Oracle JRE and the class name used in the IBM JDK, and try them in
> order.
>
>
> On Sun, Jan 13, 2013 at 2:09 PM, Kristian Rosenvold
> <kr...@gmail.com> wrote:
> > We switched to SAX parsing in m-s-u, and we just had an interesting
> > issue (https://jira.codehaus.org/browse/SUREFIRE-950)
> > which basically happens because some plugin sets org.xml.sax.driver to
> > point to a variable that is only present in that plugins classloader,
> > when m-s-u later tries to instantiate a sax parser it blows up.
> >
> > This happens because the standard instantiation algorithm in
> > org.xml.sax.helpers.XMLReaderFactory.createXMLReader() is
> > not good enough for us. To my knowledge there is no standard way to
> > determine what implementation is in use for different JDK's,
> > so the best option is probably to shade in a nice small version of a
> > sax parser from somewhere.
> >
> > I tried shading in xerces, which works nicely, but is hardly "small".
> > Anyone have any other suggestions ?
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Need a small sax parser for m-s-u
Posted by Benson Margulies <bi...@gmail.com>.
Well, you could scan for the JRE's builtin SPI file and pass the class
name you acquire to
http://docs.oracle.com/javase/6/docs/api/org/xml/sax/helpers/XMLReaderFactory.html.
It is rather annoying that these classes don't let you say 'give me
the stock JRE method, ignore the system property'.
Or you could write down a list consisting of the class name used in
the Oracle JRE and the class name used in the IBM JDK, and try them in
order.
On Sun, Jan 13, 2013 at 2:09 PM, Kristian Rosenvold
<kr...@gmail.com> wrote:
> We switched to SAX parsing in m-s-u, and we just had an interesting
> issue (https://jira.codehaus.org/browse/SUREFIRE-950)
> which basically happens because some plugin sets org.xml.sax.driver to
> point to a variable that is only present in that plugins classloader,
> when m-s-u later tries to instantiate a sax parser it blows up.
>
> This happens because the standard instantiation algorithm in
> org.xml.sax.helpers.XMLReaderFactory.createXMLReader() is
> not good enough for us. To my knowledge there is no standard way to
> determine what implementation is in use for different JDK's,
> so the best option is probably to shade in a nice small version of a
> sax parser from somewhere.
>
> I tried shading in xerces, which works nicely, but is hardly "small".
> Anyone have any other suggestions ?
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org