synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: A few changes proposed for the Synapse Configuration Language
Date Wed, 19 Jul 2006 05:48:33 GMT
On Tue, 2006-07-18 at 17:04 +0530, Asankha C. Perera wrote:
> Paul
> 
> See my comments below
> 
> > 1. <proxy>
> >
> > a) We need to be able to specify more than one transport - e.g.
> > transports="jms,http".
> Yes, this is possible.. and default is to enable on all available 
> transports (as Axis2) , else you could specify multiple transports 
> separated by commas or spaces

Please don't do both - the proper XML way is to use spaces so that the
schema can be defined properly.

> > c) the fact that the properties are really configuring an Axis2
> > endpoint is a little confusing. If we look at it from a general WS-*
> > viewpoint an exposed endpoint has no  "properties". I'd like to remove
> > or rename this. I couldn't think of a usecase.
> This was introduced by me to support the following use case.. when a 
> service is exposed on JMS, we need to be able to specify a custom 
> destination on which it will listen for messages, and a connection 
> factory. The new JMS implementation uses these even when used in a pure 
> Axis2 environment to configure itself properly
> 
> e.g.
>         <parameter name="transport.jms.ConnectionFactory" 
> locked="true">myTopicConnectionFactory</parameter>
>         <parameter name="transport.jms.Destination" 
> locked="true">dynamicTopics/something.TestTopic</parameter>
> 
> > 2. <endpoint>
> > I'm assuming that the policy tags here will be applied "actively". It
> > would be nice to be able to import a policy: e.g.
> >
> > <endpoint address="http://fremantle.org/service1">
> >   <policy src="http://fremantle.org/service1?policy">
> > </endpoint>
> >
> > I would really like some consistency between the use of policy on the
> > <proxy> and <endpoint>.
> Not very clear what you mean as "actively"... right now the policy is 
> for RM only.. and Rampart uses a Parameter named "OutflowSecurity"

I thought Ruchith was going to change Rampart to use the sec policy
stuff instead of using a parameter. In fact the same can be done for the
JMS stuff .. basically with policy being burnt into Axis2, there's we
could even completely get rid of the parameter concept. Anyway that's an
Axis2 discussion.

> > 3. I understand that xslt and xquery are both examples of a
> > "transform", but I prefer the syntax:
> >
> > <xslt source="" stylesheet=" "/>
> I'm ok to changing this ... and can do it quickly as we don't yet have XQ

+1. I suggest we don't put <xquery ..> right now - let someone put that
in when we decide which xquery impl to do it with. No need to pretend we
have function that we don't have!

> > 4. I like the filter. There is something missing tho, which is that we
> > used to have two options: one was to find part of the message and
> > apply a regex, the other was to evaluate an xpath expression that
> > resolved to true/false. I'm not sure we can still do the latter. Seems
> > to me we need two clearly formulated options - XPath Source points to
> > string - then regex. XPath expression evaluates to true/false.
> You are correct.. but I'm not sure whether you are referring to the 
> 'current' syntax, or the syntax I proposed a few days back... since we 
> don't seem to be going ahead with a revision to the schema language, 
> what we have 'currently' does exactly what you mention. i.e. it has the 
> two options that you mention.

OK let me make sure I understand correctly:

- filter has a "source" property saying what item to filter (xpath or
regex) on
- default value of that is the /s:Envelope (separately I'd like to
propose a model where that supports SOAP 1.1 and 1.2 both
simultaneously)
- in addition, there is EITHER:
	- regex: meaning match the regex aganst the text value of whatever
"source"gives .. so clearly if you use regex you must use @source to
point to something interesting .. s:Envelope has no text value
	- xpath: a boolean valued xpath which is executed with an xpath context
set to whatever node the source property points to

Is that correct?

Sanjiva.


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


Mime
View raw message