synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SYNAPSE-235) Allow XPath expressions to be specified relative to envelope or body via an attribute
Date Thu, 13 Mar 2008 21:52:24 GMT

    [ https://issues.apache.org/jira/browse/SYNAPSE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578506#action_12578506
] 

Andreas Veithen commented on SYNAPSE-235:
-----------------------------------------

Some more comments and suggestions:

1) SynapseXPath extends AXIOMXPath. I would prefer composition instead of inheritance here.
Indeed, given the way we extend the functionality of AXIOMXPath, there is no longer an "is
a" relation between SynapseXPath and AXIOMPath. Not having SynapseXPath extending AXIOMXPath
directly would give us more control over how SynapseXPath objects are used. For example this
would have prevented the problem I pointed out in my previous comment. Another example: for
the moment nothing prevents the code from calling setVariableContext on a SynapseXPath object,
but this would lead to unexpected results.

I'm aware that this requires additional changes to SynapseXPathFactory and OMElementUtils,
but I think that from a design point of view the effort is worth it.

2) We also need a ThreadSafeDelegatingFunctionContext to make SynapseXPath thread safe.

3) SynapseVariableContext objects are stored in ThreadLocals and at the same time hold references
to MessageContext and/or SOAPEnvelope objects. To avoid memory leaks, we need to release the
reference to SynapseVariableContext after the evaluation. There should be a try-finally block
with a call to ThreadSafeDelegatingFunctionContext #setDelegate(null). Idem for the function
contexts.

4) There are hardcoded namespace prefix-URI mappings in SynapseXPath#evaluate and SynapseVariableContext#getVariableValue.
I really don't like this because it is in contradiction with the fact that normally namespace
prefixes can be chosen arbitrarily. I think we should only specify well defined namespace
URIs and let the user define the prefix-URI mapping in the usual way. The config file would
then look like this:

<definitions xmlns="http://ws.apache.org/ns/synapse" xmlns:t="http://ws.apache.org/ns/synapse/xpath-vars/transport-headers">
  ...
    <... expression="$t:content-type"/>
  ...
</definitions>

This is a bit more complicated, but it is the same approach as in XML Schema and especially
XSLT. Also when reading a config file, somebody not familiar with our implicit XPath variables
(but otherwise experienced with XML) would almost certainly try to find the namespace mapping
to get an idea about where the variable comes for. If he sees something like "http://ws.apache.org/ns/synapse/xpath-vars/transport-headers"
as the URI, this will become clear to him immediately. He can then get rest of the information
from Google...



> Allow XPath expressions to be specified relative to envelope or body via an attribute
> -------------------------------------------------------------------------------------
>
>                 Key: SYNAPSE-235
>                 URL: https://issues.apache.org/jira/browse/SYNAPSE-235
>             Project: Synapse
>          Issue Type: Improvement
>            Reporter: Asankha C. Perera
>            Assignee: Ruwan Linton
>             Fix For: 1.2
>
>
> This would make XPath expressions simpler without consideration for SOAP 1.1 or 1.2 or
REST etc
> Default could be envelope (i.e. what we have now - for backward compatibility), and an
optional attribute could specify if it should be relative to the body

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message