You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Dasarath Weeratunge <da...@yahoo.com> on 2004/06/18 19:17:50 UTC
ws-addressing // !!! We shouldn't be removing these headers here.
AddressingHeaders
// !!! We shouldn't be removing these headers
here. The only
// reason to remove them is for use as an
intermediary, and
// that should work via the
infrastructure, NOT by removing
// headers here. Removing them here just
means other handlers
// which run after this one don't see the
whole message, which
// is bad. Change awaiting discussion on
fx-dev. --Glen
// must have found one
if (remove) {
headerElement.detachNode();
}
Hi,
Please correct me if I'm wrong but it seems that the
WSAddressingHandler removes all header elements even
when the
reference properties are clearly identified in the
<parameter name="referencePropertyNames" ...>.
As a result, WSAtomicTransactionHandler in the ws-at
impl that I'm working on was not able to see the
coordination
context.
I think we can get the handler to process the non-wsa
elements but only those that are enumerated under
"referencePropertyNames" by allowing the
processReferenceProperty method to return a boolean.
Thanks
Dasarath
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Re: Re: ws-addressing // !!! We shouldn't be removing these headers here.
Posted by Dasarath Weeratunge <da...@yahoo.com>.
--- Davanum Srinivas <da...@gmail.com> wrote:
> please submit a patch to JIRA.
>
> thanks,
> dims
>
====================================================
--- AddressingHeaders-old.java 2004-06-19
18:44:09.000000000 +0600
+++ AddressingHeaders.java 2004-06-19
18:48:32.000000000 +0600
@@ -201,8 +201,9 @@
} else if
(localName.equals(Constants.RELATES_TO)) {
relatesTo.add(new
RelatesTo(headerElement));
} else {
- // its a reference property
- processReferenceProperty(headerElement,
refPropsQNames);
+ // it could be a reference property
+ if (!processReferenceProperty(headerElement,
refPropsQNames))
+ continue;
}
// !!! We shouldn't be removing these
headers here. The only
@@ -509,7 +510,7 @@
* @param headerElement
* @throws Exception
*/
- private void
processReferenceProperty(SOAPHeaderElement
headerElement,
+ private boolean
processReferenceProperty(SOAPHeaderElement
headerElement,
List
refPropQNames)
throws Exception {
Name name = headerElement.getElementName();
@@ -518,9 +519,14 @@
// if we got to this point, the user wants
deserialization of ref props.
// if refPropQNames was a null, it is treated
as a '*' or process all headers
// otherwise we check to see if the element
name was specified by the user
+
if ((refPropQNames == null) ||
(refPropQNames.contains(elementName))) {
referenceProperties.add(headerElement);
+ return true;
}
+
+ // we didn't process the header so return
false
+ return false;
}
/**
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Re: ws-addressing // !!! We shouldn't be removing these headers here.
Posted by Davanum Srinivas <da...@gmail.com>.
please submit a patch to JIRA.
thanks,
dims
On Fri, 18 Jun 2004 10:17:50 -0700 (PDT), Dasarath Weeratunge
<da...@yahoo.com> wrote:
>
> AddressingHeaders
>
> // !!! We shouldn't be removing these headers
> here. The only
> // reason to remove them is for use as an
> intermediary, and
> // that should work via the
> infrastructure, NOT by removing
> // headers here. Removing them here just
> means other handlers
> // which run after this one don't see the
> whole message, which
> // is bad. Change awaiting discussion on
> fx-dev. --Glen
>
> // must have found one
> if (remove) {
> headerElement.detachNode();
> }
>
> Hi,
>
> Please correct me if I'm wrong but it seems that the
> WSAddressingHandler removes all header elements even
> when the
>
> reference properties are clearly identified in the
> <parameter name="referencePropertyNames" ...>.
> As a result, WSAtomicTransactionHandler in the ws-at
> impl that I'm working on was not able to see the
> coordination
>
> context.
>
> I think we can get the handler to process the non-wsa
> elements but only those that are enumerated under
>
> "referencePropertyNames" by allowing the
> processReferenceProperty method to return a boolean.
>
> Thanks
>
> Dasarath
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: ws-addressing // !!! We shouldn't be removing these headers here.
Posted by Jarek Gawor <ga...@mcs.anl.gov>.
That should be fixed now along with another problem I found in the code.
Also, the ignoreNonWSAHeader parameter is not needed anymore. Just pass the
refProperties list as null (for all non-wsa headers), empty (to ignore all
non-wsa headers - default), or non empty with some qnames for specific
headers. During testing I think I also ran into some Axis-specific issues
which need to be investigated more.
Jarek
> -----Original Message-----
> From: Davanum Srinivas [mailto:davanum@gmail.com]
> Sent: Friday, June 18, 2004 6:52 PM
> To: Dasarath Weeratunge; Jarek Gawor
> Cc: fx-dev@ws.apache.org
> Subject: Re: ws-addressing // !!! We shouldn't be removing
> these headers here.
>
>
> Jarek,
>
> Can you please review this?
>
> thanks,
> dims
>
> On Fri, 18 Jun 2004 10:17:50 -0700 (PDT), Dasarath Weeratunge
> <da...@yahoo.com> wrote:
> >
> > AddressingHeaders
> >
> > // !!! We shouldn't be removing these headers
> > here. The only
> > // reason to remove them is for use as an intermediary,
> > and
> > // that should work via the
> > infrastructure, NOT by removing
> > // headers here. Removing them here just
> > means other handlers
> > // which run after this one don't see the
> > whole message, which
> > // is bad. Change awaiting discussion on
> > fx-dev. --Glen
> >
> > // must have found one
> > if (remove) {
> > headerElement.detachNode();
> > }
> >
> > Hi,
> >
> > Please correct me if I'm wrong but it seems that the
> > WSAddressingHandler removes all header elements even when the
> >
> > reference properties are clearly identified in the
> > <parameter name="referencePropertyNames" ...>.
> > As a result, WSAtomicTransactionHandler in the ws-at
> > impl that I'm working on was not able to see the
> > coordination
> >
> > context.
> >
> > I think we can get the handler to process the non-wsa elements but
> > only those that are enumerated under
> >
> > "referencePropertyNames" by allowing the processReferenceProperty
> > method to return a boolean.
> >
> > Thanks
> >
> > Dasarath
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - 100MB free storage!
> > http://promotions.yahoo.com/new_mail
> >
>
>
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
Re: ws-addressing // !!! We shouldn't be removing these headers here.
Posted by Davanum Srinivas <da...@gmail.com>.
Jarek,
Can you please review this?
thanks,
dims
On Fri, 18 Jun 2004 10:17:50 -0700 (PDT), Dasarath Weeratunge
<da...@yahoo.com> wrote:
>
> AddressingHeaders
>
> // !!! We shouldn't be removing these headers
> here. The only
> // reason to remove them is for use as an
> intermediary, and
> // that should work via the
> infrastructure, NOT by removing
> // headers here. Removing them here just
> means other handlers
> // which run after this one don't see the
> whole message, which
> // is bad. Change awaiting discussion on
> fx-dev. --Glen
>
> // must have found one
> if (remove) {
> headerElement.detachNode();
> }
>
> Hi,
>
> Please correct me if I'm wrong but it seems that the
> WSAddressingHandler removes all header elements even
> when the
>
> reference properties are clearly identified in the
> <parameter name="referencePropertyNames" ...>.
> As a result, WSAtomicTransactionHandler in the ws-at
> impl that I'm working on was not able to see the
> coordination
>
> context.
>
> I think we can get the handler to process the non-wsa
> elements but only those that are enumerated under
>
> "referencePropertyNames" by allowing the
> processReferenceProperty method to return a boolean.
>
> Thanks
>
> Dasarath
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/