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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
