I think we agree on all counts except one. Actually I understand it could be done that way, but I don't necessarily agree that we solve any problem.
What I understand is this. We, and any implementor of a mediator that can be instantiated using xml will need to:
1. Define the semantics of the mediator and its configuration. Formalize the xml configuration in an xml schema.
2. Implement the factory and the mediator.
Now, the xml configuration will look something like:
<rules xmlns="http://ws.apache.org/ns/synapse" xmlns:foo="http://www.example.com/synapse/extension/foo ">
<log level="full"/> <!-- for instance -->
<foo:mediator attr="value, etc. etc." />
</rules>
I think it makes sense to enforce a rule (and it's an assumption I'm making) that extensions written by third parties MUST be in a target namespace *other* than the Synapse namespace. Then a namespace mapping MUST exist in the xml file (the foo namespace prefix above). The targetNamespace of the custom extension could be an http based url (usually the case) or not. If it is an http based url the definition of schema could be available (usually true) at that url or not. We have two situations now.
1. The xml schema is available at the http location specified as targetNamespace.
2. The url is not http based or is not available at the specified url.
In the first case the validator will use the schema at the http location for validation, and that schema should be considered the authoritative source, in which case the copy of the schema available from the factory had imho no value. Tools and any interested parties could access the schema at the http url or make a local copy, etc.
In the second case we need to make the schema available to the validator at a location specified via a url and the api won't help in this case either.
In both cases the schema could (must for 2nd case) be packaged in the jar anyway and I think this is a better solution which does not require and api change.
Regards
Hadrian
On 7/11/06, Asankha C. Perera <[EMAIL PROTECTED]> wrote:
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)--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
