Re: XSD generation for mediator syntax in Synapse

[Asankha C. Perera]

Hi Hadrian Let me try to explain a bit more about my recent changes.. What I understand is that you propose a way to generate a schema from the code and you propose additions to the api that would make this possible.  IMHO this is flawed in at least two ways. No. What I propose is to allow a *mediator factory* (not a medaitor) to specify the schema that could be used to validate an XML configuration as well as be used for tooling as you note, or even to generate a UI to configure such a mediator! Now the MedaitorFactory interface is in o.a.s.config.xml package, and is totally about the XML configuration of the mediators. It is one of the ways in which a Mediator writer can specify how instances of the mediator could be created and configured through an XML configuration. I think renaming the MediatorFactory interface as XMLMediatorFactory would help in making things clearer. Also I am in the process of introducing one method to this interface to get the element declaration, instead of the getTagSchemaType() and getTagSchema() pair to make things less complicated (hopefully :-)).. give me a bit of time to do this.. First, Synapse's design suggests that the construction of the mediator tree is independent of configuration in general and xml configuration in particular. Yes, now if you generate the SynapseConfiguration by any other means than through an XML configuration, you will need to perform your validation etc accordingly. Right now, the SynapseConfigurationBuilder is the connection between the XML based configuration and the rest of Synapse. So, the feature you are proposing would only make sense, design-wise, for the current xml configuration mechanism. Unfortunately yes.. when someone introduces another mechanism to create a Synapse configuration, they will have to solve this problem again to suit that environment. Second reason is that I personally prefer the contract first approach.  This sparked many religious debates, and it is not my intent to start one here.  However, I think that the syntax and it's semantics should be defined and documented first and not be an artifact of the build system. The generated schema is not an artifact of the build system - again, we are *not* generating a schema at build or runtime. The mediaor factories defines the schema fragments for each mediator, and at runtime we just collect these to build the overall schema required to validate a configuration. I would also gladly volunteer to help with the effort. As always, your feedback and help is very much appreciated :-).. The second issue you raised about dependencies is a valid one, but I suspect less so with jdk 1.5. Im not sure I understand what you mean here? asankha My 2 cents, Hadrian On 7/7/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote: Saminda Yes, I know that the schema's I checked in may have a few issues to fix..and areas for improvement, as its the initial version.. and greatly appreciate your feedback to get them fixed :-) thanks asankha Saminda Abeyruwan wrote: On 7/7/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote: This is with reference to the chat discussion we had yesterday.. This feature allows mediators to expose the XML configuration syntax for them, through their mediator factories- and thus allows Synapse to validate a configuration, as well as for additional purposes in future. How it is achieved is as follows. The MediatorFactoryFinder loads all core mediators, and dynamically finds any extension mediators from the classpath. Each mediator should have a MediatorFactory which will expose the schema fragment to define its element and complex type. Lets look at some examples The LogMediatorFactory exposes the following schema fragment through its implementation of the public XmlSchema getTagSchema() method <xs:element name="log" type="log_type"/> <xs:complexType name="log_type">   <xs:sequence minOccurs="0" maxOccurs="unbounded">     <xs:element name="property" type="synapse:property_type"/>   </xs:sequence>   <xs:attribute name="level"/>   <xs:attribute name="seperator"/> </xs:complexType> As an example , Wouldn't this should be simplified as follows, <xsd:element name="log>    <xsd:complexType>        <xsd:sequence>              <xsd:element name="property" type="syn:property_type" minOccurs="0" maxOcuurs="unbounded"/>        </xsd:sequence>    </xsd:complexType> </xsd:element> Now as Synapse does not know which complex type in the above fragment defines the type for the Log mediator element, we also need the mediator factory to expose it through the public QName getTagSchemaType() method, which will return "log_type". (A schema fragment as shown above may define more than one complex type - e.g. for the switch mediator) Now if we want to validate a Synapse configuration, we need to include "log_type" as a valid "mediator_type" - please refer [1] which gives a brief sample Synapse.XSD <xs:complexType name="mediator_type">   <xs:sequence>   <xs:choice>     <xs:element name="sequence" type="sequence_type"/>     <xs:element name="log" type="log_type"/>     ...................     <xs:element name="_javascript_" type="_javascript__type"/>   </xs:choice>   </xs:sequence> </xs:complexType> Without "mediator_type" having the "log_type" as a valid choice, we cannot validate a configuration properly. The discussion we had yesterday was more around the extension mediators one would write for Synapse, and the use of the public QName getTagSchemaType() method in that instance. Take a look at the _javascript_ mediator, and how its included into the "mediator_type" set of choices. As we dynamically locate the JS mediator from the classpath and load it as a mediator, we do not know which complex type within its schema fragment defines the actual type for the JS mediator - to be included into the "mediator_type".. I hope this explains why we need the above method on the MediatorFactory The second issue we discussed yesterday was on the dependency of the Apache XmlSchema that we use for the above, to Xalan (and any of its dependencies such as Xerces..) Right now we do not ship any code that requires Xerces or Xalan with the Synapse core - hence the code right now hacks to see if these are available during runtime, and performs the loading of the schemas if its possible, and remains silent (with a WARN log message) if it cannot process the schemas due to the non availability of the above. Your thoughts, comments and suggestions welcome asankha References [1] http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]