Hi Dan,
No, I haven't commit the rt part code yet, but it's on my working copy,
i'll commit that part later(just had a long vacation, and there are some
conficts , i have to solve, and some unit test failed also), and along
with a demo to show how soap1.2 working.
So, yes, it's just the tools. as the first line of the log explained ;)
I'm think of creating a Soap12BindingFactory, which support Soap12, and
SoapBindigFactory support Soap11, and i have abstracted the common logic
into AbstractSoapBindingFactory, and also move the Ioc related
annotations into the AbstractSoapBindingFactory, but seems that our
ExtensionManager can not handle this situation. I have to work out
another way.(maybe some similar mechanism i used in tools, hope that
will not cause a performance problem, have to test that before i commit)
And of course the RT should also support SOAP1.2 Fault.
I know we'll refactoring the tools, but i think that'll after the
MS1(hopefully MS2), and i want the soap1.2 support included in the MS1,
so i have to hask the current tools ;)
When you say multiple services/bindings,
Do you mean
<wsdl:service name="SOAPService">
<wsdl:port name="SoapPort"
binding="tns:PutLastTradedPriceSoapBinding">
<soap:address
location="http://localhost:9107/SOAPDocLitBareService/SoapPort"/>
</wsdl:port>
<wsdl:port name="Soap12Port"
binding="tns:PutLastTradedPriceSoapBinding">
<soap12:address
location="http://localhost:9107/SOAPDocLitBareService/Soap12Port"/>
</wsdl:port>
</wsdl:service>
Will that cause a problem in current code base? i hope not.
Cheers,
James.
Dan Diephouse 写道:
> Hiya,
> Have you tried this out with the runtime yet? I was just looking at
> the code and noticed we still don't have support for parsing the SOAP
> 1.2 extensors in the SoapBindingFactory. Or is this just tooling
> support at this point?
>
> I am also concerned at this point how we should support multiple
> services/bindings on the same endpoint. Has anyone else thought about
> this? Maybe we have a routing endpoint which selects a particular
> binding based on some criteria?
>
> Thanks for getting the maven upload request in - hopefully they'll get
> it up soon.
> Cheers,
> - Dan
>
> James Mao wrote:
>
>> I have added the wsdl4j 1.6.1 into the maven_repo dir, since maven
>> team have not add wsdl4j1.6.1 into remote repository.
>> So after you update your project, please don't specify the -o in the
>> first build. this will allow maven to load the wsdl4j 1.6.1 from
>> maven_repo and add those artifacts into your home repository.
>> otherwise you will get the following errors:
>>
>> Missing:
>> ----------
>> 1) wsdl4j:wsdl4j:jar:1.6.1
>>
>> Try downloading the file manually from the project website.
>>
>> Then, install it using the command:
>> mvn install:install-file -DgroupId=wsdl4j-DartifactId=wsdl4j \
>> -Dversion=1.6.1 -Dpackaging=jar -Dfile=/path/to/file
>>
>> ----------
>> 1 required artifact is missing.
>>
>> We will remove wsdl4j 1.6.1 when maven team add those artifacts into
>> the remote repository.
>> Related JIRA task: http://jira.codehaus.org/browse/MAVENUPLOAD-1158
>>
>>
>> Thanks,
>> James.
>>
>>> Author: mmao
>>> Date: Sun Oct 8 06:53:28 2006
>>> New Revision: 454143
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=454143
>>> Log:
>>> Tools support soap12
>>>
>>> * Upgrade the wsdl4j from 1.5.2 to 1.6.1
>>> * Turn on the soap12 support.
>>> * To reuse the code, we use the proxy mechanism to support soap12 in
>>> tools.
>>> * Added Soap wsdl extensions model to work as a proxy to soap11 and
>>> soap12. in this way, we changed the least code.
>>> * Remove elementFormDefault attribute from couple wsdl files, which
>>> are not valid wsdl attribute.
>>> * Remove system.out.print from system tests.
>>>
>>>
>>
>>
>
>
|