Public wstools API

[thomas.diesler]

Anil,

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.

[anil.saldhana]

I agree on the XSModel to be included inside the RW based JBossXSModel. I created a top priority JIRA issue for this:
http://jira.jboss.com/jira/browse/JBWS-348

It was only by trial and error that I learnt that the Xerces implementation of XSModel is read only and they do not recommend using their api/model for writing purposes. This was the reason I had to create a seperate JBossXSModel.

Another factor that affected tools was the migration of the wsdl metadata into the server module and now its back in the webservices module. The reappearance of the wsdl metadata into webservices module is good because it will simplify tools code.

Now regarding the JavaToXSD api, I have to disagree a bit. My original intent was to have JavaToXSD to just generate a XSTypeDefinition given a Java class. The introspection of the class for methods and properties, was a concern of the JavaToWSDL layer. But now I see your feedback and on second thought, I think what you are asking is achievable and will be suitable.

The concern of dealing with the class internals can be either with the JavaToWSDL layer or with the JavaToXSD subsystem. I prefer the former and you wish to have the latter. So will get that to you.

[anil.saldhana]

http://jira.jboss.com/jira/browse/JBWS-348 has been resolved. Refactoring is never complete until a few iterations happen. The issue can be reopened if there are any problems noticed.

Additionally, WSDLTypes has been provided a unified Schema Model based on the JBossXSModel. This model has NamespaceItems that are keyed by namespaces and store types/elements/attributes etc. Additionally, the namespaceitems can store the locations of the schema files that contributed to the particular piece of schema model.

The codebase may have some code commented out. They can be removed anytime. I will remove them when I notice them.

To Do:
1) JavaToXSD refactor needs to happen. That is a few hours job.
2) JavaToWSDL API needs to be retrofitted with the new tools schema.
3) Serialization of the Unified Meta Data Model.

Additionally, I would like to know from Thomas (Web Services Layer) if the API for WSDLTypes plus JBossXSModel is intuitive and complete.

[anil.saldhana]

Also, wrt maintaining a hashmap of <namespace,xsmodel>, lets maintain that for sometime. I am going to write a testcase of a wsdl that involves schemas with xsd:include to check the behavior.

IMO, the unified JBossXSModel (or the schema model) is enough to derive all types of schema information including a map of namespace->schemamodel relationship.

Give me a couple of days on this.

[thomas.diesler]

The changes to WSDLTypes are quite confusing

 //The typeNamespace may be different from the targetNamespace of the wsdl
 private String typeNamespace;

 //The Schema Model
 private JBossXSModel schemaModel;

 // 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<JBossXSModel>> schemaModels = new LinkedHashMap<String, List<JBossXSModel>>();

Please explain

1) how a wsdl types element can be associated with a with a single typeNamespace

2) why we need to have a single schemaModel AND a map of schemaModels and how they are different

You should make up your mind how you want to model the wsdl included/imported schemas and implement accordingly.

Please keep in mind that WSDLTypes should be a representation of the wsdl types element not more. It should be as simple as possible, but not simpler. The WS layer operates of the unified meta data model, which can be populated from WSDLTypes.

There is a SchemaLocationRegistryTestCase that covers imported/included schemas.

I reopened the JIRA issue.

[anil.saldhana]

As I have been mentioning, WSDLTypes will contain a single XSModel and no lists of schema models. I am making the change in the next iteration. As per the typeNamespace, it is leakage from the Java->WSDL process, which needs to be removed.