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
By the way - are these names connected to Axis2 pluggable transports
or are they a specific synapse keyword?
They are the same Axis2 names
b) Policy.... as I understand it this is just a pointer to the doc
that the end user will see if they browse ?policy. It would be nice if
this was policy that was actively set on the endpoint and used to
configure the modules.
Yes, this is the service level policy which will apply as you have
mentioned. But we will allow some 'simpler' notation to request the
default QoS module configuration on a proxy service e.g. <enableRM/>
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"
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
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.
thanks
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
