You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Saminda Abeyruwan <sa...@gmail.com> on 2006/07/07 11:59:11 UTC
Re: XSD generation for mediator syntax in Synapse
On 7/7/06, Asankha C. Perera <as...@wso2.com> 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: synapse-dev-unsubscribe@ws.apache.org For additional
> commands, e-mail: synapse-dev-help@ws.apache.org
>
Re: XSD generation for mediator syntax in Synapse
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi,
So far so good.
> There's absolutely no way to "generate" a schema IMO.
+1.
I forgot to mention in my previous mail that there may be multiple schemas
an xml could be succesfully validated against, each with its nuances. One
more reason why a generated schema may not be the one *intended* by the
designer of the mediator negating the value of validation.
The question now is why is an api needed at all? Do you mean that the API
would return the schema content itself or the schemaLocation? Assuming the
schema is published at the url that defines its targetNamespace, which is a
common practice, both cases seem redundant to me.
So the way I see it is that the only thing we need to do is to define and
publish schema(s) for the configuration of the mediators already supported.
I am planning to come up with something during the weekend unless somebody
beats me to it.
Thanks
Hadrian
On 7/10/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> On Sat, 2006-07-08 at 10:12 -0400, Hadrian Zbarcea wrote:
> > For the life of me, I still don't get it.
> >
> > We can use SynapseMediatorFactoryFinder to find extension factories,
> > no problem, but we cannot assume the factories use xml (and implicitly
> > a schema) for instantiating mediators.
>
> +1.
>
> > So we agree that a schema is needed. We also seem to agree that for
> > the synapse supplied mediators we could supply a schema, no need to
> > generate one. For extensions it is the responsibility of the creator
> > of the extension to document the expected behavior and the
> > configuration mechanism. If this involves xml she should provide a
> > schema as well. If we generate the schema we cannot guarantee that it
> > matches the intent of the extension developer.
>
> I think all that can be done is have a method on the API to get the
> schema and document saying that that may return null because its
> possible the mediator never uses XML. I didn't follow the first part of
> this thread to understand the motivation for a schema but since everyone
> seems to agree that a schema is needed then the only way to do it with a
> method that may return null. There's absolutely no way to "generate" a
> schema IMO.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
Re: XSD generation for mediator syntax in Synapse
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sat, 2006-07-08 at 10:12 -0400, Hadrian Zbarcea wrote:
> For the life of me, I still don't get it.
>
> We can use SynapseMediatorFactoryFinder to find extension factories,
> no problem, but we cannot assume the factories use xml (and implicitly
> a schema) for instantiating mediators.
+1.
> So we agree that a schema is needed. We also seem to agree that for
> the synapse supplied mediators we could supply a schema, no need to
> generate one. For extensions it is the responsibility of the creator
> of the extension to document the expected behavior and the
> configuration mechanism. If this involves xml she should provide a
> schema as well. If we generate the schema we cannot guarantee that it
> matches the intent of the extension developer.
I think all that can be done is have a method on the API to get the
schema and document saying that that may return null because its
possible the mediator never uses XML. I didn't follow the first part of
this thread to understand the motivation for a schema but since everyone
seems to agree that a schema is needed then the only way to do it with a
method that may return null. There's absolutely no way to "generate" a
schema IMO.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: XSD generation for mediator syntax in Synapse
Posted by Hadrian Zbarcea <hz...@gmail.com>.
For the life of me, I still don't get it.
We can use SynapseMediatorFactoryFinder to find extension factories, no
problem, but we cannot assume the factories use xml (and implicitly a
schema) for instantiating mediators.
So we agree that a schema is needed. We also seem to agree that for the
synapse supplied mediators we could supply a schema, no need to generate
one. For extensions it is the responsibility of the creator of the
extension to document the expected behavior and the configuration mechanism.
If this involves xml she should provide a schema as well. If we generate
the schema we cannot guarantee that it matches the intent of the extension
developer.
Regards
hz
On 7/8/06, Saminda Abeyruwan <sa...@gmail.com> wrote:
>
> Hi Hadrian,
>
> 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 <hz...@gmail.com> 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,
> > Hadrian
> >
> >
> >
> > On 7/7/06, Asankha C. Perera <as...@wso2.com> 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 <as...@wso2.com> 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: synapse-dev-unsubscribe@ws.apache.org For
> > > > additional commands, e-mail: synapse-dev-help@ws.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> > > additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> >
> >
>
Re: XSD generation for mediator syntax in Synapse
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Hi Hadrian,
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 <hz...@gmail.com> 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,
> Hadrian
>
>
>
> On 7/7/06, Asankha C. Perera <as...@wso2.com> 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 <as...@wso2.com> 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: synapse-dev-unsubscribe@ws.apache.org For
> > > additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> > additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
>
Re: XSD generation for mediator syntax in Synapse
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi,
I think I understand better know where you're coming from. I think all we
need is there today.
Let me start with an example. Since the <sequence> can contain any kind of
mediators both out-of-the-box or 3rd party not shipped with synapse and
assuming we would enforce a rule that 3rd party mediator schemas *must* be
in a targetNamespace different than the synapse one then the schema for the
<sequence> mediator would look something like:
<xs:schema targetNamespace="[synapse schema url]" xmlns:xs="..." [etc.]
elementFormDefault="qualified">
...
<xs:complexType name="sequenceMediatorType">
<xs:sequence>
<xs:any namespace="##any" processContents="strict"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="sequence" type="tns:sequenceMediatorType"/>
...
</xs:schema>
We need "##any" because we will support both synapse and 3rd party
mediators. We also need processContents="strict" (the default, so we don't
realy need to make it explicit) for obvious reasons.
As I mentioned in my previous mail an xml instance may look like:
<rules xmlns="http://ws.apache.org/ns/synapse"
xmlns:foo="http://www.example.com/synapse/extension/foo
">
<sequence>
<log level="full"/> <!-- for instance -->
<foo:mediator attr="value, etc. etc." />
<sequence>
</rules>
In most cases (as explained in my previous mail) the schema to validate the
syntax for the foo:mediator will be available at the url pointed out by the
namespace, namely "http://www.example.com/synapse/extension/foo". The
MediatorFactory interface already has a method "public QName getTagQName();"
which would return for the above example something like
new QName("http://www.example.com/synapse/extension/foo", "mediator");
which means that it already provides the *implied* location of the schema in
the namespaceURI of the QName returned by getTagQName().
If the schema is available at the http location defined by its namespace the
validator can do its job with no help needed from the factory.
If that's not the case (2nd scenario in my previous mail) or the user
decides to put the schema somewhere else because production systems do not
have access to the internet (just an intranet) or various other reasons,
validation is not possible, unless the validator is told where the actual
schema location is. So there is no way the factory could know about the
real location anyway. Hardcoding the schema itself in the factory is not a
good idea for a number of reasons. But what the factory does tell already
is the targetNamespace of the schema. So what is missing (for this unusual
case) is a mechanism of mapping namespace URLs to xsi:schemLocation URLs
possibly via .properties or some other configuration artifact (but certainly
not hardcoded in the factory) that Synapse would use to initialize the
validator.
The creator of a mediator *should* make the schema available (to make
validation possible) preferrably online at the http address defined by its
targetNamespace or otherwise (such as in a the jar) along with the
corresponding configuration artifact (such that validation would work out of
the box). The user could manually (re)configure the mapping if she decides
to rehost the schema files somewhere else.
I forgot one point, which you mentioned in the original mail when you
referred to a new getTagSchemaType() api. This is not needed either because
in order to make validation possible the way <sequence> is defined above
(<xs:any> has to be used to support mediators not known at this time) a
creator of a mediator *must* define a schema element, not merely a type, and
as such the getTagQName() method is sufficient.
I hope this clarifies what I meant,
Hadrian
On 7/12/06, Asankha C. Perera <as...@wso2.com> wrote:
>
> Hi Hadrian
>
> Could you explain a bit more on how you propose a Mediator writer makes
> the schema available to Synapse? Right now we load implementations of the
> MediatorFactory interface from the classpath (see
> MediatorFactoryFinder:registerExtensions) so I guess the MediatorFactory
> would have to have some means (a method) to let Synapse know which file
> contains the schema for that mediator..?
>
> thanks
> asankha
>
>
> Hadrian Zbarcea wrote:
>
> Hi Asankha,
>
> 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 <as...@wso2.com> 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 <as...@wso2.com> 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 <as...@wso2.com> 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: synapse-dev-unsubscribe@ws.apache.org For
> > > > additional commands, e-mail: synapse-dev-help@ws.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> > > additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> > additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For additional
> commands, e-mail: synapse-dev-help@ws.apache.org
>
Re: XSD generation for mediator syntax in Synapse
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi Asankha,
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 <as...@wso2.com> 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 <as...@wso2.com> 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 <as...@wso2.com> 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: synapse-dev-unsubscribe@ws.apache.org For
> > > additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For
> > additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For additional
> commands, e-mail: synapse-dev-help@ws.apache.org
>
Re: XSD generation for mediator syntax in Synapse
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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,
Hadrian
On 7/7/06, Asankha C. Perera <as...@wso2.com> 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 <as...@wso2.com> 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: synapse-dev-unsubscribe@ws.apache.org For
> > additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org For additional
> commands, e-mail: synapse-dev-help@ws.apache.org
>