Bug in SOAPActionProcessorImpl ?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in SOAPActionProcessorImpl ?

lluki
Hiho!

I was testing my mediaserver against the GUpnp universal control point. (http://www.gupnp.org/, gupnp-universal-cp 0.8).

This is one example XML it sends:
<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><ObjectID>1</ObjectID><Filter>2</Filter><RequestedCount>4</RequestedCount><SortCriteria>5</SortCriteria><StartingIndex>3</StartingIndex><BrowseFlag>BrowseDirectChildren</BrowseFlag></u:Browse></s:Body></s:Envelope>

I think thats valid. But cling parses it wrong, it uses the order of the children in the XML to pass the argument to my Browse implementation. I could hack Cling to work with such an XML:

org.teleal.cling.transport.impl.SOAPActionProcessorImpl.readActionInputArguments

    public void readActionInputArguments(Element actionRequestElement,
                                         ActionInvocation actionInvocation) throws ActionException {
        NodeList actionRequestChildren = actionRequestElement.getChildNodes();

        List<String> inputArgumentNames = actionInvocation.getAction().getInputArgumentNames();

                for (String currentArgument : inputArgumentNames) { //NEW
                        for (int i = 0; i < actionRequestChildren.getLength(); i++) {
                                Node actionRequestChild = actionRequestChildren.item(i);

                                if (actionRequestChild.getNodeType() != Node.ELEMENT_NODE)
                                        continue;

                                if (!getUnprefixedNodeName(actionRequestChild).equals(currentArgument)) //NEW
                                        continue; //NEW

                                if (inputArgumentNames.contains(getUnprefixedNodeName(actionRequestChild))) {
                                        log.fine("Reading action input argument: " + getUnprefixedNodeName(actionRequestChild));
                                        String value = XMLUtil.getTextContent(actionRequestChild);
                                        actionInvocation.getInput().addValue(value);
                                }
                        }
        }//NEW
    }


Greetings
Luki
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

Christian Bauer
Administrator
This is an invalid message for the Browse action, the UDA 1.0 specification says:

'Every “in” argument in the definition of the action in the service description must be included, in the same order as specified in the service description (SCPD) that was downloaded from the device.'

The same is true for response output argument ordering.

I always had the suspicion that I would find devices which do not follow this rule and that my code would have to be modified. Today I am surprised that it took that long to find a broken device/control point and I'm less inclined to make any changes to correct code. This should be fixed in GUPnP instead, maybe you can report it there.
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

Christian Bauer
Administrator
In reply to this post by lluki
Note that I'm assuming your Browse action has a _different_ order of @UpnpInputArgument parameters than this message has.

I've just realized that although Cling's descriptors are correct (preserving the order you have defined with @UpnpInputArgument and @UpnpOutputArgument on your classes), and Clings SOAP messages are correct (they preserve the order as declared in the descriptors), some of the control points in the Workbench/Support module are not.

I've made a similar mistake but instead of randomly sorting the input arguments I've used the order as listed in the specification document e.g. in BrowseActionCallback. In general it was probably a mistake to even provide an addValue(v) method which assumes some fixed order of arguments.
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

lluki
Yes, i have a different ordering than the upnp tools. I use the ordering found in the standard, but the upnp tools dont (at least their xml processing doesn't, because in their GUI the order is the same as in the standard...).

I think at least an assert or producing some meaningful log messages (when the parameters don't match) would be helpful. I'll report the bug to the gupnp devs...
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

Christian Bauer
Administrator
I'm working on this part of Cling right now, there will be a better message and unfortunately some API changes.

The important aspect here is that the order of action arguments for input and output in the SOAP messages has to be the same as in the device/service descriptor. It does not have to be the same as in the specification document, it just has to match internally. There is no good reason for that, just one of the many issues in UPnP.
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

lluki
Hi

Another little thing:

A XML Class for upnp:artist is missing (applicable to any items of object.item.audioItem.musicTrack).

Greets
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

Christian Bauer
Administrator
Other attributes are probably missing from the schema. The classes are automatically generated during the build. Since you are already writing a MediaServer, could you add these to the Cling upnp-cds-1.0.xsd and post the patch here?  That would be great.
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

lluki
Hi!

Did you add the missing things? I just wanted to look into it, and there actually is an entry for artist in upnp-cds-1.0.xsd. I eventually could get maven working, and after a "mvn verify" classes for artist etc. appear.... I just noticed, that there are no auto generated classes in the svn (what makes sense), so maybe it was only a local build problem (didnt use maven before, just checked it out in eclipse and added dependencys manually).

Greets
Reply | Threaded
Open this post in threaded view
|

Re: Bug in SOAPActionProcessorImpl ?

Christian Bauer
Administrator
No, I didn't have time to add more attributes/entities to the schemas. I fixed the Maven build on Linux with the SUN JDK, which was actually an issue with the JAXB class generator. If you have any problems with the build, let me know.