Sounds like a decent approach but I do have a concern: by returning Definition you're forcing WSDL 1.1 only. The approach of "put whatever you need into AxisService so that printWSDL() does the right thing" allows us to support both WSDL 1.1 and 2.0 nicely.

Can we modify your proposal a bit:

interface WSDLDataSupplier {
  void fillWSDLData (AxisService as);
}

and then have printWSDL() call this first always. This way the person writing the new provider (message receiver) gets a chance to populate the necessary bits into the AxisService hierarchy so that we'll automatically get correct WSDL 1.1 or 2.0 depending on whether ?wsdl or ?wsdl2 was called.

Thoughts?

Sanjiva.

Glen Daniels wrote:
[Resending with correct prefix. Please reply on THIS thread]

Hi folks!

So I've got a custom deployer which wants to be able to generate its own
WSDL (via "?wsdl") for the artifacts it deploys.  Unfortunately there's
no really good way that I've found in the Axis2 architecture to do that. :(

In Axis1, WSDL generation was the responsibility of the "Provider", so
if you had a different backend (script, etc), you'd have a different
Provider which would know to generate WSDL in a different way.  In
Axis2, WSDL generation seems to happen via AxisService.printWSDL().
This either ends up expecting a Definition object (from WSDL4J) to be
sitting in the "wsdl4jDefinition" parameter of the AxisService (if
useOriginalWSDL is set), or it calls out to the WSDLDataLocator to
generate the WSDL with the AxisService2WSDL* classes.

Neither of these cases was right for what I need to do, since I can't
pre-create the WSDL and leave it in the parameter, and there's no way to
plug in a new WSDL generator so that I could customize the output of
WSDLDataLocator.

So I've introduced a small interface called WSDLSupplier:

public interface WSDLSupplier {
    Definition getWSDL(AxisService service) throws AxisFault;
}

I added a check in printWSDL() to see if there was a WSDLSupplier
sitting in the "WSDLSupplier" parameter of the AxisService.  If so, it
attempts to call the WSDLSupplier to obtain the Definition object from
there dynamically.  It then runs that WSDL through the usual
printDefinitionObject() API.  This allows my custom service to plug in
and generate its own WSDL.

I just wanted to give y'all a heads-up before I checked this into the
tree, as it's a slight API change (but only an addition) for 1.3.

Is there a better way to do this?

--Glen

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to