On Wed, Mar 18, 2009 at 05:57, Pradeep Fernando <pradee...@gmail.com> wrote:
> hi devs,
>
> @ Andreas,
>
>> What about improving WSDL20ToAxisServiceBuilder to support DOM and/or
>> Axiom directly (I think Woden supports both)?
>
>
> I don't think that would solve our problem, since in the case of WSDL
> s we parse the whole document
> at some point. So it doesn't matter weather Dom or Axiom used inside
> the builder.correct me if I am wrong.
>
Both WSDL4J and Woden support DOM, so the obvious solution is to parse
the WSDL as DOM, check the namespace and then dispatch to WSDL4J or
Woden. The only problem is that WSDL20ToAxisServiceBuilder only
supports URLs and input streams, not DOM documents. That could be
easily changed, so that it is no longer required to parse the WSDL
twice.
> @ Sagara,
>
>> Instead of - if
>> (Constants.NS_URI_WSDL20.
>> equals(documentElementNS.getNamespaceURI()))
>> check try to use Woden WSDLReader in the AxisService class.
>>
>> try{
>> WSDLFactory factory = WSDLFactory.newInstance();
>> WSDLReader reader = factory.newWSDLReader();
>> reader.setFeature(ReaderFeatures.VALIDATION_FEATURE_ID, true);
>> Description descComp = reader.readWSDL(wsdlLoc);
>> }
>>
>> Once you have a org.apache.woden.wsdl20.Description instance you can
>> implement a method something like
>>
>> createClientSideAxisService(wsdlDescription,
>> wsdlServiceName,portName, options);
>
> Yes , this is possible. In fact this is the exact process currently
> use by the Service Client to build a wsdl4j
> definition & passing it as the argument to WSDL11ToaxisServiceBuilder.
> The way you are suggesting seems to
> be based on Exception handling. So once the Exception is thrown from
> this(if the WSDL is 1.1) then we have to
> parse it again to a *wsdl4j.definition* in order to feed the
> WSDL11ToAxisServiceBuilder. So problem is not addressed.
>
> Thanks for your valuable suggestions & ideas,
> still feels the mechanism i used to implement this is better, but
> ready to change it if there is a better way.
> waiting for your comments.
>
> Thanks,
> Pradeep Fernando.
>
