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:
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.
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.
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...
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.
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.
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).
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.