Hi Johannes, Try breaking up this email into 1-2 questions at a time. It's very hard to read:) Just a few points to help:
1) To be doc-literal, import the necessary XSDs. Don't import another WSDL and assume you'll inherit all the schemas used in that WSDL. 2) Try to avoid using wsdlmerge. I've seen that after using wsdl2java, the wsdl it generates which combines all schemas inline doesn't always update the schema namespaces properly. So I've always deployed my original wsdls instead of the one wsdl2java outputs. 3) The "No WS-RP schema found" can safely be ignored. It's probably because your service has WSRP properties but no .wsrmd file, which is not required. 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. 5) A capability only needs to implement AbstractWsResourceCapability if it is providing the get/set methods for your custom resource properties. 6) A SubscriptionManager resource manages a single subscription. So if you call Subscribe 5 times, you will have 5 instances of SubscriptionManager. -Vinh -----Original Message----- From: Allen George [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2008 8:49 AM To: [email protected] Subject: Re: generating sources for service using quite complex schema Hi Johannes, I'm not as expert as many on this list, but I thought I'd take a stab at answering some of your questions anyways. Looking through your SAS.wsdl, I was curious why you did a <wsdl:import> of the WSRF/WSN wsdls. At least when I created my (much simpler) WS-Resource I did not have to do that. Another point: I noticed that you've split your schema definition for the same namespace into two parts as follows: <xsd:schema elementFormDefault="qualified" targetNamespace="http://www.opengis.net/sas/1.0.0";> <xsd:include schemaLocation="OGC-SAS-1_0_0-sasAll.xsd"/> <xsd:include schemaLocation="OGC-SAS-1_0_0-sasCapabilities.xsd"/> <xsd:include schemaLocation="OGC-SAS-1_0_0-sasCommon.xsd"/> <xsd:include schemaLocation="OGC-SAS-1_0_0-sasDescribeSensor.xsd"/> <xsd:include schemaLocation="OGC-SAS-1_0_0-sasMessageSchema.xsd"/> </xsd:schema> <xsd:schema elementFormDefault="qualified" targetNamespace="http://www.opengis.net/sas/1.0.0";> <xsd:element name="SasResourceProperties"> <xsd:complexType> <xsd:sequence> <xsd:element ref="wsrf-rp:QueryExpressionDialect" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="wsn-b:FixedTopicSet"/> <xsd:element ref="wsn-t:TopicSet" minOccurs="0"/> <xsd:element ref="wsn-t:TopicExpression" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="wsn-t:TopicExpressionDialect" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="muws1:ResourceId"/> <xsd:element ref="muws1:ManageabilityCapability" minOccurs="0" maxOccurs="unbounded"/> <!-- ??? --> <xsd:element ref="muws2:Caption" minOccurs="0" maxOccurs="unbounded"/> <!-- ??? --> <xsd:element ref="muws2:Description" minOccurs="0" maxOccurs="unbounded"/> <!-- ??? --> <xsd:element ref="muws2:Version" minOccurs="0"/> <!-- ??? --> <xsd:element ref="muws2:OperationalStatus"/> <!-- ??? --> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:complexType name="ServiceExceptionType"> <xsd:complexContent> <xsd:extension base="wsrf-bf:BaseFaultType"> <xsd:choice> <xsd:element ref="ows:ExceptionReport"/> <xsd:element ref="ows:Exception"/> </xsd:choice> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="ServiceException" type="sas:ServiceExceptionType"/> </xsd:schema> I am not sure how a parser will interpret this, but my understanding was that each <xsd:schema></xsd:schema> pair is separate from the other. Was there a reason you did not include the imports and message definitions in one <xsd:schema> pair? Also, I assume that all the imported documents are defined in the http://www.opengis.net/sas/1.0.0 namespace or have no namespace? > C:\muse-test\wsdl>wsdl2java.bat -j2ee mini -wsdl SASallinone.wsdl > -output test -verbose > WARNING: [ID = 'NoWSRPSchema'] No WS-RP schema found I'm not quite sure, but this may be because you don't have ResourceMetadataDescriptor document attached to your SAS portType as well as a reference to wsrf-rp:ResourceProperties reference. Perhaps someone can correct me on this? > (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? There are several questions that I have > * 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> > o 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) > o Neither of the capability classes extends AbstractWsResourceCapability - is that due to the fact that I did not extend the resource type with my own elements (i.e., it just lists elements from WSN, WSRF and MUWS)? The capabilities look fine. I've not seen any generated capability extend AbstractWsResourceCapability... > o The registerPublisher method (in MyCapability1) takes the > elements contained in a usual RegisterPublisher request, > i.e. as they are listed in the schema from OASIS, as > parameters. As I said earlier I would like to make use of > the extension mechanism for that operation. Do I therefore > have to modify the schema before generating source code or > is there some way to retrieve the pure request body via muse? Were you planning on extending it using the <xsd:extension>system? > * in general: > o According to the SubscriptionManager.wsdl that is contained > in the generated folders (WebContent/WEB-INF/classes/wsdl) > there will be one subscription manager that will be > referenced in all Subscribe request responses. So will each > subscription reference the same manager? Could you clarify this point? My understanding is that when subscribing, you set the producer EPR to the EPR of the resource that you're subscribing to. That said, all subscribe operations are handled by the same subscription manager under Muse's hood. Any renew, destroy request etc. will contain a subscription reference that (using reference parameters) will identify the exact subscription you want to perform these operations on... I hope this helps a bit at least. Cheers, Allen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
