Re: XSD generation for mediator syntax in Synapse

[Asankha C. Perera]

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]