[JBossWS] - wsconsume schema type reference problem
by gryffin
I'm using wsconsume to build the server classes necessary for a top-down implementation of a ws. I get an error that seems to indicate it can't find the type description, but it's there.
C:\wsdev\jboss2>wsconsume -k -p com.boeing.nmt.server.ws -o gen -s src NlsSoap.wsdl
| Invalid wsdl:operation "AssetAssociationSet": its a rpc-literal operation, message part must refer
| to a schema type declaration
| at org.jboss.com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.fail(WSDLModeler.java:2788)
|
Excerpt from WSDL binding:
<binding name="NlsSoapBinding" type="y:SOAPport">
| <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
| <operation name="AssetAssociationSet">
| <soap:operation soapAction="urn:#AssetAssociationSet" style="rpc"/>
| ...
|
Excerpt from portType:
| <portType name="SOAPport">
| <operation name="AssetAssociationSet">
| <input message="y:AssetAssociationSetSoapIn"/>
| <output message="y:AssetAssociationSetSoapOut"/>
| ...
|
Excerpt from message:
| <message name="AssetAssociationSetSoapIn">
| <part name="Selector" element="ns1:AssetSelector"/>
| <part name="AssociationValues" element="ns1:AssociationValues"/>
| </message>
| <message name="AssetAssociationGetSoapIn">
| <part name="Selector" element="ns1:AssetSelector"/>
| </message>
| ...
|
Excerpt from schema:
| <xs:element name="AssetSelector">
| <xs:complexType>
| <xs:sequence>
| <xs:element name="AssetId" type="xs:string"/>
| <xs:element name="OwnerAppId" type="xs:string" minOccurs="0"/>
| </xs:sequence>
| </xs:complexType>
| </xs:element>
| <xs:element name="AssociationValues">
| <xs:complexType>
| <xs:sequence>
| ...
|
Is there some mistake in the WSDL parts shown that prevent wsconsume from matching the schema type with the binding? To me, it looks good. Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045045#4045045
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4045045
19 years, 1 month
[JBoss Seam] - Re: Incremental UI updates in AJAX with rich client state
by TedGoddard
"mdoraisamy" wrote : Too good to be true!
|
| How does ICEFaces know what changed without any support from the object graph ?
| Does it manage the previous request's DOM to be able to indentify the changes ?
| Does it render the object graph into DOM and then does the comparision ?
| Is it a comparision by doing a full scan of DOM tree?
|
Of course, we reserve the right to make internal optimizations in ICEfaces or even radically change the implementation -- such things can be done because we only need to preserve the contract to the developer that standard JSF pages will behave as expected, but they will be updated smoothly and efficiently via Ajax. Currently, though, ICEfaces uses a technique called Direct-to-DOM rendering: The component tree is rendered into a DOM on the server (the output of the components is not parsed, the responseWriter is used like an inverse-SAX for efficiency) and a previous DOM is compared with the current DOM to determine an incremental update. The DOMs are scanned fully, but subtrees are not traversed when differences are found (we will be enhancing this algorithm in the future, but I won't go into that detail here).
"mdoraisamy" wrote :
| If i have returned a value from a query (or intensive processing) in an bean getter will it get executed irrespective of the change ? (which itself is not a problem but to understand the behaviour, so that i can model app correctly)
|
If the getter is for a property referenced by a component rendered on the page, it will be called (this is a JSF behavior, not an ICEfaces behavior). When an application has expensive getters, we typically recommend some form of caching, either in the beans themselves or in the persistence layer.
"mdoraisamy" wrote :
| Any reference/document that explains how ICEFaces does incremental UI updates should be of great help in pushing this case forward in my company. Thanks.
|
The ICEfaces architecture is described in the Developer's guide, but the implementation details have varied over time. It's probably best just to ask us questions on the areas that interest you.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045044#4045044
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4045044
19 years, 1 month