Hi.
As suggested I break up my questions into separate emails. This one
covers the topic of the missing request parameter of my custom
GetCapabilities operation.
My question was: the getCapabilities method (in MyCapability2) should
expect some XML input - do you have any idea why the generated method
only has a return parameter? Is that due to the fact that I used
doc/literal?
Allen wrote:
(MyCapability2) package net.opengis.www.sas._1.0.0; import
org.apache.muse.core.AbstractCapability; import org.w3c.dom.Element;
public class MyCapability extends AbstractCapability implements
IMyCapability { public Element getCapabilities() throws
Exception { //TODO implement getCapabilities throw
new RuntimeException("Unimplemented Method: getCapabilities");
} public Element describeSensor(Element SensorID) throws
Exception { //TODO implement describeSensor throw
new RuntimeException("Unimplemented Method: describeSensor"); } }
I cannot see the element definition for sas:GetCapabilities in either
of the WSDLs... What does it look like?
Vinh wrote:
4) If a generated capability method doesn't have parameters when it is
expected to, it might be due to your wsdl not being doc-literal. The
message input might not be defined correctly. Since you didn't include
your schemas (i.e. sas:GetCapabilities), I can't tell if you're defining
them correctly.
You can find the complete schema definition I used - together with my
current wsdl files - in the zip package at
http://ifgi.uni-muenster.de/~echterhj/SAS/SAS_with_muse.zip (for
convenience I copied two schema fragments to the end of this email)
Maybe you can find some time to have a look at the schema - there are a
lot of schema files in there, the interesting ones should be named
OGC-SAS*, OGC-OWS* and OGC-SensorML*.
Allen also wrote:
* concerning the generated sources:
o The getCapabilities method (in MyCapability2) should expect
some XML input - do you have any idea why the generated
method only has a return parameter? Is that due to the fact
that I used doc/literal?
No - I don't think it's because it's doc/lit. All my WSDLs use doc/lit
and they have input parameters for the methods. I am curious if the
element definition is being found properly.<br>
That is a good question. Maybe there is a bug in my wsdl? At least
oXygen, my XML tool, seems to recognize the GetCapabilities operation in
my wsdl file as it generates both request and response templates as
expected.
The describeSensor method (in MyCapability2) looks ok - if the
SensorID Element is actually the complete DescribeSensor request XML
document which would be send by a client in the SOAP body. Looking at
the registerPublisher method, it seems like wsdl2java removes the
top-level XML fragment from the request (in this case the
RegisterPublisher XML element) and lists all elements contained in
that element instead (even converting them if they are of simple type).
What does the sas:DescribeSensor element look like? Is SensorID a
complex type? (Note that you can write your own Java classes to
represent this type and define a custom serializer in muse.xml to
convert to/from the xml wire format; this would allow you to use a Java
type as a method parameter)
The SensorID is a simple element of type xs:token that is contained in
the DescribeSensor request element (see
OGC-SAS-1_0_0-sasDescribeSensor.xsd and OGC-SAS-1_0_0-sasCommon.xsd in
the zipfile mentioned earlier).
The custom serializer sounds interesting. I have read the passage in the
manual concerning the deployment-descriptor and also had a look at the
javadoc of org.apache.muse.core.serializer.Serializer. Usually I am
using XMLBeans for (de-)serializing XML, I hope it works here as well.
To summarize: wsdl2java still did not create a getCapabilities method
that expects an input parameter. Maybe that is due to the fact that the
schema for the request element is complex. If using my own serializer
helps I will give it a try, provided that I find out how to do this.
Cheers,
Johannes
---------------------------------------
Schema fragment for the GetCapabilities operation:
<xs:element name="GetCapabilities">
<xs:annotation>
<xs:documentation>Request to a SAS to perform the GetCapabilities
operation. This operation allows a client to retrieve service metadata
(capabilities XML) providing metadata for the specific SAS server. In
this XML encoding, no "request" parameter is included, since the element
name specifies the specific operation. </xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="ows:GetCapabilitiesType">
<xs:attribute name="service" type="ows:ServiceType"
use="required" fixed="SAS"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
where ows:GetCapabilitiesType is defined as follows:
<complexType name="GetCapabilitiesType">
<annotation>
<documentation>XML encoded GetCapabilities operation request. This
operation allows clients to retrieve service metadata about a specific
service instance. In this XML encoding, no "request" parameter is
included, since the element name specifies the specific operation. This
base type shall be extended by each specific OWS to include the
additional required "service" attribute, with the correct value for that
OWS. </documentation>
</annotation>
<sequence>
<element name="AcceptVersions" type="ows:AcceptVersionsType"
minOccurs="0">
<annotation>
<documentation>When omitted, server shall return latest
supported version. </documentation>
</annotation>
</element>
<element name="Sections" type="ows:SectionsType" minOccurs="0">
<annotation>
<documentation>When omitted or not supported by server, server
shall return complete service metadata (Capabilities) document.
</documentation>
</annotation>
</element>
<element name="AcceptFormats" type="ows:AcceptFormatsType"
minOccurs="0">
<annotation>
<documentation>When omitted or not supported by server, server
shall return service metadata document using the MIME type "text/xml".
</documentation>
</annotation>
</element>
</sequence>
<attribute name="updateSequence" type="ows:UpdateSequenceType"
use="optional">
<annotation>
<documentation>When omitted or not supported by server, server
shall return latest complete service metadata document. </documentation>
</annotation>
</attribute>
</complexType>
As you can see a lot of my message elements and types use definitions
from other namespaces or defined in separate elements/types - that Is
why I wrote "quite complex schema".
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
