January 2007 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: Soap with Attachments and document/literal

by jason.greene＠jboss.com

There is support for document/literal attachments. You can have multiple parts as long as there is only one part bound to the soap body. So attachments and headers can also be included. The jaxrpc-mapping.xml file doesnt have a way to indicate attachments, so the way this is determined is by the binding section in the wsdl file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001849#4001849 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001849

18 years

1
0
0 / 0

Re: [JBoss JIRA] Commented: (JBWS-1442) Update cruise control

by Thomas Diesler

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Soap with Attachments and document/literal

by darran.lofthouse＠jboss.com

I have just been looking at http://jira.jboss.com/jira/browse/JBWS-269, I am trying to see how much work will be involved to add support for attachments to wstools. I just wanted to check that my understanding of the current status of the Swa implementation is correct. >From what I can see support for mapping attachments to parameters is complete for RPC/literal. For document/literal it is not possible to map the attachments to message parameters, the only way to handle attachments with document/literal is to use the 'org.jboss.ws.core.jaxrpc.StubExt' API on the client as shown in http://jira.jboss.org/jira/browse/JBWS-1384 and on the server side use the SOAPMessageContext to get the attachment. Is this correct? Do we plan to support mapping to parameters for document/literal endpoints? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001514#4001514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001514

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1452 - WSDL To Java, Array unwrapping.

by darran.lofthouse＠jboss.com

Thanks for the information, I have been looking at the test case for http://jira.jboss.com/jira/browse/JBWS-732 to try and get a better understanding of the expected behaviour of array unwrapping. I have the following defined in my WSDL: - <types> | <schema targetNamespace='http://test.jboss.org/ws/jbws1452/types' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://test.jboss.org/ws/jbws1452/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'> | | <complexType name='testMethod'> | <sequence> | <element name='request' nillable='true' type='tns:RequestStringArray'/> | </sequence> | </complexType> | | <complexType name='RequestStringArray'> | <sequence> | <element name='TheStrings' type='string' maxOccurs='unbounded'/> | </sequence> | </complexType> | | <complexType name='testMethodResponse'> | <sequence> | <element name='result' nillable='true' type='tns:ResponseStringArray'/> | </sequence> | </complexType> | | <complexType name='ResponseStringArray'> | <sequence> | <element name='TheStrings' type='string' maxOccurs='unbounded'/> | </sequence> | </complexType> | | <element name='testMethod' type='tns:testMethod'/> | <element name='testMethodResponse' type='tns:testMethodResponse'/> | </schema> | </types> | <message name='TestEndpoint_testMethod'> | <part element='ns1:testMethod' name='testMethod'/> | </message> | <message name='TestEndpoint_testMethodResponse'> | <part element='ns1:testMethodResponse' name='testMethodResponse'/> | </message> | I believe this matches the wrapped array example from the test case. The complexType 'testMethod' contains a sequence with a single element which references a complexType 'RequestStringArray' which contains a sequence that just contains the array. Using wstools the following method is generated on the SEI: - (Packages removed for readability) | public ResponseStringArray testMethod(RequestStringArray request) | throws RemoteException; | So the first stage of parameter unwrapping has occured but I don't think the array unwrapping has occured, I was expecting the method to look like: - | public String[] testMethod(String[] request) | throws RemoteException; | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001285#4001285 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001285

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1452 - WSDL To Java, Array unwrapping.

by jason.greene＠jboss.com

This code only applies to the root level parameters on the SEI, unwrapping of arrays is also done in XSD processing. The reason it applies to rpc was to make arrays simpler from a client perspective. So the wsdl produced by java-wsdl for foo(String[] blah) would generate the same method signature on the client. The reason its disabled for document/literal is because array unwrapping on the parameter level for a document/literal wrapped message is not needed. I'm not sure why bare was prevented as well, most likely was unintentional. I guess the reason no one complained is that using an array parameter for a bare service is probably rare. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001178#4001178 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001178

18 years

1
0
0 / 0

[Design of JBoss Web Services] - JBWS-1452 - WSDL To Java, Array unwrapping.

by darran.lofthouse＠jboss.com

Could someone please confirm for which WSDL styles we should be unwrapping arrays when an unbounded element is the only element in a complex type. The code that handles the unwrapping is currently wrapped with this: - if (! Constants.DOCUMENT_LITERAL.equals(style)) | { | ... | } So perform the unwrapping for all styles except document/literal. Shouldn't this be the other way round? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001137#4001137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001137

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: Using jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.

by dwin

thanks, another issue that I had was a class not found exception of ParameterMode but that was fixed when I manually moved over the jboss-rpc.jar to the third party lib folder and the lib folder for the app server. Not all tests passed but the vast majority of them did (99% to be exact) Just a question, when do you guys think there will be a stable binary release (beyond beta) for JBossWS (JAXWS) with JBoss 4.0.5? Also, there isn't much documentation for using JAXWS with wstools. I am trying to decipher it whether wstool supports wsimport and wsgen (like the GlassFish implementation) but I am guessing its not entirely there yet. again, thanks for the help View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001108#4001108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001108

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Future direction and state of the WSDLDefinitions API

by jason.greene＠jboss.com

Part of the JAX-WS work I did involved revamping the WSDLDefinitions API to be more accurate with WSDL 1.1 (there were many problems with the previous design that made it impossible to represent the mappings required by JAX-WS). I also brought the API inline with the current version of the WSDL 2.0, as many elements are missing. So basically the current version in trunk is highly focused towards WSDL 2.0. The reason for this is that we now only have one component that generates the model (WSDLGenerator), and the resulting model is capable of serializing to both 1.1 and 2.0 (as soon as the 2.0 writer is fully implemented[further down the roadmap]). This allows for interesting applications. For example, it would theoretically be possible to provide a conversion utility that would read a WSDL 1.1 file, and produce a WSDL 2.0 file by just reading it using WSDL11Reader, and writing it using the final WSDL20Writer. There is only one major difference that has to be accounted for, and that is the change of the RPC style in WSDL 2.0 to be the document/literal wrapped style. So basically the difference here is that there is no equivalent of a message in WSDL 2.0, which means that everything has to be expressed using schema. Therefore anything that used the RPC style in WSDL 1.1 would have to have its parts converted to a schema complexType before it could be serialized correctly. So when using this API, everything operates mainly from the 2.0 perspective. So I would recommend that anyone doing work on this API, or using it take a brief look at WSDL 2.0 spec to get an idea of how it should be used. All of the metadata builders can be looked at for examples as well. There also is some information that is needed for WSDL 1.1 that can't be expressed in 2.0, so in order to have a model that is capable of being serialized to both, you need to provide the extra 1.1 information, which would be ignored when producing a WSDL 2.0 document. For example, since WSDL 2.0 does not have a message component, the message name, and the part names are not used. So in this example, the WSDLInteraceMessageReference object (which is a WSDL 2.0 concept) contains additional properties for the WSDL 1.1 message name, and the part name. As mentioned above the RPC style in WSDL 2.0 is basically document/literal wrapped. This means there is conceptionally only once "part" as you think of it in WSDL 1.1 terms, and that one part maps to a complexType that contains the multiple "parameters". So to support serialization to 1.1 RPC style, there is the notion of a WSDLRPCPart. This is capable of being mapped to both. For WSDL 1.1 this would translate to a message part element, and for WSDL 2.0 this is just extra information about the schema element that represents the "part". Another difference is that headers were designed to be binding only, and are not part of the formal abstract contract which is represented in schema. So when using headers (or attachments) they must be represented directly on the binding API elements of WSDLDefinitions, and not the WSDLInterface. This is actually a loss of information in WSDL 2.0 that prevents determining whether a header is implicit or explicit. In WSDL 1.1 if the header was part of the message containing the body parts, it was assumed that the resulting java code should have this header bound to a parameter(explicit). If it was in a different message it was assumed to not be part of the main contract, and thus not bound to a java parameter, and instead up to a handler or the like to provide it. So in order to allow this information to be maintained when serializing/deserializing to WSDL 1.1 set/getIncludeInSignature is used on the WSDLSOAPHeader to indicate wheter or not it is implicit or explicit. There are a couple of things that still need to be improved. Originally the WSDLDefinitions API was designed to represent a single WSDL 2.0 file, so everything used NCNames. It has since been update to be a final infoset, and uses QNames, but the NCNames are still used in some places. These should all be removed. Also the writers should be updated to use either DOM, JDOM or StAX for writing the document. Currently they serialize everything on their own, which is a potential problem with character escaping. Also the code would be simpler and more maintainable if it relied on a framework to do the heavy lifting. Also everything is ran through DOM to pretty print the output anyway, so this would eliminate an extra parse phase. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001087#4001087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001087

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - such a part must refer to an element named a

by jason.greene＠jboss.com

"darran.lofthouse(a)jboss.com" wrote : I am not sure if that is the case, this at your WSDL your message 'attachRequest' contains two message parts so based on the first requirement for a message to contain only a single part this should also be rejected so I am surprised you are not seeing that - I will have a look and see what happened to that check. | The rule is that it must contain only one part that is bound to body of the message. The service can still contain additional parts if the extra parts are bound to an attachment or a header. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001054#4001054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001054

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - such a part must refer to an element named a

by jason.greene＠jboss.com

"thomas.diesler(a)jboss.com" wrote : In that case a wsdl like this | AFAICS the requriment pertains only the the java realm and not to the abstract contract in wsdl. This is not in the BP since it only governs existing specifications namely WSDL 1.1, which does not have a mechanism to express this convention. The whole reason for the wrapped convention, is to fix the RPC style in WSDL 1.1 by overlaying the RPC requirements on top of a document/literal service. (This is the source of the operation name match requirement). So the intention is that a server component using the wrapped convention would provide hints to any client so that it would use this style as well. However since a WSDL extension was not introduced, the service still works with any thing that understands document/literal (since it is just a convention). So, by design, the wrapped convention is more restrictive than a normal document/literal bare service. The problem was fully addressed in WSDL 2.0, where the wrapped convention became the new RPC style. So, in WSDL 2.0, all of these rules and restrictions you see are officially part of the spec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001051#4001051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001051

18 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev January 2007