The idea of lazy-initialization of SOAPProxy has been discussed ad nauseam in the forum thread: SOAPProxy initialization and deployment ordering. I know it's a long thread, but it's worth reading I believe.
The biggest problem I believe is when I said, "If we went with a lazy approach, then we would have a deployed service for which we would not be able to expose WSDL for! We need to pull in the WSDL on initialization so we can transform it and provide it to consumers of the ESB. If we went the lazy way, we would get more bug reports from people saying 'WSDL contract unavailable!'".
Agreed however making the whole ESB deployment fail because of one errant Web Service seems severe.
It would be great if you had a property to allow me to fail, ignore, retry, use cache, construct on first request, etc.
Right now the code constructs temporary files to cache the WSDL, XSDs, failing back on the temp files would be acceptible under certain conditions.
Of course they would have to be named by category+service-name in order to resolve.
It would also be great if the ?wsdl request entered the pipeline first, this would have made it easier for me to do fixups on modular wsdls, use local wsdl caching, etc. My SOAPProxy wraper is getting bigger. I'm adding a WSDL+XSL HTML doc render now.
Finally I'd like to be able to parse the WSDL via JMX for one of nnn exposed web services, so I don't have to bounce the whole ESB.
BTW - I'm pushing some of these issues via redhat.com support too, sorry about the overlap.