Taking a lok at this now. A couple questions/thoughts:

• Did you think about making the WSDLBuilder take a list of WSDLExtensions? It might be handy if you want to have more than one extension
• Why would you need to add something before the portType or binding is created? (i.e. why would someone use beforeConcreteInterface)
• Did you think about a visitor patter at all? i.e. after the wsdl is created we could visit each part of the wsdl. See this class:

http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/wsdl11/WSDLVisitor.java?r=833

Looks good for the most part though! I'm interested in your feedback to those questions before we commit something.

• Did you think about making the WSDLBuilder take a list of WSDLExtensions? It might be handy if you want to have more than one extension
  • Yes, in fact that was my first thought as that would be a similar approach to the approach taken with the In+Out Handlers. However I couldn't see a neat way to inject the list into the WSDLBuilder instances as currently it is Factories that are injected not WSDLBuilders, so I then went off down the root of injecting a list of Extensions by creating a special factory. At this point I realised there was little point forcing the WSDLBuilder to take on the semantics of iterating over a list of extensions when this could be done implicitly by using the decorator pattern to nest repeated instances, so the order that WSDBUilderExtensions were wrapped implicitly defined the list, I also thought you might want to do something around a change made by some other extension so by wrapping them you had the option of maintaining the state before and after. However I don't feel particularly strongly one way or t'other I created the code to foster a discussion because I feel being able to manipulate the generated WSDL is something that will be very useful to many people <g>

• Why would you need to add something before the portType or binding is created? (i.e. why would someone use beforeConcreteInterface)
  • Good question, it's quite obviously redundant, I left it in so that a WSDLExtension implementor could have a better understanding of exactly what point in the process they were injecting their new behaviour, but perhaps a better name for 'afterCreateAbstractInterface' and 'beforeCreateConcreteInterface' could be in order.

• Did you think about a visitor patter at all? i.e. after the wsdl is created we could visit each part of the wsdl. See this class:
  • I did yes, however I've never been a particular fan of the visitor pattern, normally because it exposes the internal interface, but in this case we're doing it anyway. I guess on the one hand it is an elegant solution so multiple visitors could be used, but on the other hand it could be quite inefficient because the majority case is likely to be adding a element(s) to the wsdl:definition. So perhaps the Visitor pattern is quite a bit of an overkill, in that each visitor specified would be called-back to for every part of the document, and also [and I'd need to check the specific semantics of that visitor pattern], if you add new sections to the WSDL, say partner-links etc, to be true visitor you'd want to pass back those nodes to the visitor's visit method(s), which you won't know until run-time, so you'd have a default elements pass-back, but then why bother with the visitor ?

As I said before, I have no strong feelings on implementation details, my design ideals would be something that promotes (in order of care) :
i) Re-use of extensions
ii) Easy configuration via Spring/Services.xml
iii) Looser coupling i.e. less dependence on Inheritance hierarchies, and more on interface injection.

Cheers

• ciaran

void extend(Definition d, WSDLBuilder builder)

Let me know if that works for you!