Axiom bug?
Hello,
I'm trying to use Sandesha with Rampart and I think I've found a bug.
When the server is replying to a CreateSequence message, it gets to
RampartSender,
which calls org.apache.rampart.MessageBuilder.build(MessageContext msgCtx),
which verifies that the security header is empty and tries to remove it:
if ( secHeader != null secHeader.isEmpty(doc) ) {
secHeader.removeSecurityHeader(doc);
}
WSSecHeader.removeSecurityHeader(Document doc) does this:
...
Node parent = securityHeader.getParentNode();
parent.removeChild(securityHeader);
Parent:
soapenv:Header
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wsa=http://www.w3.org/2005/08/addressing;
wsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
soapenv:mustUnderstand=1 /
wsa:Tohttp://192.168.1.5:6060/axis2/services/personaldataserv...@286914895//wsa:To
wsa:ReplyTowsa:Addresshttp://www.w3.org/2005/08/addressing/none/wsa:Address/wsa:ReplyTo
wsa:MessageIDurn:uuid:E3FC5985317BCF16351233758322948/wsa:MessageID
wsa:Actionhttp://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse/wsa:Action
wsa:RelatesTourn:uuid:A07FCCC1972C7E06671233758319824/wsa:RelatesTo
/soapenv:Header
securityHeader:
wsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:mustUnderstand=1 /
Then, org.apache.axiom.om.impl.dom.ParentNode.removeChild(Node) is
called and it gets to this, begining with line 482:
if (this.firstChild == tempNode) {
// If this is the first child
this.firstChild = null;
this.lastChild = null;
tempNode.parentNode = null;
}
tempNode is the security header and it is equal to the firstChild of
the envelope header.
The firstChild is removed... then the lastChild(which is the relatesTo
child) is removed...
The resulting envelope header is this:
soapenv:Header
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wsa=http://www.w3.org/2005/08/addressing; /
I'm using Axis-1.4.1, Addressing-1.41, Sandesha2-1.3, Rampart-1.4, Axiom 1.2.8
I've looked in the Axiom sources and it seems this code is from before
revision 389047 (Moving doom into ws-commons axiom from axis2)
I think this is a bug...
Am I right? Should I create an issue?
Re: Axiom bug?
Andrei,
What is the Axiom version you are using? If it is not 1.2.8 or a
recent snapshot, please check against version 1.2.8. If you can
confirm that the issue still exists in that version, please open a
JIRA issue in the WSCOMMONS project.
Regards,
Andreas
On Wed, Feb 4, 2009 at 16:08, Andrei Ivanov andrei.iva...@gmail.com wrote:
Hello,
I'm trying to use Sandesha with Rampart and I think I've found a bug.
When the server is replying to a CreateSequence message, it gets to
RampartSender,
which calls org.apache.rampart.MessageBuilder.build(MessageContext msgCtx),
which verifies that the security header is empty and tries to remove it:
if ( secHeader != null secHeader.isEmpty(doc) ) {
secHeader.removeSecurityHeader(doc);
}
WSSecHeader.removeSecurityHeader(Document doc) does this:
...
Node parent = securityHeader.getParentNode();
parent.removeChild(securityHeader);
Parent:
soapenv:Header
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wsa=http://www.w3.org/2005/08/addressing;
wsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
soapenv:mustUnderstand=1 /
wsa:Tohttp://192.168.1.5:6060/axis2/services/personaldataserv...@286914895//wsa:To
wsa:ReplyTowsa:Addresshttp://www.w3.org/2005/08/addressing/none/wsa:Address/wsa:ReplyTo
wsa:MessageIDurn:uuid:E3FC5985317BCF16351233758322948/wsa:MessageID
wsa:Actionhttp://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse/wsa:Action
wsa:RelatesTourn:uuid:A07FCCC1972C7E06671233758319824/wsa:RelatesTo
/soapenv:Header
securityHeader:
wsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:mustUnderstand=1 /
Then, org.apache.axiom.om.impl.dom.ParentNode.removeChild(Node) is
called and it gets to this, begining with line 482:
if (this.firstChild == tempNode) {
// If this is the first child
this.firstChild = null;
this.lastChild = null;
tempNode.parentNode = null;
}
tempNode is the security header and it is equal to the firstChild of
the envelope header.
The firstChild is removed... then the lastChild(which is the relatesTo
child) is removed...
The resulting envelope header is this:
soapenv:Header
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wsa=http://www.w3.org/2005/08/addressing; /
I'm using Axis-1.4.1, Addressing-1.41, Sandesha2-1.3, Rampart-1.4, Axiom 1.2.8
I've looked in the Axiom sources and it seems this code is from before
revision 389047 (Moving doom into ws-commons axiom from axis2)
I think this is a bug...
Am I right? Should I create an issue?
Re: Axiom bug?
On Wed, Feb 4, 2009 at 5:41 PM, Andreas Veithen
andreas.veit...@gmail.com wrote:
Andrei,
What is the Axiom version you are using? If it is not 1.2.8 or a
recent snapshot, please check against version 1.2.8. If you can
confirm that the issue still exists in that version, please open a
JIRA issue in the WSCOMMONS project.
1.2.8... it say right at the end of my email...
I'll open an issue...
Thanks
Regards,
Andreas
On Wed, Feb 4, 2009 at 16:08, Andrei Ivanov andrei.iva...@gmail.com wrote:
Hello,
I'm trying to use Sandesha with Rampart and I think I've found a bug.
When the server is replying to a CreateSequence message, it gets to
RampartSender,
which calls org.apache.rampart.MessageBuilder.build(MessageContext msgCtx),
which verifies that the security header is empty and tries to remove it:
if ( secHeader != null secHeader.isEmpty(doc) ) {
secHeader.removeSecurityHeader(doc);
}
WSSecHeader.removeSecurityHeader(Document doc) does this:
...
Node parent = securityHeader.getParentNode();
parent.removeChild(securityHeader);
Parent:
soapenv:Header
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wsa=http://www.w3.org/2005/08/addressing;
wsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
soapenv:mustUnderstand=1 /
wsa:Tohttp://192.168.1.5:6060/axis2/services/personaldataserv...@286914895//wsa:To
wsa:ReplyTowsa:Addresshttp://www.w3.org/2005/08/addressing/none/wsa:Address/wsa:ReplyTo
wsa:MessageIDurn:uuid:E3FC5985317BCF16351233758322948/wsa:MessageID
wsa:Actionhttp://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse/wsa:Action
wsa:RelatesTourn:uuid:A07FCCC1972C7E06671233758319824/wsa:RelatesTo
/soapenv:Header
securityHeader:
wsse:Security
xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd;
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:mustUnderstand=1 /
Then, org.apache.axiom.om.impl.dom.ParentNode.removeChild(Node) is
called and it gets to this, begining with line 482:
if (this.firstChild == tempNode) {
// If this is the first child
this.firstChild = null;
this.lastChild = null;
tempNode.parentNode = null;
}
tempNode is the security header and it is equal to the firstChild of
the envelope header.
The firstChild is removed... then the lastChild(which is the relatesTo
child) is removed...
The resulting envelope header is this:
soapenv:Header
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wsa=http://www.w3.org/2005/08/addressing; /
I'm using Axis-1.4.1, Addressing-1.41, Sandesha2-1.3, Rampart-1.4, Axiom
1.2.8
I've looked in the Axiom sources and it seems this code is from before
revision 389047 (Moving doom into ws-commons axiom from axis2)
I think this is a bug...
Am I right? Should I create an issue?
Re: AXIOM bug or feature
I guess this is a bug. No question about it. But . Axiom is an XML object model designed to be high performant. We can do hundreds of checks like this to make sure its integrity, conformance, etc., IMHO, there is a part from the users side also to make things work, if he needs performance. We didn't design Axiom to be bullet-proof. We sometimes purposely avoided checks like this. You can easily avoid this error by setting the attr to instead of setting to null. I am not defending Axiom team or anything, it is just that these sorts of things can be avoided. If it is that there is a problem in Axiom not serializing some info, then I'd have fixed it. But these sorts of errors, I personally don't think we should put as high priority, IMHO. On Tue, Jul 22, 2008 at 6:54 AM, Pierre Muller [EMAIL PROTECTED] wrote: Hello, There seems to be a minor bug - or perhaps feature - in AXIOM : One may set the attribute of an OMElement to null without having any error. But this OMElement can't be returned (as an operation response) nor be converted to String (e.g for display purpose) : a java.lang.NullPointerException is thrown at this time. Why doesn't the null attribute value get converted to an empty string, or why doesn't the attribute simply get discarded ? Thanks, Pierre Muller *Example trace when trying to display an OMElement with a null attribute : Exception in thread main java.lang.NullPointerException at com.ctc.wstx.sw.BaseNsStreamWriter.doWriteAttr(BaseNsStreamWriter.java:468) at com.ctc.wstx.sw.BaseNsStreamWriter.writeAttribute(BaseNsStreamWriter.java:230) at org.apache.axiom.om.impl.MTOMXMLStreamWriter.writeAttribute(MTOMXMLStreamWriter.java:178) at org.apache.axiom.om.impl.util.OMSerializerUtil.serializeStartpart(OMSerializerUtil.java:443) at org.apache.axiom.om.impl.util.OMSerializerUtil.serializeStartpart(OMSerializerUtil.java:197) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:901) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:889) at org.apache.axiom.om.impl.llom.OMNodeImpl.serialize(OMNodeImpl.java:375) at org.apache.axiom.om.impl.llom.OMElementImpl.toString(OMElementImpl.java:1051) * ** Si vous n'êtes pas le destinataire désigné de ce message ou une personne autorisée à l'utiliser, toute distribution, copie, publication ou usage à quelques fins que ce soit des informations dans ce message sont interdits. Merci d'informer immédiatement l'expéditeur par messagerie, et, de détruire ce message. This e-mail is confidential. If you are not the addressee or an authorized recipient of this message, any distribution, copying, publication or use of this information for any purpose is prohibited. Please notify the sender immediately by e-mail and then delete this message. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- With Mettha, Eran Chinthaka Health is the greatest gift; contentment is the greatest wealth; trusting is the best relationship; nirvana is the highest joy. - Dhammapada
AXIOM bug or feature
Hello, There seems to be a minor bug - or perhaps feature - in AXIOM : One may set the attribute of an OMElement to "null" without having any error. But this OMElement can't be returned (as an operation response) nor be converted to String (e.g for display purpose) : a "java.lang.NullPointerException" is thrown at this time. Why doesn't the null attribute value get converted to an empty string, or why doesn't the attribute simply get discarded ? Thanks, Pierre Muller Example trace when trying to display an OMElement with a null attribute : Exception in thread "main" java.lang.NullPointerException at com.ctc.wstx.sw.BaseNsStreamWriter.doWriteAttr(BaseNsStreamWriter.java:468) at com.ctc.wstx.sw.BaseNsStreamWriter.writeAttribute(BaseNsStreamWriter.java:230) at org.apache.axiom.om.impl.MTOMXMLStreamWriter.writeAttribute(MTOMXMLStreamWriter.java:178) at org.apache.axiom.om.impl.util.OMSerializerUtil.serializeStartpart(OMSerializerUtil.java:443) at org.apache.axiom.om.impl.util.OMSerializerUtil.serializeStartpart(OMSerializerUtil.java:197) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:901) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:889) at org.apache.axiom.om.impl.llom.OMNodeImpl.serialize(OMNodeImpl.java:375) at org.apache.axiom.om.impl.llom.OMElementImpl.toString(OMElementImpl.java:1051) ** Si vous n'êtes pas le destinataire désigné de ce message ou une personne autorisée à l'utiliser, toute distribution, copie, publication ou usage à quelques fins que ce soit des informations dans ce message sont interdits. Merci d'informer immédiatement l'expéditeur par messagerie, et, de détruire ce message. This e-mail is confidential. If you are not the addressee or an authorized recipient of this message, any distribution, copying, publication or use of this information for any purpose is prohibited. Please notify the sender immediately by e-mail and then delete this message. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible Axiom Bug: base64 encoding
Hi Carlos,
Thanks for digging in to the problem. Can you please create a patch and
attach it to a JIRA (http://issues.apache.org/jira/browse/AXIS2)?
-- Chinthaka
Carlos Perez wrote:
Hi,
I have been trying to consume an Axis2 web service that returns binary
data in base64 from a .NET client, and the client is complaining about
invalid characters in the base64 string. I took a look at the string and
actually the base64 string is including '=' chars in the middle of the
string, but this char is only allowed at the end of the string, for
padding. So I took a look at the code for the class
org.apache.axiom.om.impl.llom.OMTextImpl and there seems to be a bug in
the base64 encoding process, in the method getText(). This method is
encoding chunks of 1024 bytes at a time; base64 encodes 3 bytes at a
time, and as 1024 is not a multiple of 3 then a pad of two '=' chars is
generated for every chunk. I think that with a chunk size that is
multiple of 3 (i.e. 1023), this problem could be solved.
public String getText() throws OMException {
...
InputStream inStream;
inStream = this.getInputStream();
byte[] data;
StringBuffer text = new StringBuffer();
do {
data = new byte[1024];
int len;
while ((len = inStream.read(data)) 0) {
byte[] temp = new byte[len];
System.arraycopy(data, 0, temp, 0, len);
text.append(Base64.encode(temp));
}
} while (inStream.available() 0);
...
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
Possible Axiom Bug: base64 encoding
Hi,
I have been trying to consume an Axis2 web service that
returns binary data in base64 from a .NET client, and the
client is complaining about invalid characters in the
base64 string. I took a look at the string and actually
the base64 string is including '=' chars in the middle of
the string, but this char is only allowed at the end of
the string, for padding. So I took a look at the code for
the class org.apache.axiom.om.impl.llom.OMTextImpl and
there seems to be a bug in the base64 encoding process, in
the method getText(). This method is encoding chunks of
1024 bytes at a time; base64 encodes 3 bytes at a time,
and as 1024 is not a multiple of 3 then a pad of two '='
chars is generated for every chunk. I think that with a
chunk size that is multiple of 3 (i.e. 1023), this
problem could be solved.
public String getText() throws OMException {
...
InputStream inStream;
inStream = this.getInputStream();
byte[] data;
StringBuffer text = new StringBuffer();
do {
data = new byte[1024];
int len;
while ((len = inStream.read(data))
0) {
byte[] temp = new byte[len];
System.arraycopy(data, 0, temp,
0, len);
text.append(Base64.encode(temp));
}
} while (inStream.available() 0);
...
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
