You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Rich Scheuerle (JIRA)" <ji...@apache.org> on 2007/11/05 21:39:50 UTC

[jira] Commented: (WSCOMMONS-267) OMSourcedElement SOAPHeaders will always be forceExpand()ed

    [ https://issues.apache.org/jira/browse/WSCOMMONS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540268 ] 

Rich Scheuerle commented on WSCOMMONS-267:
------------------------------------------

Design Proposal:

Add support for generic properties on the OMDataSource interface 
Add specific properties for MUST_UNDERSTAND and ROLE.
Change SOAPHeaderBlock to query that property first.  If the property is not set, then it gets the (attrribute) information the expansion.
This will allow an OMDataSource to communicate header specific information without requiring an expansion.

Side Effect:
Adding properties to OMDataSource would be a useful way to expose/add other capabilities.

--------------
I am going to start working on this issue.  


> OMSourcedElement SOAPHeaders will always be forceExpand()ed
> -----------------------------------------------------------
>
>                 Key: WSCOMMONS-267
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-267
>             Project: WS-Commons
>          Issue Type: Bug
>          Components: AXIOM
>            Reporter: David Illsley
>            Assignee: Rich Scheuerle
>
> Working through trying to use WSCOMMONS-263 I've noticed that the OMSourcedElement SOAPHeader implementation doesn't take account of the special nature of SOAP Headers - namely that they have 'special' attributes e.g mustUnderstand and role that will get searched for regardless of the fact that the header is an OMSourcedElement. Calling getAttribute (which is how these attributes are retrieved under the covers) will cause a forceExpand which will negate the performance improvements intended.

-- 
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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org