Public wstools API
thomas.diesler Aug 4, 2005 3:30 AMAnil,
I made a few minor changes to the JavaToWSDL (1.52) API. I think this is clean now. Except that the features it supports should be enforced and documented. See org.jboss.ws.jaxrpc.CallImpl for an example.
The configuration that we support in jbossws-tools.xsd should map cleanly to JavaToWSDL API calls. That still needs to be done.
The JavaToXSD (1.23) API is still much too complicated. This needs to be refactored in a similar way. Additionally to some property getters/setters, it should really be offering only these methods
JBossXSModel generateForEndpoint (Class epSEIorImpl) JBossXSModel generateForSingleType (Class javaType)
or am I missing something? JBossXSModel should make max reuse of the xerces XSModel, but not leak it ouside its private space. It is implementation detail.
JBossXSModel should allow me to add complexTypes, globalElements, etc. There should be a XSDWriter that can serialize the model, which I think we have.
WSDLToJava as implemented by the WSDLDefinitionsFactory is ok.
WSDL11Reader (1.6) uses direct calls to the xerces API. The read-only XSModel leaks into WSDLTypes, which then cannot be modified any more. This is nonsense.
private XSModel parseSchema(URL fileurl) { XSLoader xsloader = new XMLSchemaLoader(); XSModel xsmodel = xsloader.loadURI(fileurl.toExternalForm()); return xsmodel; } should be private JBossXSModel parseSchema(URL fileurl) { ... }
In WSDLTypes we have
// This registry maps a schema target namespace to the extracted schema model. // The registry is populated at parse time. It is possible that the wsdl types element // contains multiple schema definitions some assigned to the same target namespace. // This especially occurs when a schema uses xsd:include elements private Map<String, List<XSModel>> schemaModels = new LinkedHashMap<String, List<XSModel>>(); // This registry maps a schema target namespace to the extracted temp file URL for that schema. // It is populated at parse time. Ideally this map should disappear and clients of this class // should work with the XSModel map exclusively. They may then serialize and cache the models if // needed. It is not clear to me how this can be done since XSModel cannot be written out easily. // A possible solution would be to maintain a Map<String, List<JBossXSModel>> private Map<String, List<URL>> schemaLocations = new LinkedHashMap<String, List<URL>>(); should be a registry for read/write JBossXSModel, maybe similar to private Map<String, List<JBossXSModel>> schemaModels = new LinkedHashMap<String, List<JBossXSModel>>();
WSDLTypes should not have a registry of temp files to schema URLs.
If clients of WSDLTypes require a URL to a schema they can serialize JBossXSModel and maybe cache it if appropriate.
These refactorings have been discussed in bits on various occasions. Do we have JIRA issues that we can reference from here?
IMHO, these refactorings are most critical because they provide the API that the tools project itself needs to rely on, let alone its clients.