Chat Log

["Asankha C. Perera" <as...@wso2.com>]

Here is a list to a sample XSD we generate 
http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD as 
mentioned below

* Now talking in #apache-synapse
* paulfremantle has joined #apache-synapse
<asankha> hi Paul
* ant has joined #apache-synapse
<ant> hi
<asankha> hi Ant
<paulfremantle> hi
<ant> Did you get back from apachecon with out too much trouble?
<asankha> we did.. though we missed one flight, we were able to get on 
the next one..
<paulfremantle> so
<paulfremantle> i know its quiet today
<paulfremantle> a couple of things
<paulfremantle> 1) ant - did you read the registry wiki i posted
<paulfremantle> that was the final point asankha and i got to on friday
<ant> actually not yet in great detail. I'll do that right after this chat
<paulfremantle> ok
<paulfremantle> theres really three parts to it
<paulfremantle> 1) being able to bootstrap "properties" from an external 
xml - either src (just a URL) or key (a "reg" lookup)
* saminda has joined #apache-synapse
<saminda> hi all
<paulfremantle> hi
* hzbarcea has joined #apache-synapse
<paulfremantle> hi hadrian
<hzbarcea> hi
<paulfremantle> 2) instead of mediators loading XML from outside they 
can get it from properties
<asankha> hi hadrian
<hzbarcea> hi everybody
<ant> hi
<paulfremantle> 3) if we pull it from a "registry" then its dynamic but 
cached
<ant> ok. that all sounds good
<paulfremantle> and we had some idea of how we could cache any 
"compilation"
<paulfremantle> e.g. a script or XSLT
<asankha> we should be able to get something working by next week on 
these lines.. so that we can refine it
<paulfremantle> cool
<hzbarcea> I have a question
<paulfremantle> shoot!
<hzbarcea> what are the rules with the wiki site
<paulfremantle> rules?
<paulfremantle> wiki?
<hzbarcea> i created an account yesterday and i would like to update 
some pages
<paulfremantle> afaik anyone can edit pages
<hzbarcea> but i am not a commiter
<hzbarcea> technically yes
<paulfremantle> go ahead :-)
<hzbarcea> thx
<paulfremantle> we'd welcome the help
<asankha> yes.. it'll be great to get the documentation reviewed
<asankha> do not change the main pages though... but whats in the 
"InProgress" section...
<hzbarcea> i thought that as i learn i could capture the knowledge somewhere
<asankha> unless its a typo etc..
<hzbarcea> no, not the main page, of course
<hzbarcea> and anybody could revert my changes and give me a yellow card 
if you don't like it :)
<asankha> you could create new pages as well inside 
http://wiki.apache.org/incubator/Synapse/InProgr
ess and link from there
<paulfremantle> so the other thing i wanted to discuss today was how we 
use policy
<asankha> yep
<paulfremantle> so now we are adding rm and sec support
<paulfremantle> it would be good to have a common way of configuring those
<paulfremantle> for both incoming (proxy) and outgoing (endpoints)
<paulfremantle> so I am in favour of using
<paulfremantle> <wsrmp:RMAssertion>
<paulfremantle> in other words the actual ws policy
<paulfremantle> but that might be a little complex in some cases
<paulfremantle> so how about we let you do
<paulfremantle> EITHER
<paulfremantle> 1) the full WS-Policy (including any Sandesha/Rampart 
extensions)
<paulfremantle> or
<paulfremantle> 2) an alias: <syn:enableRM>, <syn:enableWSS>
<paulfremantle> in which case it takes the default from the underlying 
config of sandesha or rampart
* ant_ has joined #apache-synapse
<ant_> hi, sorry PC crashed
<paulfremantle> when?
<ant_> when the converstation about updating the wiki started
<ant_> did i miss anything?
<asankha> i guess so.. about the WS RM and Sec discussion
<paulfremantle> [13:20] hzbarcea: thx
<paulfremantle> [13:20] asankha: yes.. it'll be great to get the 
documentation reviewed
<paulfremantle> [13:21] asankha: do not change the main pages though... 
but whats in the "InProgress" section...
<paulfremantle> [13:21] hzbarcea: i thought that as i learn i could 
capture the knowledge somewhere
<paulfremantle> [13:21] asankha: unless its a typo etc..
* paulfremantle has quit IRC (Excess Flood)
<asankha> hmm... seems like NW trouble for all :-)
* paulfremantle has joined #apache-synapse
<asankha> <paulfremantle> so now we are adding rm and sec support
<asankha> <paulfremantle> it would be good to have a common way of 
configuring those
<asankha> <paulfremantle> for both incoming (proxy) and outgoing (endpoints)
<asankha> <paulfremantle> so I am in favour of using
<asankha> <paulfremantle> <wsrmp:RMAssertion>
<paulfremantle> ha
<asankha> <paulfremantle> in other words the actual ws policy
<asankha> <paulfremantle> but that might be a little complex in some cases
<asankha> <paulfremantle> so how about we let you do
<asankha> <paulfremantle> EITHER
<asankha> <paulfremantle> 1) the full WS-Policy (including any 
Sandesha/Rampart extensions)
<asankha> <paulfremantle> or
<asankha> <paulfremantle> 2) an alias: <syn:enableRM>, <syn:enableWSS>
<asankha> <paulfremantle> in which case it takes the default from the 
underlying config of sandesha or rampart
<paulfremantle> i tried posting it but it disconnected me :-)
<asankha> i think you posted too much in one go :-)
<asankha> Ant.. thats the part you missed.. so we can go on Paul
<paulfremantle> that was it!
<hzbarcea> i agree that using thw <wsrmp:RMAssertion> is a good way to 
go as its semantic is clear
<hzbarcea> but since one has to instantiate the mediator
<hzbarcea> isn't it ok to use a wrapper
<hzbarcea> which wraps the assertion if you want to replace the default
<hzbarcea> as in
<asankha> well.. actually what Paul is describing is not a mediator.. we 
"will" have a mediator to
perform RM/Sec too
<paulfremantle> yes thanks asankha
<hzbarcea> <enableRM/> - use the deffault
<hzbarcea> or <enableRM>
<hzbarcea>   <wsrmp:RMAssertion> ...
<asankha> The idea is that you can request enabling of RM/Sec on an 
Endpoint or Proxy using the above mentioned Tags within the Proxy or 
Endpoint Tags
<paulfremantle> i wasnt clear.... this is a subelement of <proxy> or 
<endpoint>
<hzbarcea> </enableRM>
<paulfremantle> really what i was thinking was
<paulfremantle> <endpoint>
<paulfremantle>   <policy>
<paulfremantle>    <wsx:xpolicy/>
<ant_>  by default do you mean a Synapse global WSRM or WSSec default? 
<paulfremantle> </policy></endpoint>
<paulfremantle> But
<paulfremantle> I figured maybe we could just bypass the <policy> tags
<paulfremantle> to make it simple
<paulfremantle> well neethi (policy framework) has all kinds of clever 
inheritance stuff
<paulfremantle> so possibly we could make things inherit defaults from 
the parent
<paulfremantle> or maybe we keep the <policy> tag
<paulfremantle> if you use the full version
<paulfremantle> and <enableRM/> is an alias for 
<policy><wsrmp:RMAssertion/></policy>
* Retrieving #apache-synapse modes...
<paulfremantle> so in either <endpoint> or <proxy> you could have
<paulfremantle> <policy> any ws policy at all </policy>
<paulfremantle> <endpoint><enableRM/><enableWSS/></endpoint>
* ant has quit IRC (Read error: 110 (Connection timed out))
* ant has joined #apache-synapse
<asankha> yes.. i guess the common case is that usually WS-sec for each 
Proxy/Endpoint would be different.. and how we would specify those 
security properties
<paulfremantle> then in that case you'd have to use the full policy
<ant> sorry, NW problems so I'd dropped out again. carry on though i'll 
catch up when the log is posted
<paulfremantle> if you come on again we'll have 3 ants
<paulfremantle> which is nearly a colony
<ant> LOL
<paulfremantle> asankha do you think that will work
<ant> i've an off topic question if you've finished with WS-* things
<asankha> yes.. i guess it will..
<paulfremantle> go ahead ant
<asankha> but i dont think we can specify things like the keystore and 
identity etc to be used for a sec operation through policy.. or can we?
<ant> the mediator interface now has a getType method. I wondered if 
that was really necessary or could be put somewhere else?
<paulfremantle> yes im not sure we need that
<paulfremantle> on the mediator
<paulfremantle> maybe on the mediatorfactory?
<asankha> ant.. thats a good question.. let me explain why i need it
<asankha> actually paul we have it on the mediator factory
<asankha> the mediator factory now returns the XML schema for its mediator
<asankha> so the schema fragment usually defines a complex type like 
<mediator>_type
<asankha> and we need to include this type as a valid choice for the 
mediator_type complex type which is defined as follows
<asankha> <xs:complexType name="mediator_type">
<asankha>         <xs:sequence maxOccurs="unbounded">
<asankha>             <xs:choice>
<asankha>                 <xs:element name="send" type="synapse:send_type"/>
<asankha>                 <xs:element name="drop" type="synapse:drop_type"/>
<asankha> ....
<asankha> <xs:element name="in" type="synapse:in_type"/>
<asankha>                 <xs:element name="out" type="synapse:out_type"/>
<asankha>             </xs:choice>
<asankha>         </xs:sequence>
<asankha>     </xs:complexType>
<asankha> so that the schema would be valid and complete
<paulfremantle> couldn't we just do an <xs:any> at that point
<asankha> but the problem is.. the "mediator_type" complex type is 
defined programmatically looking at the available extensions
<paulfremantle> to handle the extension
<asankha> well.. thats what i wanted to do first..
<asankha> but this way you wont be able to validate them
<paulfremantle> true
<asankha> you cannot define a choice with <xs:anyType>
<ant> what do you mean "the mediator factory now returns the XML 
schema", which class/method are you talking about so i can go look?
<asankha> the other option is to always expect the complex type name to 
be "<mediator>_type"
<asankha> and thats what we do for the core mediators... if you extend 
from the Abstract
<paulfremantle> asankha I'm still not clear how we can validate if 
someone has plugged in their own extension
<hzbarcea> you can if xs:any if from namespace="##other"
<asankha> shall i post the draft synapse.xsd i have and a sample XML to 
the mailing list.. and we could all try it out, suggest and decide?
<paulfremantle> great
<hzbarcea> i have a quick q
<hzbarcea> are there any tools for synapse or any plans for tools?
<hzbarcea> gui and/or other stuff
<asankha> i just posted a quick copy of a generated schema.. 
http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD
<paulfremantle> not yet Hadrian
<paulfremantle> we would like to get the base stable first
<asankha> for example.. look at this
<asankha> <xs:complexType name="spring_type">
<asankha> <xs:attribute name="bean" type="xs:string" use="required"/>
<asankha> <xs:attribute name="config" type="xs:string"/>
<asankha> <xs:attribute name="src" type="xs:string"/>
<asankha> </xs:complexType>
<asankha> we also have spring_type as a possible choice in the 
mediator_type (as I said before)
<paulfremantle> the problem is that this isn't extensible
<asankha> so now you can validate a config with the spring mediator
<paulfremantle> if I write a paul.jar that adds support for the paul 
mediator <paul src="http://fremantle.org/paul.xml"/>
<paulfremantle> then how can we validate?
<asankha> your PaulMediatorFactory should expose something like follows...
<asankha> a method public XmlSchema getTagSchema(); which exposes your 
schema "fragment"
<asankha> something like whats below..
<asankha> <xs:complexType name="spring_type">
<asankha> <xs:attribute name="bean" type="xs:string" use="required"/>
<asankha> <xs:attribute name="config" type="xs:string"/>
<asankha> <xs:attribute name="src" type="xs:string"/>
<asankha> </xs:complexType>
<paulfremantle> ok
<paulfremantle> and then?
<asankha> and then the public QName getTagSchemaType() should state the 
complex type name that defines your mediator in the above schema
<paulfremantle> but we cannot use "pure XSD" validation
<asankha> i.e. "spring_type" for above
<paulfremantle> outside of Synapse
<asankha> you mean on the paul.jar file?
<paulfremantle> i mean that if I have the schema plus a validator tool
<paulfremantle> I can't just run it
<paulfremantle> Synapse can because synapse could extract all the schema 
fragments and validate the whole
<paulfremantle> but a standard XSDValidator couldnt'
<asankha> well.. yes..
<asankha> we actually have the mediator_type and property_type common 
types in a common place
<paulfremantle> maybe we should build an option into Synapse.bat to 
validate the config
<asankha> but we could ship the synapse.xsd for the core mediators
<asankha> and anyone could import it and use it
<asankha> we can do that.. that brings me to the second problem i 
encountered :-)
<asankha> XmlSchema uses Xalan underneath...
<asankha> which we do not ship by default with the synapse core release!
<asankha> so right now i have it generate the schema's only if Xalan and 
its dependencies (Xerces) are available.. and issue a WARN if not
<asankha> since it will still enable you to run Synapse without a problem
<asankha> but if the dependenceis are met.. it will work fine and also 
be able to validate
<asankha> I guess thats the best for right now is it Paul? or do we 
begin to get Xalan into our code dependencies set?
<paulfremantle> hmmmm
<paulfremantle> its a shame
<paulfremantle> maybe we should ask the xmlschema guys if theyu can do 
without it
<asankha> well.. interestingly thats one of the main objectives of the 
XmlSchema according to the web page...
* ant_ has quit IRC (Read error: 113 (No route to host))
<asankha> but i guess they need to reuse as opposed to reinvent the wheel
<asankha> :-(
<paulfremantle> mmm
<asankha> lets look at this during the coming week and decide next week 
how we want to progress?
<paulfremantle> yes
<paulfremantle> i have to go as well
<asankha> yes.. i think we had a good discussion today ..
<paulfremantle> i need to look through the schema stuff
<paulfremantle> yes thanks
<paulfremantle> +1
<asankha> hopefully Ant will catch it up too..
<asankha> ok.. see you all later.. i will post this to the mailing list
<ant> yes. I've only just sync SVN now and seen all the schema stuff...
<ant> Paul, we've a Tuscany chat at 5pm if you wantt o come along
<paulfremantle> cool
<paulfremantle> i will if i can
<ant> (and anyone else if you're interested)
<paulfremantle> :-)



---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org

Re: Chat Log

[Paul Fremantle <pz...@gmail.com>]

Asankha

Could you please post an overall description of how the XSD validation
is planned to work. I realise now I'm re-reading the chat that I
didn't get it!

Paul

On 7/6/06, Asankha C. Perera <as...@wso2.com> wrote:
> Here is a list to a sample XSD we generate
> http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD as
> mentioned below
>
> * Now talking in #apache-synapse
> * paulfremantle has joined #apache-synapse
> <asankha> hi Paul
> * ant has joined #apache-synapse
> <ant> hi
> <asankha> hi Ant
> <paulfremantle> hi
> <ant> Did you get back from apachecon with out too much trouble?
> <asankha> we did.. though we missed one flight, we were able to get on
> the next one..
> <paulfremantle> so
> <paulfremantle> i know its quiet today
> <paulfremantle> a couple of things
> <paulfremantle> 1) ant - did you read the registry wiki i posted
> <paulfremantle> that was the final point asankha and i got to on friday
> <ant> actually not yet in great detail. I'll do that right after this chat
> <paulfremantle> ok
> <paulfremantle> theres really three parts to it
> <paulfremantle> 1) being able to bootstrap "properties" from an external
> xml - either src (just a URL) or key (a "reg" lookup)
> * saminda has joined #apache-synapse
> <saminda> hi all
> <paulfremantle> hi
> * hzbarcea has joined #apache-synapse
> <paulfremantle> hi hadrian
> <hzbarcea> hi
> <paulfremantle> 2) instead of mediators loading XML from outside they
> can get it from properties
> <asankha> hi hadrian
> <hzbarcea> hi everybody
> <ant> hi
> <paulfremantle> 3) if we pull it from a "registry" then its dynamic but
> cached
> <ant> ok. that all sounds good
> <paulfremantle> and we had some idea of how we could cache any
> "compilation"
> <paulfremantle> e.g. a script or XSLT
> <asankha> we should be able to get something working by next week on
> these lines.. so that we can refine it
> <paulfremantle> cool
> <hzbarcea> I have a question
> <paulfremantle> shoot!
> <hzbarcea> what are the rules with the wiki site
> <paulfremantle> rules?
> <paulfremantle> wiki?
> <hzbarcea> i created an account yesterday and i would like to update
> some pages
> <paulfremantle> afaik anyone can edit pages
> <hzbarcea> but i am not a commiter
> <hzbarcea> technically yes
> <paulfremantle> go ahead :-)
> <hzbarcea> thx
> <paulfremantle> we'd welcome the help
> <asankha> yes.. it'll be great to get the documentation reviewed
> <asankha> do not change the main pages though... but whats in the
> "InProgress" section...
> <hzbarcea> i thought that as i learn i could capture the knowledge somewhere
> <asankha> unless its a typo etc..
> <hzbarcea> no, not the main page, of course
> <hzbarcea> and anybody could revert my changes and give me a yellow card
> if you don't like it :)
> <asankha> you could create new pages as well inside
> http://wiki.apache.org/incubator/Synapse/InProgr
> ess and link from there
> <paulfremantle> so the other thing i wanted to discuss today was how we
> use policy
> <asankha> yep
> <paulfremantle> so now we are adding rm and sec support
> <paulfremantle> it would be good to have a common way of configuring those
> <paulfremantle> for both incoming (proxy) and outgoing (endpoints)
> <paulfremantle> so I am in favour of using
> <paulfremantle> <wsrmp:RMAssertion>
> <paulfremantle> in other words the actual ws policy
> <paulfremantle> but that might be a little complex in some cases
> <paulfremantle> so how about we let you do
> <paulfremantle> EITHER
> <paulfremantle> 1) the full WS-Policy (including any Sandesha/Rampart
> extensions)
> <paulfremantle> or
> <paulfremantle> 2) an alias: <syn:enableRM>, <syn:enableWSS>
> <paulfremantle> in which case it takes the default from the underlying
> config of sandesha or rampart
> * ant_ has joined #apache-synapse
> <ant_> hi, sorry PC crashed
> <paulfremantle> when?
> <ant_> when the converstation about updating the wiki started
> <ant_> did i miss anything?
> <asankha> i guess so.. about the WS RM and Sec discussion
> <paulfremantle> [13:20] hzbarcea: thx
> <paulfremantle> [13:20] asankha: yes.. it'll be great to get the
> documentation reviewed
> <paulfremantle> [13:21] asankha: do not change the main pages though...
> but whats in the "InProgress" section...
> <paulfremantle> [13:21] hzbarcea: i thought that as i learn i could
> capture the knowledge somewhere
> <paulfremantle> [13:21] asankha: unless its a typo etc..
> * paulfremantle has quit IRC (Excess Flood)
> <asankha> hmm... seems like NW trouble for all :-)
> * paulfremantle has joined #apache-synapse
> <asankha> <paulfremantle> so now we are adding rm and sec support
> <asankha> <paulfremantle> it would be good to have a common way of
> configuring those
> <asankha> <paulfremantle> for both incoming (proxy) and outgoing (endpoints)
> <asankha> <paulfremantle> so I am in favour of using
> <asankha> <paulfremantle> <wsrmp:RMAssertion>
> <paulfremantle> ha
> <asankha> <paulfremantle> in other words the actual ws policy
> <asankha> <paulfremantle> but that might be a little complex in some cases
> <asankha> <paulfremantle> so how about we let you do
> <asankha> <paulfremantle> EITHER
> <asankha> <paulfremantle> 1) the full WS-Policy (including any
> Sandesha/Rampart extensions)
> <asankha> <paulfremantle> or
> <asankha> <paulfremantle> 2) an alias: <syn:enableRM>, <syn:enableWSS>
> <asankha> <paulfremantle> in which case it takes the default from the
> underlying config of sandesha or rampart
> <paulfremantle> i tried posting it but it disconnected me :-)
> <asankha> i think you posted too much in one go :-)
> <asankha> Ant.. thats the part you missed.. so we can go on Paul
> <paulfremantle> that was it!
> <hzbarcea> i agree that using thw <wsrmp:RMAssertion> is a good way to
> go as its semantic is clear
> <hzbarcea> but since one has to instantiate the mediator
> <hzbarcea> isn't it ok to use a wrapper
> <hzbarcea> which wraps the assertion if you want to replace the default
> <hzbarcea> as in
> <asankha> well.. actually what Paul is describing is not a mediator.. we
> "will" have a mediator to
> perform RM/Sec too
> <paulfremantle> yes thanks asankha
> <hzbarcea> <enableRM/> - use the deffault
> <hzbarcea> or <enableRM>
> <hzbarcea>   <wsrmp:RMAssertion> ...
> <asankha> The idea is that you can request enabling of RM/Sec on an
> Endpoint or Proxy using the above mentioned Tags within the Proxy or
> Endpoint Tags
> <paulfremantle> i wasnt clear.... this is a subelement of <proxy> or
> <endpoint>
> <hzbarcea> </enableRM>
> <paulfremantle> really what i was thinking was
> <paulfremantle> <endpoint>
> <paulfremantle>   <policy>
> <paulfremantle>    <wsx:xpolicy/>
> <ant_>  by default do you mean a Synapse global WSRM or WSSec default?
> <paulfremantle> </policy></endpoint>
> <paulfremantle> But
> <paulfremantle> I figured maybe we could just bypass the <policy> tags
> <paulfremantle> to make it simple
> <paulfremantle> well neethi (policy framework) has all kinds of clever
> inheritance stuff
> <paulfremantle> so possibly we could make things inherit defaults from
> the parent
> <paulfremantle> or maybe we keep the <policy> tag
> <paulfremantle> if you use the full version
> <paulfremantle> and <enableRM/> is an alias for
> <policy><wsrmp:RMAssertion/></policy>
> * Retrieving #apache-synapse modes...
> <paulfremantle> so in either <endpoint> or <proxy> you could have
> <paulfremantle> <policy> any ws policy at all </policy>
> <paulfremantle> <endpoint><enableRM/><enableWSS/></endpoint>
> * ant has quit IRC (Read error: 110 (Connection timed out))
> * ant has joined #apache-synapse
> <asankha> yes.. i guess the common case is that usually WS-sec for each
> Proxy/Endpoint would be different.. and how we would specify those
> security properties
> <paulfremantle> then in that case you'd have to use the full policy
> <ant> sorry, NW problems so I'd dropped out again. carry on though i'll
> catch up when the log is posted
> <paulfremantle> if you come on again we'll have 3 ants
> <paulfremantle> which is nearly a colony
> <ant> LOL
> <paulfremantle> asankha do you think that will work
> <ant> i've an off topic question if you've finished with WS-* things
> <asankha> yes.. i guess it will..
> <paulfremantle> go ahead ant
> <asankha> but i dont think we can specify things like the keystore and
> identity etc to be used for a sec operation through policy.. or can we?
> <ant> the mediator interface now has a getType method. I wondered if
> that was really necessary or could be put somewhere else?
> <paulfremantle> yes im not sure we need that
> <paulfremantle> on the mediator
> <paulfremantle> maybe on the mediatorfactory?
> <asankha> ant.. thats a good question.. let me explain why i need it
> <asankha> actually paul we have it on the mediator factory
> <asankha> the mediator factory now returns the XML schema for its mediator
> <asankha> so the schema fragment usually defines a complex type like
> <mediator>_type
> <asankha> and we need to include this type as a valid choice for the
> mediator_type complex type which is defined as follows
> <asankha> <xs:complexType name="mediator_type">
> <asankha>         <xs:sequence maxOccurs="unbounded">
> <asankha>             <xs:choice>
> <asankha>                 <xs:element name="send" type="synapse:send_type"/>
> <asankha>                 <xs:element name="drop" type="synapse:drop_type"/>
> <asankha> ....
> <asankha> <xs:element name="in" type="synapse:in_type"/>
> <asankha>                 <xs:element name="out" type="synapse:out_type"/>
> <asankha>             </xs:choice>
> <asankha>         </xs:sequence>
> <asankha>     </xs:complexType>
> <asankha> so that the schema would be valid and complete
> <paulfremantle> couldn't we just do an <xs:any> at that point
> <asankha> but the problem is.. the "mediator_type" complex type is
> defined programmatically looking at the available extensions
> <paulfremantle> to handle the extension
> <asankha> well.. thats what i wanted to do first..
> <asankha> but this way you wont be able to validate them
> <paulfremantle> true
> <asankha> you cannot define a choice with <xs:anyType>
> <ant> what do you mean "the mediator factory now returns the XML
> schema", which class/method are you talking about so i can go look?
> <asankha> the other option is to always expect the complex type name to
> be "<mediator>_type"
> <asankha> and thats what we do for the core mediators... if you extend
> from the Abstract
> <paulfremantle> asankha I'm still not clear how we can validate if
> someone has plugged in their own extension
> <hzbarcea> you can if xs:any if from namespace="##other"
> <asankha> shall i post the draft synapse.xsd i have and a sample XML to
> the mailing list.. and we could all try it out, suggest and decide?
> <paulfremantle> great
> <hzbarcea> i have a quick q
> <hzbarcea> are there any tools for synapse or any plans for tools?
> <hzbarcea> gui and/or other stuff
> <asankha> i just posted a quick copy of a generated schema..
> http://wiki.apache.org/incubator/Synapse/InProgress/Synapse_XSD
> <paulfremantle> not yet Hadrian
> <paulfremantle> we would like to get the base stable first
> <asankha> for example.. look at this
> <asankha> <xs:complexType name="spring_type">
> <asankha> <xs:attribute name="bean" type="xs:string" use="required"/>
> <asankha> <xs:attribute name="config" type="xs:string"/>
> <asankha> <xs:attribute name="src" type="xs:string"/>
> <asankha> </xs:complexType>
> <asankha> we also have spring_type as a possible choice in the
> mediator_type (as I said before)
> <paulfremantle> the problem is that this isn't extensible
> <asankha> so now you can validate a config with the spring mediator
> <paulfremantle> if I write a paul.jar that adds support for the paul
> mediator <paul src="http://fremantle.org/paul.xml"/>
> <paulfremantle> then how can we validate?
> <asankha> your PaulMediatorFactory should expose something like follows...
> <asankha> a method public XmlSchema getTagSchema(); which exposes your
> schema "fragment"
> <asankha> something like whats below..
> <asankha> <xs:complexType name="spring_type">
> <asankha> <xs:attribute name="bean" type="xs:string" use="required"/>
> <asankha> <xs:attribute name="config" type="xs:string"/>
> <asankha> <xs:attribute name="src" type="xs:string"/>
> <asankha> </xs:complexType>
> <paulfremantle> ok
> <paulfremantle> and then?
> <asankha> and then the public QName getTagSchemaType() should state the
> complex type name that defines your mediator in the above schema
> <paulfremantle> but we cannot use "pure XSD" validation
> <asankha> i.e. "spring_type" for above
> <paulfremantle> outside of Synapse
> <asankha> you mean on the paul.jar file?
> <paulfremantle> i mean that if I have the schema plus a validator tool
> <paulfremantle> I can't just run it
> <paulfremantle> Synapse can because synapse could extract all the schema
> fragments and validate the whole
> <paulfremantle> but a standard XSDValidator couldnt'
> <asankha> well.. yes..
> <asankha> we actually have the mediator_type and property_type common
> types in a common place
> <paulfremantle> maybe we should build an option into Synapse.bat to
> validate the config
> <asankha> but we could ship the synapse.xsd for the core mediators
> <asankha> and anyone could import it and use it
> <asankha> we can do that.. that brings me to the second problem i
> encountered :-)
> <asankha> XmlSchema uses Xalan underneath...
> <asankha> which we do not ship by default with the synapse core release!
> <asankha> so right now i have it generate the schema's only if Xalan and
> its dependencies (Xerces) are available.. and issue a WARN if not
> <asankha> since it will still enable you to run Synapse without a problem
> <asankha> but if the dependenceis are met.. it will work fine and also
> be able to validate
> <asankha> I guess thats the best for right now is it Paul? or do we
> begin to get Xalan into our code dependencies set?
> <paulfremantle> hmmmm
> <paulfremantle> its a shame
> <paulfremantle> maybe we should ask the xmlschema guys if theyu can do
> without it
> <asankha> well.. interestingly thats one of the main objectives of the
> XmlSchema according to the web page...
> * ant_ has quit IRC (Read error: 113 (No route to host))
> <asankha> but i guess they need to reuse as opposed to reinvent the wheel
> <asankha> :-(
> <paulfremantle> mmm
> <asankha> lets look at this during the coming week and decide next week
> how we want to progress?
> <paulfremantle> yes
> <paulfremantle> i have to go as well
> <asankha> yes.. i think we had a good discussion today ..
> <paulfremantle> i need to look through the schema stuff
> <paulfremantle> yes thanks
> <paulfremantle> +1
> <asankha> hopefully Ant will catch it up too..
> <asankha> ok.. see you all later.. i will post this to the mailing list
> <ant> yes. I've only just sync SVN now and seen all the schema stuff...
> <ant> Paul, we've a Tuscany chat at 5pm if you wantt o come along
> <paulfremantle> cool
> <paulfremantle> i will if i can
> <ant> (and anyone else if you're interested)
> <paulfremantle> :-)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>


-- 
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org