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