You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Stuart Roll <sr...@symantec.com> on 2002/02/19 16:24:23 UTC
Running XmlRpcClient from an applet
Greetings -
<apologies in advance if this is the wrong mailing list for this topic>
I got a nasty little suprise when I tried to use XML-RPC from within an
unsigned applet. The XmlRpcClient's worker threads are instances of XmlRpc
and XmlRpc.parse() contains the following code:
if (parserClass == null) {
// try to get the name of the SAX driver from the System
properties
setDriver (System.getProperty ("sax.driver",
"uk.co.wilson.xml.MinML"));
}
If you don't set a parser class explicitly (through XmlRpc.setDriver()),
XmlRpc will check the system property shown above and use it's default if
that isn't set. Unfortunately, in an unsigned applet the applet is
prohibited from examining that system property and a SecurityException is
thrown (which isn't handled by XML-RPC).
To make matters worse, XmlRpcClient does not provide a means to set the
parser that its workers will use. Since the XmlRpcClient.Worker class
(which extends XmlRpc) has package access, you can't even subclass
XmlRpcClient to override the behavior. Alas, all my hacks failed me and I
had to modify the library itself.
1 - At the very least, the snippet above should read something like:
if (parserClass == null) {
// try to get the name of the SAX driver from the System
properties
try {
setDriver (System.getProperty ("sax.driver",
"uk.co.wilson.xml.MinML"));
} catch (SecurityException e) {
setDriver ("uk.co.wilson.xml.MinML");
}
}
2 - For those who don't want to use the default parser, what should we do?
Should the various client and server/servlet objects each provide a means
to set the parser class for their worker threads? Perhaps someone has a
clever suggestion like a worker thread factory callback or somesuch.
In my case, I've modified the XML-RPC library to change the default to be
the Xerces parser and added the try-catch block shown above but I'd like to
see a proper fix.
Stuart
Re: Running XmlRpcClient from an applet
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> Hey Stuart, thanks for the note. I just check code implementing your
> work-around into CVS. If you'd like to add some sort of factory for
> parser creation, there would be interested in that.
Okay, now I don't always write in English this broken... ;-/
- dan
Re: Running XmlRpcClient from an applet
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> Hey Stuart, thanks for the note. I just check code implementing your
> work-around into CVS. If you'd like to add some sort of factory for
> parser creation, there would be interested in that.
Okay, now I don't always write in English this broken... ;-/
- dan
Re: Running XmlRpcClient from an applet
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Hey Stuart, thanks for the note. I just check code implementing your
work-around into CVS. If you'd like to add some sort of factory for
parser creation, there would be interested in that.
http://jakarta.apache.org/site/source.html
Thanks, Dan
"Stuart Roll" <sr...@symantec.com> writes:
> Greetings -
>
> <apologies in advance if this is the wrong mailing list for this topic>
>
> I got a nasty little suprise when I tried to use XML-RPC from within an
> unsigned applet. The XmlRpcClient's worker threads are instances of XmlRpc
> and XmlRpc.parse() contains the following code:
>
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> }
>
> If you don't set a parser class explicitly (through XmlRpc.setDriver()),
> XmlRpc will check the system property shown above and use it's default if
> that isn't set. Unfortunately, in an unsigned applet the applet is
> prohibited from examining that system property and a SecurityException is
> thrown (which isn't handled by XML-RPC).
>
> To make matters worse, XmlRpcClient does not provide a means to set the
> parser that its workers will use. Since the XmlRpcClient.Worker class
> (which extends XmlRpc) has package access, you can't even subclass
> XmlRpcClient to override the behavior. Alas, all my hacks failed me and I
> had to modify the library itself.
>
> 1 - At the very least, the snippet above should read something like:
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> try {
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> } catch (SecurityException e) {
> setDriver ("uk.co.wilson.xml.MinML");
> }
> }
>
> 2 - For those who don't want to use the default parser, what should we do?
> Should the various client and server/servlet objects each provide a means
> to set the parser class for their worker threads? Perhaps someone has a
> clever suggestion like a worker thread factory callback or somesuch.
>
> In my case, I've modified the XML-RPC library to change the default to be
> the Xerces parser and added the try-catch block shown above but I'd like to
> see a proper fix.
>
> Stuart
Re: Running XmlRpcClient from an applet
Posted by John Wilson <tu...@wilson.co.uk>.
You want to use Xerces in an applet!
Hope you've got plenty of bandwidth;)
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
----- Original Message -----
From: "Stuart Roll" <sr...@symantec.com>
To: <rp...@xml.apache.org>
Sent: Tuesday, February 19, 2002 3:24 PM
Subject: Running XmlRpcClient from an applet
> Greetings -
>
> <apologies in advance if this is the wrong mailing list for this topic>
>
> I got a nasty little suprise when I tried to use XML-RPC from within an
> unsigned applet. The XmlRpcClient's worker threads are instances of
XmlRpc
> and XmlRpc.parse() contains the following code:
>
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> }
>
> If you don't set a parser class explicitly (through XmlRpc.setDriver()),
> XmlRpc will check the system property shown above and use it's default if
> that isn't set. Unfortunately, in an unsigned applet the applet is
> prohibited from examining that system property and a SecurityException is
> thrown (which isn't handled by XML-RPC).
>
> To make matters worse, XmlRpcClient does not provide a means to set the
> parser that its workers will use. Since the XmlRpcClient.Worker class
> (which extends XmlRpc) has package access, you can't even subclass
> XmlRpcClient to override the behavior. Alas, all my hacks failed me and I
> had to modify the library itself.
>
> 1 - At the very least, the snippet above should read something like:
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> try {
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> } catch (SecurityException e) {
> setDriver ("uk.co.wilson.xml.MinML");
> }
> }
>
> 2 - For those who don't want to use the default parser, what should we do?
> Should the various client and server/servlet objects each provide a means
> to set the parser class for their worker threads? Perhaps someone has a
> clever suggestion like a worker thread factory callback or somesuch.
>
> In my case, I've modified the XML-RPC library to change the default to be
> the Xerces parser and added the try-catch block shown above but I'd like
to
> see a proper fix.
>
> Stuart
>
>
>
Re: Running XmlRpcClient from an applet
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Hey Stuart, thanks for the note. I just check code implementing your
work-around into CVS. If you'd like to add some sort of factory for
parser creation, there would be interested in that.
http://jakarta.apache.org/site/source.html
Thanks, Dan
"Stuart Roll" <sr...@symantec.com> writes:
> Greetings -
>
> <apologies in advance if this is the wrong mailing list for this topic>
>
> I got a nasty little suprise when I tried to use XML-RPC from within an
> unsigned applet. The XmlRpcClient's worker threads are instances of XmlRpc
> and XmlRpc.parse() contains the following code:
>
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> }
>
> If you don't set a parser class explicitly (through XmlRpc.setDriver()),
> XmlRpc will check the system property shown above and use it's default if
> that isn't set. Unfortunately, in an unsigned applet the applet is
> prohibited from examining that system property and a SecurityException is
> thrown (which isn't handled by XML-RPC).
>
> To make matters worse, XmlRpcClient does not provide a means to set the
> parser that its workers will use. Since the XmlRpcClient.Worker class
> (which extends XmlRpc) has package access, you can't even subclass
> XmlRpcClient to override the behavior. Alas, all my hacks failed me and I
> had to modify the library itself.
>
> 1 - At the very least, the snippet above should read something like:
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> try {
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> } catch (SecurityException e) {
> setDriver ("uk.co.wilson.xml.MinML");
> }
> }
>
> 2 - For those who don't want to use the default parser, what should we do?
> Should the various client and server/servlet objects each provide a means
> to set the parser class for their worker threads? Perhaps someone has a
> clever suggestion like a worker thread factory callback or somesuch.
>
> In my case, I've modified the XML-RPC library to change the default to be
> the Xerces parser and added the try-catch block shown above but I'd like to
> see a proper fix.
>
> Stuart
Re: Running XmlRpcClient from an applet
Posted by John Wilson <tu...@wilson.co.uk>.
You want to use Xerces in an applet!
Hope you've got plenty of bandwidth;)
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
----- Original Message -----
From: "Stuart Roll" <sr...@symantec.com>
To: <rp...@xml.apache.org>
Sent: Tuesday, February 19, 2002 3:24 PM
Subject: Running XmlRpcClient from an applet
> Greetings -
>
> <apologies in advance if this is the wrong mailing list for this topic>
>
> I got a nasty little suprise when I tried to use XML-RPC from within an
> unsigned applet. The XmlRpcClient's worker threads are instances of
XmlRpc
> and XmlRpc.parse() contains the following code:
>
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> }
>
> If you don't set a parser class explicitly (through XmlRpc.setDriver()),
> XmlRpc will check the system property shown above and use it's default if
> that isn't set. Unfortunately, in an unsigned applet the applet is
> prohibited from examining that system property and a SecurityException is
> thrown (which isn't handled by XML-RPC).
>
> To make matters worse, XmlRpcClient does not provide a means to set the
> parser that its workers will use. Since the XmlRpcClient.Worker class
> (which extends XmlRpc) has package access, you can't even subclass
> XmlRpcClient to override the behavior. Alas, all my hacks failed me and I
> had to modify the library itself.
>
> 1 - At the very least, the snippet above should read something like:
> if (parserClass == null) {
> // try to get the name of the SAX driver from the System
> properties
> try {
> setDriver (System.getProperty ("sax.driver",
> "uk.co.wilson.xml.MinML"));
> } catch (SecurityException e) {
> setDriver ("uk.co.wilson.xml.MinML");
> }
> }
>
> 2 - For those who don't want to use the default parser, what should we do?
> Should the various client and server/servlet objects each provide a means
> to set the parser class for their worker threads? Perhaps someone has a
> clever suggestion like a worker thread factory callback or somesuch.
>
> In my case, I've modified the XML-RPC library to change the default to be
> the Xerces parser and added the try-catch block shown above but I'd like
to
> see a proper fix.
>
> Stuart
>
>
>