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 John Bellone <jo...@flipsidesoftware.com> on 2007/11/08 14:44:12 UTC

XmlRpcRequest

What class are the input buffers actually parsed for the server/client?

-- 
-John Bellone
john.bellone@flipsidesoftware.com
609.489.3112




Re: XmlRpcRequest

Posted by John Bellone <jo...@flipsidesoftware.com>.
Sorry again for the multiple e-mails, here's the message I was using and 
the return output:

<?xml version="1.0" 
encoding="utf-8"?><methodCall><methodName>test</methodName><params/></methodCall>

[Fatal Error] :2:1: Content is not allowed in trailing section.
Failed to read XML-RPC request: Content is not allowed in trailing section.

-John Bellone
john.bellone@flipsidesoftware.com
609.489.3112




Jochen Wiedmann wrote:
> On Nov 9, 2007 11:33 PM, John Bellone <jo...@flipsidesoftware.com> wrote:
>
>   
>> All I basically need is to parse and serialize the messages. I'm
>> receiving them in a ByteBuffer
>>     
>
> What do you plan to take as the parsers input/output? The parsers I
> know require In-/OutputStream, not ByteBuffer.
>
>
>
>
>   


Re: XmlRpcRequest

Posted by John Bellone <jo...@flipsidesoftware.com>.
That's for the answer. The parser is seemingly working but I am throwing 
an exception that I'm not sure where its coming from. I am getting a thrown:

class java.net.MalformedURLExceptionno protocol: <?xml version="1.0" 
encoding="utf-8"?><methodCall><methodName>accounts.name</methodName><params/></methodCall>

That's the output from this block of code:

                        try {
                            BufferedReader in = 
AbstractTransportParser.newBufferedReader(incomm);
                           
                            MethodCall method = parser.parse( 
in.readLine() );
                           
                            System.out.println( method.getMethodName() );
                        }
                        catch(Exception e) {
                            System.out.println( e.getClass() + 
e.getMessage() );
                            this.close();
                        }

Thanks for the help thus far Jochen. I'm glad that I decided to use this 
library.

-John Bellone
john.bellone@flipsidesoftware.com
609.489.3112

Jochen Wiedmann wrote:
> On Nov 11, 2007 2:36 AM, John Bellone <jo...@flipsidesoftware.com> wrote:
>
>   
>> "[Fatal Error] :2:1: Content is not allowed in prolog."
>>     
>
> This error message is thrown out by the XML parser. It indicates, that
> the document is not well formed, because the parser expects to see
> only the XML prolog, XML comments, or PI's before the root element.
>
> Reasons include things like HTTP headers as input for the parser,
> wrong charset when converting a character stream into a byte stream or
> similar stuff.
>
> Jochen
>
>
>   


Re: XmlRpcRequest

Posted by Jochen Wiedmann <jo...@gmail.com>.
On Nov 11, 2007 2:36 AM, John Bellone <jo...@flipsidesoftware.com> wrote:

> "[Fatal Error] :2:1: Content is not allowed in prolog."

This error message is thrown out by the XML parser. It indicates, that
the document is not well formed, because the parser expects to see
only the XML prolog, XML comments, or PI's before the root element.

Reasons include things like HTTP headers as input for the parser,
wrong charset when converting a character stream into a byte stream or
similar stuff.

Jochen


-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org


Re: XmlRpcRequest

Posted by John Bellone <jo...@flipsidesoftware.com>.
I'm interfacing with the parser the following way:

public MethodCall parse(InputStream stream)
    {   
        XmlRpcRequestParser parser
            = new XmlRpcRequestParser( new StreamConfig(), new 
TypeFactoryImpl(null) );
       
        try {
            XMLReader xr = SAXParsers.newXMLReader();
           
            xr.setContentHandler(parser);
            xr.parse( new InputSource(stream) );
        }
        catch(XmlRpcException xe) {}
        catch(SAXException se) {}
        catch(IOException ie) {}
       
        return new MethodCall(parser.getMethodName(), parser.getParams());
    }
   
    // @summary: Implementation of the configuration for the Apache 
XMLRPC parser. This is
    // a default configuration that most likely will never need to be 
changed.
    // @author: John Bellone (jvb4@njit.edu)
    private class StreamConfig implements XmlRpcStreamConfig
    {
        public String getEncoding() { return UTF8_ENCODING; }
        public boolean isEnabledForExtensions() { return false; }
        public java.util.TimeZone getTimeZone() { return 
java.util.TimeZone.getDefault(); }
    }

Now I am getting an error message that I am Googling for to find out the 
reason. Here's what it says:

"[Fatal Error] :2:1: Content is not allowed in prolog."

I have been connecting to the server in telnet so my first guess is that 
its not sending the proper headers? I'm trying to figure out an easy way 
to test out the implementation. Any pointers?

-John Bellone
john.bellone@flipsidesoftware.com
609.489.3112




Jochen Wiedmann wrote:
> On Nov 9, 2007 11:33 PM, John Bellone <jo...@flipsidesoftware.com> wrote:
>
>   
>> All I basically need is to parse and serialize the messages. I'm
>> receiving them in a ByteBuffer
>>     
>
> What do you plan to take as the parsers input/output? The parsers I
> know require In-/OutputStream, not ByteBuffer.
>
>
>
>
>   


Re: XmlRpcRequest

Posted by Jochen Wiedmann <jo...@gmail.com>.
On Nov 9, 2007 11:33 PM, John Bellone <jo...@flipsidesoftware.com> wrote:

> All I basically need is to parse and serialize the messages. I'm
> receiving them in a ByteBuffer

What do you plan to take as the parsers input/output? The parsers I
know require In-/OutputStream, not ByteBuffer.




-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org


Re: XmlRpcRequest

Posted by John Bellone <jo...@flipsidesoftware.com>.
No, it looks like I am going to have to write my own parser 
implementation. I'll end up using the type conversions from the library 
to make it a little easier on myself. I looked into extending 
XmlRpcStreamTransport but it doesn't look like what I need.

All I basically need is to parse and serialize the messages. I'm 
receiving them in a ByteBuffer and I have a specialized class that is 
built from the parameters and method name (and thusly, needs to be 
serialized back into xml).

I was looking into avoiding having to do this but I don't see any way to 
get around starting up the built-in server.

-John Bellone
john.bellone@flipsidesoftware.com
609.489.3112




Jochen Wiedmann wrote:
> On Nov 8, 2007 4:47 PM, John Bellone <jo...@flipsidesoftware.com> wrote:
>
>   
>> I want to use the parser and XmlRpcRequest object without the overhead
>> of the server (already have one built - we're looking to keep the
>> transports separate from the networking). Right now I am thinking that I
>> am going to have to extend to the parser, but I don't see where it
>> returns an Object with parameters and a methodcall.
>>     
>
> Sounds like a use case for subclassing the XmlRpcStreamTransport.
>
>
>   


Re: XmlRpcRequest

Posted by Jochen Wiedmann <jo...@gmail.com>.
On Nov 8, 2007 4:47 PM, John Bellone <jo...@flipsidesoftware.com> wrote:

> I want to use the parser and XmlRpcRequest object without the overhead
> of the server (already have one built - we're looking to keep the
> transports separate from the networking). Right now I am thinking that I
> am going to have to extend to the parser, but I don't see where it
> returns an Object with parameters and a methodcall.

Sounds like a use case for subclassing the XmlRpcStreamTransport.


-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org


Re: XmlRpcRequest

Posted by John Bellone <jo...@flipsidesoftware.com>.
At what point is the input from a channel/stream parsed into an 
XmlRpcRequest?

I want to use the parser and XmlRpcRequest object without the overhead 
of the server (already have one built - we're looking to keep the 
transports separate from the networking). Right now I am thinking that I 
am going to have to extend to the parser, but I don't see where it 
returns an Object with parameters and a methodcall.

-John Bellone
john.bellone@flipsidesoftware.com
609.489.3112




Jochen Wiedmann wrote:
> On Nov 8, 2007 2:44 PM, John Bellone <jo...@flipsidesoftware.com> wrote:
>
>   
>> What class are the input buffers actually parsed for the server/client?
>>     
>
> I don't understand the question.
>
>   


Re: XmlRpcRequest

Posted by Jochen Wiedmann <jo...@gmail.com>.
On Nov 8, 2007 2:44 PM, John Bellone <jo...@flipsidesoftware.com> wrote:

> What class are the input buffers actually parsed for the server/client?

I don't understand the question.

-- 
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org