This is how i got the picture from Asankhas proposal. Anyone can built the mediator tree irrespective of whether using the xml or at runtime. All elements in synapse.xml eventually mapped to a mediator or a configurator or a proxy. So inevitably we need a schema to the xml.
Now if we have a fixed mediators, without allowing extensions, then we would have come up with an per known schema, which is static. Since we support extension, we can't pre determine the schema to extensions, and the only way Synapse can generate schema to extensions is at deployment time.
ex: say you added a new mediator <extension:foo/>. At the end of the day, <syn:filter/> mediator should be able to get hold of it and, the schema to the <syn:filter/> should depict that.
So Mediator has its one MeditorFactory. Thus mediator factory hold the schema to the Mediator. Apart that there are common entities where Synapse can import to built the schema. SynapseMediatorFactoryFinder get hold of all the factories and extension factories, so this is the good place to generate schema, and that is what Synapse is doing now.
But if we are pragmatically creating the mediator tree, we would not need to have a Mediator factory, and with current mechanism we will get into trouble if we try to create the schema out of what is available in SynapseMediatorFactoryFinder. IMHO We may need a good look up model or registering model for this.
Thank you
Saminda
On 7/8/06, Hadrian Zbarcea <[EMAIL PROTECTED]> wrote:
Hi,
I am still not sure I understand the issue. 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.
First, Synapse's design suggests that the construction of the mediator tree is independent of configuration in general and xml configuration in particular. One could build its mediator tree programatically (using factories or not). Excellent so far. There is a bootstrapping mechanism in place that is configuration based (SynapseConfigurationBuilder), great, but it is not necessarily tied to xml configuration (actually it is in the current implementation, but it doesn't need to be). And then there is the concrete XML configuration (XMLConfigurationBuilder) with its factories etc.
It is not very hard to conceive a BPELConfigurationBuilder that would build the mediator tree (assuming all needed mediators are implemented) based on a bpel syntax (which is still xml) or OMG's BPMN, or other mechanism. In this case, applying the same logic, the configuration system should produce the equivalent artifact that would allow one to validate the configuration syntax, which obviously doesn't make much sense. So, the feature you are proposing would only make sense, design-wise, for the current xml configuration mechanism.
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. One would need to make sure for instance that changes in the code or the build system do not alter the schema between releases as it is the contract other projects (such as tooling) may rely upon. Again, a lot of ink was spent on all these aspects, I will not repeat them here, but I would gladly answer questions if any.
That said, I believe an xml schema must be defined and validating a configuration artifact is a real requirement. I have no problem with a draft version of the schema being generated from configuration samples. I am just saying that we should follow-up and manually revisit, clean-up and document the schema. I would also gladly volunteer to help with the effort.
The second issue you raised about dependencies is a valid one, but I suspect less so with jdk 1.5.
My 2 cents,HadrianOn 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 :-)
thanksasankha
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)--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
