Please don't do both - the proper XML way is to use spaces so that the
schema can be defined properly.
Sure, I will drop the comma
+1
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.
I would MUCH prefer it if we used policy from Synapse into Axis2 to
configure Axis2. Even if the policy statements are Axis2 specific, its
a more general way of doing it and fits nicely with the Synapse design
point.
+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!
Ok.. this will be changed ASAP
Cool
No - filter either has an (@source *and* @regex) OR (@xpath)
Great - thats what I was hoping.... I just got confused.
- 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)
Normally to support the namespace you have to add the xmlns:s
attribute into the filter element, and we then add these to the XPath
processor's namespaces. Maybe we could pre-define soap as a namespace
and unless someone overrides it we can do some clever stuff. i.e. if
the message is SOAP1.1 then soap: refers to the SOAP1.1 namespace and
if the message is SOAP1.2 then it refers to the SOAP1.2 namespace.
If you don't specify a source it should be ok.
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
