[jira] Updated: (WSCOMMONS-529) MANIFEST.MF for axiom-api JAR in 1.2.8 release is missing an Import-Package entry
[ https://issues.apache.org/jira/browse/WSCOMMONS-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated WSCOMMONS-529: -- Component/s: AXIOM MANIFEST.MF for axiom-api JAR in 1.2.8 release is missing an Import-Package entry - Key: WSCOMMONS-529 URL: https://issues.apache.org/jira/browse/WSCOMMONS-529 Project: WS-Commons Issue Type: Bug Components: AXIOM Affects Versions: Axiom 1.2.8 Reporter: Mike Edwards Attachments: axiom-api-1.2.8.MF The MANIFEST.MF file for the axiom-api-1.2.8.jar is missing an Import-Package entry for: org.apache.axiom.soap.impl.llom.soap11 This causes an exception of the following kind when using the axiom-api-1.2.8.jar under OSGi: org.apache.axiom.om.OMException: java.lang.ClassNotFoundException: org.apache.axiom.soap.impl.llom.soap11.SOAP11Factory at org.apache.axiom.om.OMAbstractFactory.getSOAP11Factory(OMAbstractFactory.java:147) ... Adding an Import-Package entry as follows overcomes this problem: org.apache.axiom.soap.impl.llom.soap11;resolution:=optional, ...I note that this matches the Import-Package entry for the equivalent soap12 package, which is already present. -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (WSCOMMONS-509) Axiom changes the namespce prefix only in the namespace declaration
[
https://issues.apache.org/jira/browse/WSCOMMONS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated WSCOMMONS-509:
--
Component/s: AXIOM
Axiom changes the namespce prefix only in the namespace declaration
---
Key: WSCOMMONS-509
URL: https://issues.apache.org/jira/browse/WSCOMMONS-509
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Reporter: Amila Chinthaka Suriarachchi
String xmlString = s:Envelope
xmlns:s=\http://schemas.xmlsoap.org/soap/envelope/\;\n +
s:Body\n +
s:Fault\n +
faultcodes:Client/faultcode\n +
faultstring xml:lang=\en-US\The creator of this
fault did not specify a Reason./faultstring\n +
detail\n +
AppBaseFault i:type=\AppDerivedFault\
xmlns=\http://xwsinterop/soapwsdl/faults\;
xmlns:i=\http://www.w3.org/2001/XMLSchema-instance\;\n +
ErrorInt50/ErrorInt\n +
ErrorStringThis is a test error string for
fault tests./ErrorString\n +
ErrorEmployee\n +
Age30/Age\n +
NameIndigo Developer/Name\n +
HireDate2009-11-17T02:09:48.394-08:00/HireDate\n +
ID12345/ID\n +
Manager\n +
Age50/Age\n +
NameIndigo Developer/Name\n +
HireDate2009-11-17T02:09:48.394-08:00/HireDate\n +
ID34567/ID\n +
Manager i:nil=\true\/\n +
/Manager\n +
/ErrorEmployee\n +
/AppBaseFault\n +
/detail\n +
/s:Fault\n +
/s:Body/s:Envelope;
try {
XMLStreamReader xmlStreamReader =
StAXUtils.createXMLStreamReader(new
ByteArrayInputStream(xmlString.getBytes()));
StAXSOAPModelBuilder builder = new
StAXSOAPModelBuilder(xmlStreamReader);
SOAPEnvelope envelope =
(SOAPEnvelope)builder.getDocumentElement();
XMLStreamReader newReader =
envelope.getBody().getFault().getDetail().getFirstElement().getXMLStreamReaderWithoutCaching();
while (!newReader.isStartElement()){
newReader.next();
}
System.out.println(Element name == + newReader.getName());
System.out.println(type == +
newReader.getAttributeValue(http://www.w3.org/2001/XMLSchema-instance,type;));
System.out.println(Namespace == +
newReader.getNamespaceContext().getNamespaceURI());
System.out.println(Namespace == +
newReader.getNamespaceContext().getNamespaceURI(axis2ns1));
} catch (XMLStreamException e) {
}
This code produce following out put.
lement name == {http://xwsinterop/soapwsdl/faults}AppBaseFault
type == AppDerivedFault
Namespace == null
Namespace == http://xwsinterop/soapwsdl/faults
the namespace prefix has changed to axis2ns1 but type still have the previous
value instead of axis2ns1:AppDerivedFault.
This give an exception at ADB.
--
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-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-203) NPE in DigestGenerator's getExpandedName() methods
[ https://issues.apache.org/jira/browse/AXIOM-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-203: -- Component/s: C14N NPE in DigestGenerator's getExpandedName() methods -- Key: AXIOM-203 URL: https://issues.apache.org/jira/browse/AXIOM-203 Project: Axiom Issue Type: Bug Components: C14N Affects Versions: 1.2.9 Reporter: Myles Bunbury In org.apache.axiom.om.util.DigestGenerator, both getExpandedName(OMElement element) and getExpandedName(OMAttribute attribute) will throw a null pointer exception if getNamespace() returns NULL: return attribute.getNamespace().getNamespaceURI() + : + attribute.getLocalName(); -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-63) OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events
[ https://issues.apache.org/jira/browse/AXIOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-63: - Component/s: API OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events Key: AXIOM-63 URL: https://issues.apache.org/jira/browse/AXIOM-63 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.9 Reporter: Andreas Veithen Priority: Minor Fix For: 1.2.11 The code in OMXMLStreamReaderValidator implicitly makes the assumption that the parser state (event) may only change during calls to next(). This is incorrect, because calls to getElementText() and nextTag() also consume events from the parser. This sometimes causes OMXMLStreamReaderValidator to report mismatched END_ELEMENT events although the sequence of events produced by the parent XMLStreamReader is correct. An example of this can be seen in AXIS2-4854. -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Resolved: (AXIOM-274) Refactor/deprecate MIMEOutputUtils
[ https://issues.apache.org/jira/browse/AXIOM-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-274. --- Resolution: Fixed Refactor/deprecate MIMEOutputUtils -- Key: AXIOM-274 URL: https://issues.apache.org/jira/browse/AXIOM-274 Project: Axiom Issue Type: Task Components: API Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.11 Axiom 1.2.9 introduced a cleaner API for writing MIME messages (see MultipartWriter and OMMultipartWriter), making MIMEOutputUtils obsolete. MIMEOutputUtils should be refactored to use the new API and/or deprecated. This was planned for 1.2.9, but didn't make it into the release. -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-31) Axiom MIME parser does not support MIME parts without content-id's
[ https://issues.apache.org/jira/browse/AXIOM-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-31: - Component/s: API Assignee: Andreas Veithen (was: Thilina Gunarathne) Axiom MIME parser does not support MIME parts without content-id's -- Key: AXIOM-31 URL: https://issues.apache.org/jira/browse/AXIOM-31 Project: Axiom Issue Type: Bug Components: API Reporter: Thilina Gunarathne Assignee: Andreas Veithen Fix For: 1.2.11 Attachments: axiom_mixed_content_patch.txt Axiom MIME parser does the content-id validation for the MIME parts as required by MTOM SwA..Also the Attachments API is designed as a map (content-id, attachment) with this assumption.. But now the mail transport is going to use the same MIME parser and they have valid messages which does not have content-id's for MIME parts. But IMHO trying to generalize all axiom/Axis2 attachment API's would be a too much of an API change at this point of the project... Attached is a quick patch to generate a UUID in place of the missing content-id... But with this we are going to miss the content-id validation... WDYT? -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Created: (AXIOM-350) Clean up the org.apache.axiom.attachments.Part interface
Clean up the org.apache.axiom.attachments.Part interface Key: AXIOM-350 URL: https://issues.apache.org/jira/browse/AXIOM-350 Project: Axiom Issue Type: Task Components: API Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.11 Currently, the Part interface is only used internally by Axiom. This can be seen from the current Javadoc [1] (note that Part is used by PartFactory, which is also only used internally [2]). Therefore the Part interface is not really part of the public API and modifying it would only impact code that uses Part and PartFactory independently from the rest of the Axiom API, which is a highly unlikely case. In order to solve AXIOM-31 and AXIOM-280, it is proposed to expose the Part instances via the Attachments object. This is also necessary to make the SAAJ implementation in Axis2 complete, because SAAJ defines methods to access the headers of a MIME part, and this is not possible with the current Axiom API. Exposing the Part instances via the Attachments object will make the Part interface part of the public API. Before doing this, we should clean up this interface a bit. In particular, we should eliminate its dependency on the JavaMail API (usage of javax.mail.MessagingException by all methods and usage of javax.mail.Header as a return value of getAllHeaders). [1] http://ws.apache.org/axiom/apidocs/org/apache/axiom/attachments/class-use/Part.html [2] http://ws.apache.org/axiom/apidocs/org/apache/axiom/attachments/impl/class-use/PartFactory.html -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Created: (AXIOM-351) Links in Javadoc JARs are broken
Links in Javadoc JARs are broken Key: AXIOM-351 URL: https://issues.apache.org/jira/browse/AXIOM-351 Project: Axiom Issue Type: Bug Affects Versions: 1.2.10 Reporter: Andreas Veithen Priority: Minor Fix For: 1.2.11 For classes in dependency projects, the Javadoc JARs normally have links pointing to the online Javadoc in the Web site of these dependencies. In the Javadoc JARs generated for the different Axiom modules, the links to the Javadoc of classes in other Axiom modules are broken. E.g. the Javadoc of org.apache.axiom.om.impl.llom.OMNodeImpl has a link to http://ws.apache.org/axiom/axiom-api/apidocs/org/apache/axiom/om/OMNode.html while this should be http://ws.apache.org/axiom/apidocs/org/apache/axiom/om/OMNode.html (note the extra 'axiom-api'). This can also be seen in some online Javadoc browser services. Example: http://www.jarvana.com/jarvana/view/org/apache/ws/commons/axiom/axiom-dom/1.2.9/axiom-dom-1.2.9-javadoc.jar!/org/apache/axiom/soap/impl/dom/SOAPHeaderImpl.html In addition, the Project Dependencies report of some downstream projects has incorrect links for individual Axiom modules. An example is Rampart: http://axis.apache.org/axis2/java/rampart/dependencies.html These two issues are presumably caused by the fact that project.url is not set correctly in the POMs of the individual Axiom modules. -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Created: (AXIOM-353) Need a replacement for OMXMLBuilderFactory
Need a replacement for OMXMLBuilderFactory -- Key: AXIOM-353 URL: https://issues.apache.org/jira/browse/AXIOM-353 Project: Axiom Issue Type: Improvement Components: API Reporter: Andreas Veithen Historically, org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory was used to create Axiom trees from XML documents (and there are still places in Axis2 where this is used). Unfortunately, this class is located in the wrong package and JAR (it is implementation independent but belongs to LLOM). Nowadays, the standard way to create an Axiom tree is to instantiate StAXOMBuilder or one of its subclasses directly. However, this is not optimal because it implies the assumption that every implementation of the Axiom API necessarily uses StAXOMBuilder. This means that an implementation doesn't have the freedom to provide its own builder implementation (e.g. in order to implement some special optimizations). There should be an abstract API for this. OMMetaFactory is a good candidate because it is already used to encapsulate an implementation of the Axiom API (there is one implementation of OMMetaFactory for LLOM and one for DDOM). -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-353) Need a replacement for OMXMLBuilderFactory
[ https://issues.apache.org/jira/browse/AXIOM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-353: -- Fix Version/s: 1.2.11 Assignee: Andreas Veithen Need a replacement for OMXMLBuilderFactory -- Key: AXIOM-353 URL: https://issues.apache.org/jira/browse/AXIOM-353 Project: Axiom Issue Type: Improvement Components: API Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.11 Historically, org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory was used to create Axiom trees from XML documents (and there are still places in Axis2 where this is used). Unfortunately, this class is located in the wrong package and JAR (it is implementation independent but belongs to LLOM). Nowadays, the standard way to create an Axiom tree is to instantiate StAXOMBuilder or one of its subclasses directly. However, this is not optimal for two reasons: * It implies the assumption that every implementation of the Axiom API necessarily uses StAXOMBuilder. This means that an implementation doesn't have the freedom to provide its own builder implementation (e.g. in order to implement some special optimizations). * StAXOMBuilder belongs to a package which has impl in its name. This tends to blur the distinction between the public API and internal implementation classes. There should be an abstract API for creating builder instances. It should be defined in terms of interfaces (such as OMXMLParserWrapper). OMMetaFactory is a good candidate for this because it is already used to encapsulate an implementation of the Axiom API (there is one implementation of OMMetaFactory for LLOM and one for DOOM). -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Commented: (WSS-257) Avoid converting the SOAP Body to DOM on the processing side if possible
[
https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966141#action_12966141
]
Andreas Veithen commented on WSS-257:
-
I think that the signature of the second method should be changed to something
like this:
InputStream getAttachment(Object msgContext, Node node)
Rationale: In DOM/SAAJ, the optimized base64 data is represented as an Element
(with name xop:Include), while Axiom represents it as an OMText node (referring
to a DataHandler instead of a String). With the modified signature we should be
able to support both models.
Avoid converting the SOAP Body to DOM on the processing side if possible
Key: WSS-257
URL: https://issues.apache.org/jira/browse/WSS-257
Project: WSS4J
Issue Type: Improvement
Affects Versions: 1.5.10
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.6
On an inbound request, WSS4J currently iterates through each security token
in the security header and processes each one. However it also requires the
entire SOAP request be converted into a DOM structure, even though it might
not be necessary to access the SOAP body as part of processing the security
header, e.g. processing a Timestamp, or a Username Token.
This task is to enhance WSS4J on the processing side, so that it does not
require access to the SOAP body. If it needs to find an element in the SOAP
request, it should use a callback mechanism, to obtain e.g. the SOAP body if
required. This mechanism could potentially provide support for signed MTOM.
WSS4J should supply a default implementation that more or less parallels the
current implementation. CXF/Rampart etc. could define their own callback
implementations for their specific needs.
The callback class could look something like:
public abstract class LookupCallbacks {
//for the wsu:ID, get the element
Element getElementForID(Object msgContext, String i) {
return null;
}
//for processing of MTOM things eventually
InputStream getAttachment(Object msgContext, String contentId) {
return null;
}
}
--
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-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Assigned: (AXIOM-351) Links in Javadoc JARs are broken
[ https://issues.apache.org/jira/browse/AXIOM-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen reassigned AXIOM-351: - Assignee: Andreas Veithen Links in Javadoc JARs are broken Key: AXIOM-351 URL: https://issues.apache.org/jira/browse/AXIOM-351 Project: Axiom Issue Type: Bug Affects Versions: 1.2.10 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.11 For classes in dependency projects, the Javadoc JARs normally have links pointing to the online Javadoc in the Web site of these dependencies. In the Javadoc JARs generated for the different Axiom modules, the links to the Javadoc of classes in other Axiom modules are broken. E.g. the Javadoc of org.apache.axiom.om.impl.llom.OMNodeImpl has a link to http://ws.apache.org/axiom/axiom-api/apidocs/org/apache/axiom/om/OMNode.html while this should be http://ws.apache.org/axiom/apidocs/org/apache/axiom/om/OMNode.html (note the extra 'axiom-api'). This can also be seen in some online Javadoc browser services. Example: http://www.jarvana.com/jarvana/view/org/apache/ws/commons/axiom/axiom-dom/1.2.9/axiom-dom-1.2.9-javadoc.jar!/org/apache/axiom/soap/impl/dom/SOAPHeaderImpl.html In addition, the Project Dependencies report of some downstream projects has incorrect links for individual Axiom modules. An example is Rampart: http://axis.apache.org/axis2/java/rampart/dependencies.html These two issues are presumably caused by the fact that project.url is not set correctly in the POMs of the individual Axiom modules. -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Resolved: (AXIOM-346) Enhance OMStAXWrapper/OMNavigator to work with OMDocument objects
[ https://issues.apache.org/jira/browse/AXIOM-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-346. --- Resolution: Fixed Enhance OMStAXWrapper/OMNavigator to work with OMDocument objects - Key: AXIOM-346 URL: https://issues.apache.org/jira/browse/AXIOM-346 Project: Axiom Issue Type: Improvement Components: API Affects Versions: 1.2.8 Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.11 Attachments: WSCOMMONS-450.patch OMStAXWrapper only works with OMElements and OMNavigator only with OMNodes. It should be easy make this work with OMDocument objects as well. This would allow to get an XMLStreamReader for the entire document (Note the missing getXMLStreamReader(WithoutCaching) method in OMDocument). -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Moved: (XMLSCHEMA-9) Relative path in multiple import include failed when reading a schema
[
https://issues.apache.org/jira/browse/XMLSCHEMA-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen moved WSCOMMONS-565 to XMLSCHEMA-9:
---
Component/s: (was: XmlSchema)
Affects Version/s: (was: XmlSchema 1.4.7)
XmlSchema 1.4.7
Key: XMLSCHEMA-9 (was: WSCOMMONS-565)
Project: XmlSchema (was: WS-Commons)
Relative path in multiple import include failed when reading a schema
-
Key: XMLSCHEMA-9
URL: https://issues.apache.org/jira/browse/XMLSCHEMA-9
Project: XmlSchema
Issue Type: Bug
Affects Versions: XmlSchema 1.4.7
Reporter: Jemini Sam
Attachments: RelativeExample.zip
When we want to load a schema with import/include on cascade, if the
*schemaLocation* is a relative path, the *SchemaBuilder* class fails to find
schemas which aren't in the same directory of the schema to load.
For example, if we have 3 schemas :
- s1.xsd in directory a/b/c which imports s2.xsd in a/b
- and s2.xsd which includes or imports s3.xsd in the same directory
a/b/c/s1.xsd
a/b/s2.xsd
a/b/s3.xsd
And we want to read the schema s1.xsd :
{code}
String sourceXSD = resources/schemas/a/b/c/s1.xsd;
InputStream is;
try {
is = new FileInputStream(sourceXSD);
XmlSchemaCollection schemaCol = new XmlSchemaCollection();
schemaCol.setBaseUri(new File(sourceXSD).getParent().replaceAll(, /));
DefaultURIResolver schemaResolver = (DefaultURIResolver)
schemaCol.getSchemaResolver();
System.out.println(schemaResolver.toString(): +
schemaResolver.getCollectionBaseURI());
XmlSchema schema = schemaCol.read(new StreamSource(is), null);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
{code}
We have an exception on s3.xsd schema which is not found in directory a/b/c.
See the sources of the example attached.
--
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-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Commented: (WSS-266) Provide better support for pluggable authentication/verification of security tokens
[ https://issues.apache.org/jira/browse/WSS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12985977#action_12985977 ] Andreas Veithen commented on WSS-266: - What about a use case where you want to delegate authentication to LDAP? In that case you can't retrieve the password for a given user, so there is no way to let the CallbackHandler supply the password to WSS4J. The only thing it can do is to validate a (plaintext) password supplied by WSS4J. Provide better support for pluggable authentication/verification of security tokens --- Key: WSS-266 URL: https://issues.apache.org/jira/browse/WSS-266 Project: WSS4J Issue Type: Improvement Affects Versions: 1.5.10 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 1.6 The way WSS4J currently processes an inbound security header is to iterate through the security header, and to store the processing results for later verification. It defers two pieces of validation to third-party WSHandler implementations: * Timestamp verification * Certificate trust validation There are a couple of problems with approach. Firstly, it is not consistent, as WSS4J performs validation on certain tokens (e.g. Username Tokens) when processing the security header, and does not validate other tokens, such as Timestamps. CXF has to resort to a hack to stop WSS4J processing a Username Token, for certain cases. Secondly, it assumes that calling code will know that Timestamps/certs must be validated, which is a potential security hole. Thirdly, WSS4J will continue to process the rest of the security header even if the Timestamp is invalid, or the certificate non-trusted, which could lead to denial-of-service attacks. WSS4J 1.6-SNAPSHOT has moved timestamp verification, and certificate trust validation, back into the processing of the security header, so this solves the problem above. What remains to be done though, is to make it easier to plug in a way to perform custom validation of security tokens as WSS4J is processing them. This is probably not such an important issue for Timestamp validation, as for the other two. As part of this task, I'm thinking of changing the way the CallbackHandler implementation works in WSS4J. Currently, it supplies passwords for some cases, and is expected to verify passwords for other cases. It would be better to let the CallbackHandler implementations solely supply the password for the processors. A new Validator interface would then validate the token using the parsing done by the processor, and the password supplied by the callback. This would allow the end-user to plug in different validators. WSS4J would supply some default validators, so the default behaviour remains the same. -- 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-31) Axiom MIME parser does not support MIME parts without content-id's
[ https://issues.apache.org/jira/browse/AXIOM-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-31: - Fix Version/s: (was: 1.2.11) 1.2.12 Axiom MIME parser does not support MIME parts without content-id's -- Key: AXIOM-31 URL: https://issues.apache.org/jira/browse/AXIOM-31 Project: Axiom Issue Type: Bug Components: API Reporter: Thilina Gunarathne Assignee: Andreas Veithen Fix For: 1.2.12 Attachments: axiom_mixed_content_patch.txt Axiom MIME parser does the content-id validation for the MIME parts as required by MTOM SwA..Also the Attachments API is designed as a map (content-id, attachment) with this assumption.. But now the mail transport is going to use the same MIME parser and they have valid messages which does not have content-id's for MIME parts. But IMHO trying to generalize all axiom/Axis2 attachment API's would be a too much of an API change at this point of the project... Attached is a quick patch to generate a UUID in place of the missing content-id... But with this we are going to miss the content-id validation... WDYT? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-201) OMSourcedElement is always expanded when getXMLStreamReader is used on one of its ancestors
[ https://issues.apache.org/jira/browse/AXIOM-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-201: -- Fix Version/s: (was: 1.2.11) 1.2.12 OMSourcedElement is always expanded when getXMLStreamReader is used on one of its ancestors --- Key: AXIOM-201 URL: https://issues.apache.org/jira/browse/AXIOM-201 Project: Axiom Issue Type: Bug Affects Versions: 1.2.8 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.12 Scenario: getXMLStreamReader is called on an OMElement that has an OMSourcedElement as one of its descendents. Result: After the XMLStreamReader has been consumed, the OMSourcedElement is expanded, even if it is backed by a data source that supports non destructive reads. When encountering an OMSourcedElement, StAXOMWrapper should insert the events from the XMLStreamReader produced by the OMDataSource instead of generating the events by traversing the OMSourcedElement (which results in its expansion). This is currently not implemented. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-280) Add access to the Content Transfer Encoding value from DataHandler
[ https://issues.apache.org/jira/browse/AXIOM-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-280: -- Fix Version/s: (was: 1.2.11) 1.2.12 Add access to the Content Transfer Encoding value from DataHandler -- Key: AXIOM-280 URL: https://issues.apache.org/jira/browse/AXIOM-280 Project: Axiom Issue Type: Improvement Components: API Affects Versions: 1.2.8 Reporter: Tim Mitchell Assignee: Andreas Veithen Fix For: 1.2.12 Attachments: ContentTransferEncodingDiff.txt We have a need to be able to identify how an SWA attachment was encoded in the message, by accessing the Content Transfer Encoding. Currently the DataHandler does contain this info, but there is no method you can use to get to the data. I have created a fix and an accompanying testcase. Please could you review the changes and if you're happy please could you integrate the fix. I intend to post on the Axiom mailing list to broadcast my suggestion. I've attached the diff details as an attachment. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-320) Allow StAXSOAPModelBuilder to fallback to XML infoset if the document is not SOAP
[ https://issues.apache.org/jira/browse/AXIOM-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-320: -- Fix Version/s: (was: 1.2.11) 1.2.12 Allow StAXSOAPModelBuilder to fallback to XML infoset if the document is not SOAP - Key: AXIOM-320 URL: https://issues.apache.org/jira/browse/AXIOM-320 Project: Axiom Issue Type: Improvement Reporter: Andreas Veithen Priority: Minor Fix For: 1.2.12 Currently, StAXOMBuilder can only be used to build an XML infoset, while StAXSOAPModelBuilder can only be used to build a SOAP infoset model. However in some cases it is impossible to determine beforehand whether a document or message is SOAP or plain XML. To handle this case with the current version of Axiom, the only available strategy is to start processing the document with one of the two builders and restart the processing with the other if the document doesn't match the type of builder. The proposal is to modify StAXSOAPModelBuilder so that it (optionally) falls back to plain XML if it detects that the document element is not a SOAP envelope. This should be feasible since StAXSOAPModelBuilder extends StAXOMBuilder. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-114) Soap envelope rpc-encoded namespace issue
[ https://issues.apache.org/jira/browse/AXIOM-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-114: -- Fix Version/s: (was: 1.2.11) 1.2.12 Soap envelope rpc-encoded namespace issue -- Key: AXIOM-114 URL: https://issues.apache.org/jira/browse/AXIOM-114 Project: Axiom Issue Type: Bug Affects Versions: 1.2.8 Environment: java 1.6 Reporter: Luca Cavanna Fix For: 1.2.12 Attachments: AxiomSoapRpcEncoded.java, AxiomSoapRpcEncodedOMSource.java, soaprequest.xml I have replaced saaj with axiom in my projects to manage soap handling. I have an rpc-encoded soap envelope containing the declarations of soapenv (xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;) and xsi (xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;) namespaces. The first element of the soap body references soapenv in one of his attributes (soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;). Some xml elements in the soap body reference the xsi namespace (xsi:type=soapenc:string) as well. When I try to parse the soap body (extracted from the soap envelope) using JDOM or DOM4J I get a SaxParseException because the soapenv and xsi namespaces are not bound: org.xml.sax.SAXParseException: The prefix soapenv for attribute soapenv:encodingStyle associated with an element type ns1:sendMessage is not bound. Saaj handles correctly the soapenv and and xsi declarations moving them in the soap body; with axiom the soap body contain only the reference to those namespaces and not the declarations. The issue seems to be creating a StAXSource from Axiom payload element (obtained by calling axiomSoapMessage.getSOAPEnvelope().getBody().getFirstElement()); serializing payload calling serialize method namespace are correctly handled, but creating a StAXSource using XMLStreamReader and transforming it to a StreamResult I get an xml not parseable because namespaces are not bound. I have found a workaround transforming the StAXSource in a JDOMResult. The problem rises when you create a StAXSource from an Axiom payload element (calling axiomSoapMessage.getSOAPEnvelope().getBody().getFirstElement()). When you call the serialize method, namespaces are correctly handled; but if you create a StAXSource using an XMLStreamReader and try to transform it to a StreamResult you get the SaxParseException mentioned above. I have found a workaround transforming the StAXSource in a JDOMResult. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-28) OMElement.declareDefaultNamespace() declares empty namespace for child element.
[
https://issues.apache.org/jira/browse/AXIOM-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated AXIOM-28:
-
Component/s: LLOM
Fix Version/s: (was: 1.2.11)
1.2.12
OMElement.declareDefaultNamespace() declares empty namespace for child
element.
---
Key: AXIOM-28
URL: https://issues.apache.org/jira/browse/AXIOM-28
Project: Axiom
Issue Type: Bug
Components: LLOM
Affects Versions: 1.2.8
Environment: Microsoft Windows 2003 Server, Java 1.5.0_11. Axis2
version 1.3 (uses AXIOM version 1.2.5).
Reporter: Yechiel Mondrowitz
Assignee: Andreas Veithen
Fix For: 1.2.12
When calling declareDefaultNamespace() on a parent node, AXIOM assignes a
blank namespace on the first level's child element. So if XML is passed to
AXIOM that looks like this:
outerTag
innerTag
node1Hello/node1
node2Hello/node2
/innerTag
/outerTag
And then declareDefaultNamespace() of http://someNamespace; is called on the
outerTag, the resulting XML will be this:
outerTag xmlns=http://someNamespace;
innerTag xmlns=
node1Hello/node1
node2Hello/node2
/innerTag
/outerTag
Notice the xmlns= declared in the innerTag. According to my
understanding of XML namespaces, the innerTag and its child nodes will no
longer belong to the parent namespace of http://someNamespace;, since it
explicitly overrides it with an empty namespace. So innerTag and its child
nodes will in fact not belong to any namespace! Here is a small program to
illustrate:
import org.apache.axiom.om.*;
import org.apache.axiom.om.impl.llom.util.*;
public class Test2 {
public static void main(String [] args) {
try {
String xmlString =
outerTag +
innerTag +
node1Hello/node1 +
node2Hello/node2 +
/innerTag +
/outerTag;
OMElement elem = AXIOMUtil.stringToOM(xmlString);
elem.declareDefaultNamespace(http://someNamespace;);
System.out.println(elem.toString());
}
catch(Exception e) {
e.printStackTrace();
}
}
}
The output of this program is this (I added line breaks in the XML for easier
readability):
outerTag xmlns=http://someNamespace;
innerTag xmlns=
node1Hello/node1
node2Hello/node2
/innerTag
/outerTag
As you can see, the innerTag was assigned xmlns= by AXIOM.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-354) Potential class loader leak caused by the thread local in org.apache.axiom.util.UIDGenerator
[ https://issues.apache.org/jira/browse/AXIOM-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-354: -- Fix Version/s: 1.2.12 Potential class loader leak caused by the thread local in org.apache.axiom.util.UIDGenerator Key: AXIOM-354 URL: https://issues.apache.org/jira/browse/AXIOM-354 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.10 Reporter: Andreas Veithen Fix For: 1.2.12 UIDGenerator uses a ThreadLocal with a value class that belongs to Axiom (namely UIDGeneratorImpl). Since the ThreadLocal is never cleaned up explicitly (doing that would break the UIDGenerator), this may cause a class loader leak (i.e. in a Web application, it may prevent the class loader from being garbage collected when the application is stopped). Since UIDGeneratorImpl basically stores 3 values of type long, it should be easy to refactor the code so that the value class ThreadLocal is not loaded from the application class loader (e.g. by using long[] as value class). However, I first need to confirm that there is really a class loader leak here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-356) OMElement#resolveQName implementations use incorrect algorithm to resolve unprefixed QNames
[
https://issues.apache.org/jira/browse/AXIOM-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated AXIOM-356:
--
Fix Version/s: 1.2.12
OMElement#resolveQName implementations use incorrect algorithm to resolve
unprefixed QNames
---
Key: AXIOM-356
URL: https://issues.apache.org/jira/browse/AXIOM-356
Project: Axiom
Issue Type: Bug
Components: DOOM, LLOM
Affects Versions: 1.2.10
Reporter: Andreas Veithen
Fix For: 1.2.12
Consider the following element:
p:root xmlns:p='urn:ns1' xmlns='urn:ns2'/
When OMElement#resolveQName is used to resolve an unprefixed QName literal
relative to this element, then the returned QName object has:
namespaceURI = urn:ns1
prefix = p
The reason is that ElementHelper#resolveQName contains code that will pick up
the namespace of the parent element if the QName literal is unprefixed. This
applies to the LLOM and DOOM implementations.
However, none of the XML specs describe a QName resolution algorithm that
works like that. There are only two valid options to resolve a QName:
A. Resolve it in the same way as element names, i.e. an unprefixed QName
literal will be interpreted based on the default namespace in scope. This is
what the XML schema spec requires [1] for the QName type:
[quote]
1 If its - normalized value- is prefixed, then all of the following must be
true:
1.1 There must be a namespace in the [in-scope namespaces] whose [prefix]
matches the prefix.
1.2 its - namespace name- is the [namespace name] of that namespace.
1.3 Its - local name- is the portion of its - normalized value- after the
colon (':').
2 otherwise (its - normalized value- is unprefixed) all of the following
must be true:
2.1 its - local name- is its - normalized value- .
2.2 The appropriate case among the following must be true:
2.2.1 If there is a namespace in the [in-scope namespaces] whose [prefix] has
no value, then its - namespace name- is the [namespace name] of that
namespace.
2.2.2 otherwise its - namespace name- is - absent- .
[/quote]
B. Resolve it in the same way as attribute names, i.e. an unprefixed QName
literal will have no namespace. This is what the XSL spec requires [2] for
QNames appearing in XPath expressions:
the set of namespace declarations are those in scope on the element which
has the attribute in which the expression occurs; this includes the implicit
declaration of the prefix xml required by the the XML Namespaces
Recommendation [XML Names]; the default namespace (as declared by xmlns) is
not part of this set
Since OMElement#resolveQName is in general used to interpret literals of the
QName schema type, it should implement algorithm A. For the specific case of
XPath expressions, AXIOMXPath#addNamespaces(OMElement) already implements
algorithm B.
Unit tests are already available, but they are currently excluded from the
LLOM and DOOM test suites:
TestResolveQNameWithDefaultNamespace
TestResolveQNameWithoutNamespace
It should not be difficult to fix the resolveQName implementation. The only
uncertainty is whether downstream projects such as Axis2 depend on the
current behavior.
[1] http://www.w3.org/TR/xmlschema-1/#src-qname
[2] http://www.w3.org/TR/xslt#section-Expressions
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-353) Need a replacement for OMXMLBuilderFactory
[ https://issues.apache.org/jira/browse/AXIOM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-353: -- Fix Version/s: (was: 1.2.11) 1.2.12 Will be finalized for 1.2.12. Need a replacement for OMXMLBuilderFactory -- Key: AXIOM-353 URL: https://issues.apache.org/jira/browse/AXIOM-353 Project: Axiom Issue Type: Improvement Components: API Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.12 Historically, org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory was used to create Axiom trees from XML documents (and there are still places in Axis2 where this is used). Unfortunately, this class is located in the wrong package and JAR (it is implementation independent but belongs to LLOM). Nowadays, the standard way to create an Axiom tree is to instantiate StAXOMBuilder or one of its subclasses directly. However, this is not optimal for two reasons: * It implies the assumption that every implementation of the Axiom API necessarily uses StAXOMBuilder. This means that an implementation doesn't have the freedom to provide its own builder implementation (e.g. in order to implement some special optimizations). * StAXOMBuilder belongs to a package which has impl in its name. This tends to blur the distinction between the public API and internal implementation classes. There should be an abstract API for creating builder instances. It should be defined in terms of interfaces (such as OMXMLParserWrapper). OMMetaFactory is a good candidate for this because it is already used to encapsulate an implementation of the Axiom API (there is one implementation of OMMetaFactory for LLOM and one for DOOM). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Updated: (AXIOM-63) OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events
[ https://issues.apache.org/jira/browse/AXIOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-63: - Fix Version/s: (was: 1.2.11) 1.2.12 OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events Key: AXIOM-63 URL: https://issues.apache.org/jira/browse/AXIOM-63 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.9 Reporter: Andreas Veithen Priority: Minor Fix For: 1.2.12 The code in OMXMLStreamReaderValidator implicitly makes the assumption that the parser state (event) may only change during calls to next(). This is incorrect, because calls to getElementText() and nextTag() also consume events from the parser. This sometimes causes OMXMLStreamReaderValidator to report mismatched END_ELEMENT events although the sequence of events produced by the parent XMLStreamReader is correct. An example of this can be seen in AXIS2-4854. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Work started: (AXIOM-63) OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events
[ https://issues.apache.org/jira/browse/AXIOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIOM-63 started by Andreas Veithen. OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events Key: AXIOM-63 URL: https://issues.apache.org/jira/browse/AXIOM-63 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.9 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.12 The code in OMXMLStreamReaderValidator implicitly makes the assumption that the parser state (event) may only change during calls to next(). This is incorrect, because calls to getElementText() and nextTag() also consume events from the parser. This sometimes causes OMXMLStreamReaderValidator to report mismatched END_ELEMENT events although the sequence of events produced by the parent XMLStreamReader is correct. An example of this can be seen in AXIS2-4854. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Assigned: (AXIOM-63) OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events
[ https://issues.apache.org/jira/browse/AXIOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen reassigned AXIOM-63: Assignee: Andreas Veithen OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events Key: AXIOM-63 URL: https://issues.apache.org/jira/browse/AXIOM-63 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.9 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.12 The code in OMXMLStreamReaderValidator implicitly makes the assumption that the parser state (event) may only change during calls to next(). This is incorrect, because calls to getElementText() and nextTag() also consume events from the parser. This sometimes causes OMXMLStreamReaderValidator to report mismatched END_ELEMENT events although the sequence of events produced by the parent XMLStreamReader is correct. An example of this can be seen in AXIS2-4854. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Resolved: (AXIOM-63) OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events
[ https://issues.apache.org/jira/browse/AXIOM-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-63. -- Resolution: Fixed OMXMLStreamReaderValidator incorrectly reports mismatched END_ELEMENT events Key: AXIOM-63 URL: https://issues.apache.org/jira/browse/AXIOM-63 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.9 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.12 The code in OMXMLStreamReaderValidator implicitly makes the assumption that the parser state (event) may only change during calls to next(). This is incorrect, because calls to getElementText() and nextTag() also consume events from the parser. This sometimes causes OMXMLStreamReaderValidator to report mismatched END_ELEMENT events although the sequence of events produced by the parent XMLStreamReader is correct. An example of this can be seen in AXIS2-4854. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Commented: (AXIOM-357) org.apache.axiom.om.util.CopyUtils throws NPE when used to copy a SOAPEnvelope containing a SOAP 1.1 SOAPFault
[ https://issues.apache.org/jira/browse/AXIOM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002767#comment-13002767 ] Andreas Veithen commented on AXIOM-357: --- Daniel, can you provide a unit test that reproduces the issue? org.apache.axiom.om.util.CopyUtils throws NPE when used to copy a SOAPEnvelope containing a SOAP 1.1 SOAPFault -- Key: AXIOM-357 URL: https://issues.apache.org/jira/browse/AXIOM-357 Project: Axiom Issue Type: Bug Environment: All Reporter: Daniel James Matthews Original Estimate: 4h Remaining Estimate: 4h NPE when using CopyUtils.copy on a SOAPEnvelope containing a SOAP 1.1 SOAPFault. This is because the copySOAPFaultCode method assumes that the SOAPFaultCode has a Value child element, but that's only true for SOAP 1.2. In SOAP 1.1 the SOAPFault contains a text element, not a Value element. I have a patch available where I copy the text or Value based on the namespace of the SOAPFactory. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (AXIOM-358) OMStAXWrapper#hasNext may return incorrect value
OMStAXWrapper#hasNext may return incorrect value Key: AXIOM-358 URL: https://issues.apache.org/jira/browse/AXIOM-358 Project: Axiom Issue Type: Bug Components: DOOM, LLOM Affects Versions: 1.2.11 Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.12 The StAX specification defines the XMLStreamReader#hasNext() method as follows: Returns true if there are more parsing events and false if there are no more events. This method will return false if the current state of the XMLStreamReader is END_DOCUMENT. In some cases, the hasNext method in OMStAXWrapper/SwitchingWrapper already returns false on the event immediately preceding the END_DOCUMENT event. This means that when using a loop constructed with hasNext, the END_DOCUMENT event is missed. Note that some code in Axis2 seems to depend on this incorrect behavior and will have to be fixed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-75) Namespace declaration cannot be removed from OMElement
[ https://issues.apache.org/jira/browse/AXIOM-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-75: - Priority: Minor (was: Critical) Namespace declaration cannot be removed from OMElement -- Key: AXIOM-75 URL: https://issues.apache.org/jira/browse/AXIOM-75 Project: Axiom Issue Type: Bug Environment: Windows Reporter: Toshiro Takase Priority: Minor Fix For: 1.3 Once an useless namespace declaration is declared to an OMElement, the namespace declaration cannot be removed forever. In DOM, we can remove namespace declarations by using Element.removeAttribute() . But, in AXIOM, we cannot remove namespace declarations by OMElement.removeAttribute() . Maybe, we need OMElement.removeDeclaredNamespace() ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Assigned] (AXIOM-356) OMElement#resolveQName implementations use incorrect algorithm to resolve unprefixed QNames
[
https://issues.apache.org/jira/browse/AXIOM-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen reassigned AXIOM-356:
-
Assignee: Andreas Veithen
OMElement#resolveQName implementations use incorrect algorithm to resolve
unprefixed QNames
---
Key: AXIOM-356
URL: https://issues.apache.org/jira/browse/AXIOM-356
Project: Axiom
Issue Type: Bug
Components: DOOM, LLOM
Affects Versions: 1.2.10
Reporter: Andreas Veithen
Assignee: Andreas Veithen
Fix For: 1.2.12
Consider the following element:
p:root xmlns:p='urn:ns1' xmlns='urn:ns2'/
When OMElement#resolveQName is used to resolve an unprefixed QName literal
relative to this element, then the returned QName object has:
namespaceURI = urn:ns1
prefix = p
The reason is that ElementHelper#resolveQName contains code that will pick up
the namespace of the parent element if the QName literal is unprefixed. This
applies to the LLOM and DOOM implementations.
However, none of the XML specs describe a QName resolution algorithm that
works like that. There are only two valid options to resolve a QName:
A. Resolve it in the same way as element names, i.e. an unprefixed QName
literal will be interpreted based on the default namespace in scope. This is
what the XML schema spec requires [1] for the QName type:
[quote]
1 If its - normalized value- is prefixed, then all of the following must be
true:
1.1 There must be a namespace in the [in-scope namespaces] whose [prefix]
matches the prefix.
1.2 its - namespace name- is the [namespace name] of that namespace.
1.3 Its - local name- is the portion of its - normalized value- after the
colon (':').
2 otherwise (its - normalized value- is unprefixed) all of the following
must be true:
2.1 its - local name- is its - normalized value- .
2.2 The appropriate case among the following must be true:
2.2.1 If there is a namespace in the [in-scope namespaces] whose [prefix] has
no value, then its - namespace name- is the [namespace name] of that
namespace.
2.2.2 otherwise its - namespace name- is - absent- .
[/quote]
B. Resolve it in the same way as attribute names, i.e. an unprefixed QName
literal will have no namespace. This is what the XSL spec requires [2] for
QNames appearing in XPath expressions:
the set of namespace declarations are those in scope on the element which
has the attribute in which the expression occurs; this includes the implicit
declaration of the prefix xml required by the the XML Namespaces
Recommendation [XML Names]; the default namespace (as declared by xmlns) is
not part of this set
Since OMElement#resolveQName is in general used to interpret literals of the
QName schema type, it should implement algorithm A. For the specific case of
XPath expressions, AXIOMXPath#addNamespaces(OMElement) already implements
algorithm B.
Unit tests are already available, but they are currently excluded from the
LLOM and DOOM test suites:
TestResolveQNameWithDefaultNamespace
TestResolveQNameWithoutNamespace
It should not be difficult to fix the resolveQName implementation. The only
uncertainty is whether downstream projects such as Axis2 depend on the
current behavior.
[1] http://www.w3.org/TR/xmlschema-1/#src-qname
[2] http://www.w3.org/TR/xslt#section-Expressions
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-356) OMElement#resolveQName implementations use incorrect algorithm to resolve unprefixed QNames
[
https://issues.apache.org/jira/browse/AXIOM-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved AXIOM-356.
---
Resolution: Fixed
OMElement#resolveQName implementations use incorrect algorithm to resolve
unprefixed QNames
---
Key: AXIOM-356
URL: https://issues.apache.org/jira/browse/AXIOM-356
Project: Axiom
Issue Type: Bug
Components: DOOM, LLOM
Affects Versions: 1.2.10
Reporter: Andreas Veithen
Assignee: Andreas Veithen
Fix For: 1.2.12
Consider the following element:
p:root xmlns:p='urn:ns1' xmlns='urn:ns2'/
When OMElement#resolveQName is used to resolve an unprefixed QName literal
relative to this element, then the returned QName object has:
namespaceURI = urn:ns1
prefix = p
The reason is that ElementHelper#resolveQName contains code that will pick up
the namespace of the parent element if the QName literal is unprefixed. This
applies to the LLOM and DOOM implementations.
However, none of the XML specs describe a QName resolution algorithm that
works like that. There are only two valid options to resolve a QName:
A. Resolve it in the same way as element names, i.e. an unprefixed QName
literal will be interpreted based on the default namespace in scope. This is
what the XML schema spec requires [1] for the QName type:
[quote]
1 If its - normalized value- is prefixed, then all of the following must be
true:
1.1 There must be a namespace in the [in-scope namespaces] whose [prefix]
matches the prefix.
1.2 its - namespace name- is the [namespace name] of that namespace.
1.3 Its - local name- is the portion of its - normalized value- after the
colon (':').
2 otherwise (its - normalized value- is unprefixed) all of the following
must be true:
2.1 its - local name- is its - normalized value- .
2.2 The appropriate case among the following must be true:
2.2.1 If there is a namespace in the [in-scope namespaces] whose [prefix] has
no value, then its - namespace name- is the [namespace name] of that
namespace.
2.2.2 otherwise its - namespace name- is - absent- .
[/quote]
B. Resolve it in the same way as attribute names, i.e. an unprefixed QName
literal will have no namespace. This is what the XSL spec requires [2] for
QNames appearing in XPath expressions:
the set of namespace declarations are those in scope on the element which
has the attribute in which the expression occurs; this includes the implicit
declaration of the prefix xml required by the the XML Namespaces
Recommendation [XML Names]; the default namespace (as declared by xmlns) is
not part of this set
Since OMElement#resolveQName is in general used to interpret literals of the
QName schema type, it should implement algorithm A. For the specific case of
XPath expressions, AXIOMXPath#addNamespaces(OMElement) already implements
algorithm B.
Unit tests are already available, but they are currently excluded from the
LLOM and DOOM test suites:
TestResolveQNameWithDefaultNamespace
TestResolveQNameWithoutNamespace
It should not be difficult to fix the resolveQName implementation. The only
uncertainty is whether downstream projects such as Axis2 depend on the
current behavior.
[1] http://www.w3.org/TR/xmlschema-1/#src-qname
[2] http://www.w3.org/TR/xslt#section-Expressions
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-362) SOAPHeader examineAllHeaderBlocks throws ClassCastException
[ https://issues.apache.org/jira/browse/AXIOM-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-362: -- Priority: Minor (was: Major) Changed priority to minor because the issue is triggered by the way the SOAPHeader is constructed and there is an easy workaround. Nevertheless, there is an issue and we need to think about how Axiom should react if somebody tries to add a plain OMElement to a SOAPHeader. SOAPHeader examineAllHeaderBlocks throws ClassCastException --- Key: AXIOM-362 URL: https://issues.apache.org/jira/browse/AXIOM-362 Project: Axiom Issue Type: Bug Components: LLOM Affects Versions: 1.2.11 Reporter: Auke Schrijnen Priority: Minor Attachments: axiom-soapheader.patch The llom SOAPHeaderImpl class throws a ClassCastException: java.lang.ClassCastException: org.apache.axiom.om.impl.llom.OMElementImpl cannot be cast to org.apache.axiom.soap.SOAPHeaderBlock at org.apache.axiom.soap.impl.llom.SOAPHeaderImpl$HeaderIterator.init(SOAPHeaderImpl.java:181) at org.apache.axiom.soap.impl.llom.SOAPHeaderImpl.examineAllHeaderBlocks(SOAPHeaderImpl.java:358) at org.apache.synapse.core.axis2.Axis2MessageContext.toString(Axis2MessageContext.java:485) at java.lang.String.valueOf(String.java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.synapse.mediators.eip.aggregator.AggregateMediator.mediate(AggregateMediator.java:249) at ... The HeaderIterator does check for nodes other than a SOAPHeaderBlock node, except for the first element. The method 'hasNext' does check if nodes are SOAPHeaderBlock nodes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-362) SOAPHeader examineAllHeaderBlocks throws ClassCastException
[ https://issues.apache.org/jira/browse/AXIOM-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13018477#comment-13018477 ] Andreas Veithen commented on AXIOM-362: --- Found an interesting comment in LLOM's SOAPHeaderImpl#addChild method: // Make sure a proper element is added. The children of a SOAPHeader should be // SOAPHeaderBlock objects. // Due to legacy usages (AXIS2 has a lot of tests that violate this constraint) // I am only going to log an exception when debug is enabled. Action plan: * Fix the Axis2 test cases that add plain OMElement instances to SOAPHeader. * Change the addChild implementation to throw an exception if the child is not a SOAPHeaderBlock. SOAPHeader examineAllHeaderBlocks throws ClassCastException --- Key: AXIOM-362 URL: https://issues.apache.org/jira/browse/AXIOM-362 Project: Axiom Issue Type: Bug Components: LLOM Affects Versions: 1.2.11 Reporter: Auke Schrijnen Priority: Minor Attachments: axiom-soapheader.patch The llom SOAPHeaderImpl class throws a ClassCastException: java.lang.ClassCastException: org.apache.axiom.om.impl.llom.OMElementImpl cannot be cast to org.apache.axiom.soap.SOAPHeaderBlock at org.apache.axiom.soap.impl.llom.SOAPHeaderImpl$HeaderIterator.init(SOAPHeaderImpl.java:181) at org.apache.axiom.soap.impl.llom.SOAPHeaderImpl.examineAllHeaderBlocks(SOAPHeaderImpl.java:358) at org.apache.synapse.core.axis2.Axis2MessageContext.toString(Axis2MessageContext.java:485) at java.lang.String.valueOf(String.java:2826) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.synapse.mediators.eip.aggregator.AggregateMediator.mediate(AggregateMediator.java:249) at ... The HeaderIterator does check for nodes other than a SOAPHeaderBlock node, except for the first element. The method 'hasNext' does check if nodes are SOAPHeaderBlock nodes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-357) org.apache.axiom.om.util.CopyUtils throws NPE when used to copy a SOAPEnvelope containing a SOAP 1.1 SOAPFault
[ https://issues.apache.org/jira/browse/AXIOM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-357: -- Component/s: API Affects Version/s: 1.2.11 Fix Version/s: 1.2.12 Assignee: Andreas Veithen org.apache.axiom.om.util.CopyUtils throws NPE when used to copy a SOAPEnvelope containing a SOAP 1.1 SOAPFault -- Key: AXIOM-357 URL: https://issues.apache.org/jira/browse/AXIOM-357 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.11 Environment: All Reporter: Daniel James Matthews Assignee: Andreas Veithen Fix For: 1.2.12 Original Estimate: 4h Remaining Estimate: 4h NPE when using CopyUtils.copy on a SOAPEnvelope containing a SOAP 1.1 SOAPFault. This is because the copySOAPFaultCode method assumes that the SOAPFaultCode has a Value child element, but that's only true for SOAP 1.2. In SOAP 1.1 the SOAPFault contains a text element, not a Value element. I have a patch available where I copy the text or Value based on the namespace of the SOAPFactory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-305) Need OMElement.getNamespaceURI() convenience method
[ https://issues.apache.org/jira/browse/AXIOM-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-305: -- Fix Version/s: (was: 1.3) 1.2.12 Need OMElement.getNamespaceURI() convenience method --- Key: AXIOM-305 URL: https://issues.apache.org/jira/browse/AXIOM-305 Project: Axiom Issue Type: Improvement Reporter: Glen Daniels Assignee: Glen Daniels Fix For: 1.2.12 Attachments: patch.txt, patch2.txt It is extremely *in*convenient to constantly have to type element.getNamespace().getNamespaceURI() in order to simply get the String namespace from an OMElement. :) We should add a convenience method OMElement.getNamespaceURI(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (NEETHI-9) Errors in XML object model conversions are not handled properly
Errors in XML object model conversions are not handled properly --- Key: NEETHI-9 URL: https://issues.apache.org/jira/browse/NEETHI-9 Project: Neethi Issue Type: Bug Affects Versions: 3.0 Reporter: Andreas Veithen Priority: Minor Implementations of Converter#convert return null when an error occurs during conversion. On the other hand, AssertionBuilderFactoryImpl#invokeBuilder doesn't check for a null return value. This means that when an error occurs, a null value is passed to AssertionBuilder#build, which leads to unexpected results. Also, the fact that the implementations of Converter#convert swallow most exceptions makes it hard to debug issues caused by problems during object model conversion. We have two options: 1. Let Converter#convert throw an exception if there is a problem. 2. Add a null check in AssertionBuilderFactoryImpl#invokeBuilder (to solve the first problem) and make sure that exceptions thrown in Converter#convert are logged (to solve the second problem). In this case, we need to agree on the logging API to be used (commons logging or SLF4J). Personally, I prefer option 1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (XMLSCHEMA-3) DefaultURIResolver doesn't resolve JAR style URLs properly
[ https://issues.apache.org/jira/browse/XMLSCHEMA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030523#comment-13030523 ] Andreas Veithen commented on XMLSCHEMA-3: - The issue is still linked to an open issue in AXIS2. I will have a closer look and fix the issue when I get the time. DefaultURIResolver doesn't resolve JAR style URLs properly -- Key: XMLSCHEMA-3 URL: https://issues.apache.org/jira/browse/XMLSCHEMA-3 Project: XmlSchema Issue Type: Bug Affects Versions: XmlSchema 1.4.2, XmlSchema 1.4.6 Reporter: Andreas Veithen Priority: Minor DefaultURIResolver is unable to resolve entities against a base URI of the following form: jar:file:/D:/data/my.jar!/package/schema.xsd The reason is that resolveEntity uses java.net.URI: the URI is opaque and java.net.URI doesn't resolve relative URIs against opaque URIs. The original version of DefaultURIResolver (r396478) used java.net.URL and worked perfectly in that case. This was broken in r400374. The impact of this issue is that it is not possible to load schemas from the classpath, if they have imports and DefaultURIResolver is used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (XMLSCHEMA-11) XmlSchemaChoice.getItems() should probably return XmlSchemaChoiceMember instead of XmlSchemaObject.
[ https://issues.apache.org/jira/browse/XMLSCHEMA-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030524#comment-13030524 ] Andreas Veithen commented on XMLSCHEMA-11: -- As already pointed out in [1], having interfaces in org.apache.ws.commons.schema extend an interface in org.apache.ws.commons.schema.utils doesn't sound correct. BTW, Benson, you never replied to that objection. [1] http://markmail.org/message/6ha4ktfeyme43mul XmlSchemaChoice.getItems() should probably return XmlSchemaChoiceMember instead of XmlSchemaObject. --- Key: XMLSCHEMA-11 URL: https://issues.apache.org/jira/browse/XMLSCHEMA-11 Project: XmlSchema Issue Type: Question Affects Versions: XmlSchema 2.0 Environment: Java :-) Reporter: Dmitry Repchevsky Priority: Trivial Labels: API, changes Attachments: fnroyOcPjyUASUVORK5CYII= XmlSchemaSequence.getItems() returns XmlSchemaSequenceMember. IMHO XmlSchemaChoice.getItems() should return XmlSchemaChoiceMember. Also XmlSchemaChoiceMember could inherit XmlSchemaObjectBase (as XmlSchemaSequenceMember does), so both XmlSchemaSequence.getItems() and XmlSchemaChoice.getItems() will return XmlSchemaObjectBase type that facilitates parsing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (XMLSCHEMA-3) DefaultURIResolver doesn't resolve JAR style URLs properly
[ https://issues.apache.org/jira/browse/XMLSCHEMA-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved XMLSCHEMA-3. - Resolution: Fixed Fix Version/s: XmlSchema 2.1 DefaultURIResolver doesn't resolve JAR style URLs properly -- Key: XMLSCHEMA-3 URL: https://issues.apache.org/jira/browse/XMLSCHEMA-3 Project: XmlSchema Issue Type: Bug Affects Versions: XmlSchema 1.4.2, XmlSchema 1.4.6 Reporter: Andreas Veithen Priority: Minor Fix For: XmlSchema 2.1, XmlSchema 1.4.8 DefaultURIResolver is unable to resolve entities against a base URI of the following form: jar:file:/D:/data/my.jar!/package/schema.xsd The reason is that resolveEntity uses java.net.URI: the URI is opaque and java.net.URI doesn't resolve relative URIs against opaque URIs. The original version of DefaultURIResolver (r396478) used java.net.URL and worked perfectly in that case. This was broken in r400374. The impact of this issue is that it is not possible to load schemas from the classpath, if they have imports and DefaultURIResolver is used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-257) Respect semicolon continuation characters of HTTP Headers
[ https://issues.apache.org/jira/browse/AXIOM-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-257: -- Fix Version/s: 1.2.8 Updated fix version based on SVN history. Respect semicolon continuation characters of HTTP Headers - Key: AXIOM-257 URL: https://issues.apache.org/jira/browse/AXIOM-257 Project: Axiom Issue Type: Bug Reporter: Rich Scheuerle Assignee: Rich Scheuerle Fix For: 1.2.8 Problem Summary: The PartFactory code reads the HTTP headers. However it does not correctly parse ;. A semicolon is an indication that the value is continued on the next line. This is a simple fix, I am adding the code and test. Kudos to Mark Welesko and Jay Witherspoon for surfacing and recreating this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-257) Respect semicolon continuation characters of HTTP Headers
[ https://issues.apache.org/jira/browse/AXIOM-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13039893#comment-13039893 ] Andreas Veithen commented on AXIOM-257: --- Rich, Which part of the MIME spec actually defines ; as a continuation character? Respect semicolon continuation characters of HTTP Headers - Key: AXIOM-257 URL: https://issues.apache.org/jira/browse/AXIOM-257 Project: Axiom Issue Type: Bug Reporter: Rich Scheuerle Assignee: Rich Scheuerle Fix For: 1.2.8 Problem Summary: The PartFactory code reads the HTTP headers. However it does not correctly parse ;. A semicolon is an indication that the value is continued on the next line. This is a simple fix, I am adding the code and test. Kudos to Mark Welesko and Jay Witherspoon for surfacing and recreating this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-280) Add access to the Content Transfer Encoding value from DataHandler
[ https://issues.apache.org/jira/browse/AXIOM-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13046728#comment-13046728 ] Andreas Veithen commented on AXIOM-280: --- For a similar request, see: http://markmail.org/thread/omk4bgihxo4xmez7 Add access to the Content Transfer Encoding value from DataHandler -- Key: AXIOM-280 URL: https://issues.apache.org/jira/browse/AXIOM-280 Project: Axiom Issue Type: Improvement Components: API Affects Versions: 1.2.8 Reporter: Tim Mitchell Assignee: Andreas Veithen Fix For: 1.2.12 Attachments: ContentTransferEncodingDiff.txt We have a need to be able to identify how an SWA attachment was encoded in the message, by accessing the Content Transfer Encoding. Currently the DataHandler does contain this info, but there is no method you can use to get to the data. I have created a fix and an accompanying testcase. Please could you review the changes and if you're happy please could you integrate the fix. I intend to post on the Axiom mailing list to broadcast my suggestion. I've attached the diff details as an attachment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (WSS-293) Getting exception when rampart is engaged without addressing at client side
[ https://issues.apache.org/jira/browse/WSS-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13046746#comment-13046746 ] Andreas Veithen commented on WSS-293: - Yes, this issue should be moved to Rampart. Either Rampart needs to make sure that the message already has a SOAPHeader element before invoking WSS4J, or Axiom DOOM would have to be modified to work like SAAJ (which converts the plain Element to a SOAPHeader on the fly when necessary). Getting exception when rampart is engaged without addressing at client side --- Key: WSS-293 URL: https://issues.apache.org/jira/browse/WSS-293 Project: WSS4J Issue Type: Bug Components: WSS4J Core Affects Versions: 1.5.10 Environment: windows Reporter: shivendra tripathi Assignee: Colm O hEigeartaigh Steps to reproduce: 1. Engage rampart and use policy based configuarion 2. Don't engage any other module like addressing 3. Use OperationClient at client side and create soap envelope as follows SOAPEnvelope envelope = soapFactory.createSOAPEnvelope();// don't use soapFactory.getDefaultEnvelope() to create soap envelope SOAPBody sb = soapFactory.createSOAPBody(envelope); On execution following exception is thrown, since WSS4J is inserting the header which is instance of OMElement and not of SOAPHeader. Caused by: org.apache.rampart.RampartException: Error in extracting message properties at org.apache.rampart.RampartMessageData.init(RampartMessageData.java:389) at org.apache.rampart.MessageBuilder.build(MessageBuilder.java:61) at org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:64) ... 59 more Caused by: org.apache.axiom.soap.SOAPProcessingException: SOAP Envelope can not have children other than SOAP Header and Body at org.apache.axiom.soap.impl.dom.SOAPEnvelopeImpl.checkChild(SOAPEnvelopeImpl.java:110) at org.apache.axiom.soap.impl.dom.SOAPEnvelopeImpl.insertBefore(SOAPEnvelopeImpl.java:164) at org.apache.ws.security.util.WSSecurityUtil.prependChildElement(WSSecurityUtil.java:646) at org.apache.ws.security.util.WSSecurityUtil.findWsseSecurityHeaderBlock(WSSecurityUtil.java:722) at org.apache.ws.security.message.WSSecHeader.insertSecurityHeader(WSSecHeader.java:146) at org.apache.rampart.RampartMessageData.init(RampartMessageData.java:379) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (AXIOM-365) Add ConcurrentModificationException support to iterators
Add ConcurrentModificationException support to iterators Key: AXIOM-365 URL: https://issues.apache.org/jira/browse/AXIOM-365 Project: Axiom Issue Type: Improvement Affects Versions: 1.2.11 Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.12 As explained in the user guide [1], the behavior of iterators returned by methods such as OMContainer#getChildren() slightly changed in Axiom 1.2.10 (see AXIOM-333). This may cause subtle issues (such as AXIS2-5071) which are difficult to detect. The Iterator implementations should be improved such that a ConcurrentModificationException is thrown if the current node is removed, exactly as the iterators of the Java 2 collection framework (java.util) do. [1] http://ws.apache.org/axiom/userguide/ch04.html#iterator-changes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-365) Add ConcurrentModificationException support to iterators
[ https://issues.apache.org/jira/browse/AXIOM-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-365. --- Resolution: Fixed Add ConcurrentModificationException support to iterators Key: AXIOM-365 URL: https://issues.apache.org/jira/browse/AXIOM-365 Project: Axiom Issue Type: Improvement Affects Versions: 1.2.11 Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.12 As explained in the user guide [1], the behavior of iterators returned by methods such as OMContainer#getChildren() slightly changed in Axiom 1.2.10 (see AXIOM-333). This may cause subtle issues (such as AXIS2-5071) which are difficult to detect. The Iterator implementations should be improved such that a ConcurrentModificationException is thrown if the current node is removed, exactly as the iterators of the Java 2 collection framework (java.util) do. [1] http://ws.apache.org/axiom/userguide/ch04.html#iterator-changes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-365) Add ConcurrentModificationException support to iterators
[ https://issues.apache.org/jira/browse/AXIOM-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13053464#comment-13053464 ] Andreas Veithen commented on AXIOM-365: --- Done. Thanks for pointing this out. Add ConcurrentModificationException support to iterators Key: AXIOM-365 URL: https://issues.apache.org/jira/browse/AXIOM-365 Project: Axiom Issue Type: Improvement Affects Versions: 1.2.11 Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.12 As explained in the user guide [1], the behavior of iterators returned by methods such as OMContainer#getChildren() slightly changed in Axiom 1.2.10 (see AXIOM-333). This may cause subtle issues (such as AXIS2-5071) which are difficult to detect. The Iterator implementations should be improved such that a ConcurrentModificationException is thrown if the current node is removed, exactly as the iterators of the Java 2 collection framework (java.util) do. [1] http://ws.apache.org/axiom/userguide/ch04.html#iterator-changes -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-350) Clean up the org.apache.axiom.attachments.Part interface
[ https://issues.apache.org/jira/browse/AXIOM-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-350: -- Fix Version/s: (was: 1.2.12) 1.2.13 Clean up the org.apache.axiom.attachments.Part interface Key: AXIOM-350 URL: https://issues.apache.org/jira/browse/AXIOM-350 Project: Axiom Issue Type: Task Components: API Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.13 Currently, the Part interface is only used internally by Axiom. This can be seen from the current Javadoc [1] (note that Part is used by PartFactory, which is also only used internally [2]). Therefore the Part interface is not really part of the public API and modifying it would only impact code that uses Part and PartFactory independently from the rest of the Axiom API, which is a highly unlikely case. In order to solve AXIOM-31 and AXIOM-280, it is proposed to expose the Part instances via the Attachments object. This is also necessary to make the SAAJ implementation in Axis2 complete, because SAAJ defines methods to access the headers of a MIME part, and this is not possible with the current Axiom API. Exposing the Part instances via the Attachments object will make the Part interface part of the public API. Before doing this, we should clean up this interface a bit. In particular, we should eliminate its dependency on the JavaMail API (usage of javax.mail.MessagingException by all methods and usage of javax.mail.Header as a return value of getAllHeaders). [1] http://ws.apache.org/axiom/apidocs/org/apache/axiom/attachments/class-use/Part.html [2] http://ws.apache.org/axiom/apidocs/org/apache/axiom/attachments/impl/class-use/PartFactory.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-320) Allow StAXSOAPModelBuilder to fallback to XML infoset if the document is not SOAP
[ https://issues.apache.org/jira/browse/AXIOM-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-320: -- Fix Version/s: (was: 1.2.12) Allow StAXSOAPModelBuilder to fallback to XML infoset if the document is not SOAP - Key: AXIOM-320 URL: https://issues.apache.org/jira/browse/AXIOM-320 Project: Axiom Issue Type: Improvement Reporter: Andreas Veithen Priority: Minor Currently, StAXOMBuilder can only be used to build an XML infoset, while StAXSOAPModelBuilder can only be used to build a SOAP infoset model. However in some cases it is impossible to determine beforehand whether a document or message is SOAP or plain XML. To handle this case with the current version of Axiom, the only available strategy is to start processing the document with one of the two builders and restart the processing with the other if the document doesn't match the type of builder. The proposal is to modify StAXSOAPModelBuilder so that it (optionally) falls back to plain XML if it detects that the document element is not a SOAP envelope. This should be feasible since StAXSOAPModelBuilder extends StAXOMBuilder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-61) saveOnFile=true will alter attachments
[ https://issues.apache.org/jira/browse/AXIOM-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-61: - Fix Version/s: (was: 1.2.12) 1.2.13 saveOnFile=true will alter attachments -- Key: AXIOM-61 URL: https://issues.apache.org/jira/browse/AXIOM-61 Project: Axiom Issue Type: Bug Affects Versions: 1.2.8 Environment: Java 1.5 Reporter: Lorenzo Priority: Minor Fix For: 1.2.13 Attachments: TESTWithAttachments.zip Hi all, working with SWA messages i found this strange error: i build messages with attachment with saveAttachmentsOnFile option set true when i write the message back, attachments are modified... If i try with saveAttachmentsOnFile at false, it works fine. The really strange thing is how attachments are changed... hard to explain, just run the test. Lorenzo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-311: -- Fix Version/s: (was: 1.2.12) 1.2.13 Improve the Axiom test suite Key: AXIOM-311 URL: https://issues.apache.org/jira/browse/AXIOM-311 Project: Axiom Issue Type: Improvement Reporter: Andreas Veithen Fix For: 1.2.13 axiom-tests contains a rich set of unit tests, but things could still be improved by applying a common set of tests to both LLOM and DOOM. Indeed the test coverage of DOOM is much lower than that of LLOM. I already refactored some of the tests so that they are applied to both OM implementations, but we should push things further. One specific problem is that since all tests are in a common Maven module which depends on both axiom-impl and axiom-dom, it happens that some DOOM tests accidentally use the LLOM implementation (which is the default). This could be avoided by moving the tests out of axiom-tests into the axiom-api, axiom-impl and axiom-dom. Looking at the description in axiom-tests/pom.xml, It seems that this was actually the original intention: [quote] The Axiom test suite. This ought to be split into several parts and be made a part of axiom-api, axiom-impl and axiom-dom. However, that's not as easy as it seems. The intention is to start with axiom-test and continuosly move parts to the actual projects. [/quote] It is indeed true that this is not as easy as it seems. I can see the following difficulties: 1) In Maven, the fact that module B depends on module A doesn't imply that the unit tests of module B can refer to code in the unit tests of module A. If we want to avoid creating new modules for the test code shared among several other modules, we need to get around this problem. We had the same issue in Synapse and it can be solved by using the test-jar goal in maven-jar-plugin which attaches a JAR with the unit test code. It is then sufficient to add this as a dependency (in scope test) to the other modules. 2) We not only need to split the code, but also the test messages and documents in axiom-tests/test-resources. As with the code, some of these documents would be used by several modules. The problem here is that the tests don't access them as classpath resources but as files (see AbstractTestCase). If we change that, i.e. if we load them using Class#getResourceAsStream, then the solution for item 1 will also solves this problem. But maybe there is a particular reason why AbstractTestCase uses file access? 3) Currently axiom-tests overrides the JavaMail dependency of axiom-api (see WSCOMMONS-417). If we move the tests to the module to which they apply, we can no longer do this, but I think it is a bad practice anyway. Does anyone see other difficulties that block us from splitting axiom-tests? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-28) OMElement.declareDefaultNamespace() declares empty namespace for child element.
[
https://issues.apache.org/jira/browse/AXIOM-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated AXIOM-28:
-
Fix Version/s: (was: 1.2.12)
1.2.13
OMElement.declareDefaultNamespace() declares empty namespace for child
element.
---
Key: AXIOM-28
URL: https://issues.apache.org/jira/browse/AXIOM-28
Project: Axiom
Issue Type: Bug
Components: LLOM
Affects Versions: 1.2.8
Environment: Microsoft Windows 2003 Server, Java 1.5.0_11. Axis2
version 1.3 (uses AXIOM version 1.2.5).
Reporter: Yechiel Mondrowitz
Assignee: Andreas Veithen
Fix For: 1.2.13
When calling declareDefaultNamespace() on a parent node, AXIOM assignes a
blank namespace on the first level's child element. So if XML is passed to
AXIOM that looks like this:
outerTag
innerTag
node1Hello/node1
node2Hello/node2
/innerTag
/outerTag
And then declareDefaultNamespace() of http://someNamespace; is called on the
outerTag, the resulting XML will be this:
outerTag xmlns=http://someNamespace;
innerTag xmlns=
node1Hello/node1
node2Hello/node2
/innerTag
/outerTag
Notice the xmlns= declared in the innerTag. According to my
understanding of XML namespaces, the innerTag and its child nodes will no
longer belong to the parent namespace of http://someNamespace;, since it
explicitly overrides it with an empty namespace. So innerTag and its child
nodes will in fact not belong to any namespace! Here is a small program to
illustrate:
import org.apache.axiom.om.*;
import org.apache.axiom.om.impl.llom.util.*;
public class Test2 {
public static void main(String [] args) {
try {
String xmlString =
outerTag +
innerTag +
node1Hello/node1 +
node2Hello/node2 +
/innerTag +
/outerTag;
OMElement elem = AXIOMUtil.stringToOM(xmlString);
elem.declareDefaultNamespace(http://someNamespace;);
System.out.println(elem.toString());
}
catch(Exception e) {
e.printStackTrace();
}
}
}
The output of this program is this (I added line breaks in the XML for easier
readability):
outerTag xmlns=http://someNamespace;
innerTag xmlns=
node1Hello/node1
node2Hello/node2
/innerTag
/outerTag
As you can see, the innerTag was assigned xmlns= by AXIOM.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-305) Need OMElement.getNamespaceURI() convenience method
[ https://issues.apache.org/jira/browse/AXIOM-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-305. --- Resolution: Fixed Need OMElement.getNamespaceURI() convenience method --- Key: AXIOM-305 URL: https://issues.apache.org/jira/browse/AXIOM-305 Project: Axiom Issue Type: Improvement Reporter: Glen Daniels Assignee: Andreas Veithen Fix For: 1.2.12 Attachments: patch.txt, patch2.txt It is extremely *in*convenient to constantly have to type element.getNamespace().getNamespaceURI() in order to simply get the String namespace from an OMElement. :) We should add a convenience method OMElement.getNamespaceURI(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-114) Soap envelope rpc-encoded namespace issue
[ https://issues.apache.org/jira/browse/AXIOM-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-114: -- Fix Version/s: (was: 1.2.12) 1.2.13 Soap envelope rpc-encoded namespace issue -- Key: AXIOM-114 URL: https://issues.apache.org/jira/browse/AXIOM-114 Project: Axiom Issue Type: Bug Affects Versions: 1.2.8 Environment: java 1.6 Reporter: Luca Cavanna Fix For: 1.2.13 Attachments: AxiomSoapRpcEncoded.java, AxiomSoapRpcEncodedOMSource.java, soaprequest.xml I have replaced saaj with axiom in my projects to manage soap handling. I have an rpc-encoded soap envelope containing the declarations of soapenv (xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;) and xsi (xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;) namespaces. The first element of the soap body references soapenv in one of his attributes (soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;). Some xml elements in the soap body reference the xsi namespace (xsi:type=soapenc:string) as well. When I try to parse the soap body (extracted from the soap envelope) using JDOM or DOM4J I get a SaxParseException because the soapenv and xsi namespaces are not bound: org.xml.sax.SAXParseException: The prefix soapenv for attribute soapenv:encodingStyle associated with an element type ns1:sendMessage is not bound. Saaj handles correctly the soapenv and and xsi declarations moving them in the soap body; with axiom the soap body contain only the reference to those namespaces and not the declarations. The issue seems to be creating a StAXSource from Axiom payload element (obtained by calling axiomSoapMessage.getSOAPEnvelope().getBody().getFirstElement()); serializing payload calling serialize method namespace are correctly handled, but creating a StAXSource using XMLStreamReader and transforming it to a StreamResult I get an xml not parseable because namespaces are not bound. I have found a workaround transforming the StAXSource in a JDOMResult. The problem rises when you create a StAXSource from an Axiom payload element (calling axiomSoapMessage.getSOAPEnvelope().getBody().getFirstElement()). When you call the serialize method, namespaces are correctly handled; but if you create a StAXSource using an XMLStreamReader and try to transform it to a StreamResult you get the SaxParseException mentioned above. I have found a workaround transforming the StAXSource in a JDOMResult. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-315) Handling of completeness in OMNodes and correct OM Serialization in DOOM impl
[ https://issues.apache.org/jira/browse/AXIOM-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-315: -- Fix Version/s: (was: 1.2.12) 1.2.13 Handling of completeness in OMNodes and correct OM Serialization in DOOM impl - Key: AXIOM-315 URL: https://issues.apache.org/jira/browse/AXIOM-315 Project: Axiom Issue Type: Improvement Components: DOOM Reporter: Eran Chinthaka Assignee: Andreas Veithen Fix For: 1.2.13 Attachments: r443065.diff.txt The bug fixed in WSCOMMONS-96 and WSCOMMONS-97 should be reflected in DOOM implementation as well. I consider this as a post Axiom 1.1 release issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-366) PartFactory uses incorrect algorithm to process folded MIME headers
[ https://issues.apache.org/jira/browse/AXIOM-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-366: -- Fix Version/s: (was: 1.2.12) 1.2.13 PartFactory uses incorrect algorithm to process folded MIME headers --- Key: AXIOM-366 URL: https://issues.apache.org/jira/browse/AXIOM-366 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.11 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 This issue was originally reported here: http://markmail.org/thread/guj44ez5wdnxjobc AXIOM-257 introduced code into PartFactory that interprets ; at the end of a header line as a continuation character, i.e. as an indication that the value is continued on the next line. This however is not compatible with the MIME specification and may cause issues with clients that produce multi-line headers in conformance with the MIME specs. Section 1 of RFC 2045 specifies that: All of the header fields defined in this document are subject to the general syntactic rules for header fields specified in RFC 822. Section 3.1.1 of RFC 822 describes how headers are folded: Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body. For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation; this is called folding. The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may instead be inserted. This means that a multi-line header should not be detected by looking for a semicolon at the end of a line, but by looking for white-space at the beginning of a line. In most cases, the change introduced by AXIOM-257 produces the expected result because for MTOM or SwA messages, the only header that has a significant probability of being folded is the Content-Type header and RFC 822 specifies that: While the standard permits folding wherever linear-white-space is permitted, it is recommended that structured fields [...] limit folding to higher-level syntactic breaks. For the Content-Type header this means that folding will in general occur after a semicolon. However, there are rare cases where the algorithm introduced by AXIOM-257 fails to unfold headers correctly, and the code needs to be fixed to conform to RFC 822. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Work started] (AXIOM-360) OMNodeImpl fails to properly set parent for insertSiblingBefore
[ https://issues.apache.org/jira/browse/AXIOM-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIOM-360 started by Andreas Veithen. OMNodeImpl fails to properly set parent for insertSiblingBefore --- Key: AXIOM-360 URL: https://issues.apache.org/jira/browse/AXIOM-360 Project: Axiom Issue Type: Bug Components: LLOM Affects Versions: 1.2.11 Reporter: Eric Johnson Assignee: Andreas Veithen Fix For: 1.2.12 When attempting to use Axiom with the https://code.google.com/a/apache-extras.org/p/santuario-genxdm/, I noticed a test case that failed after trying to encrypt, then decrypt XML in the same document. Turns out it was failing because the parent OMContainer was not being set properly on the child in OMNodeImpl.insertSiblingBefore(). If you look at OMNodeImpl.insertSiblingAfter(), it has a line: ((OMNodeEx) sibling).setParent(parent); However, insertSiblingBefore() sets the parent differently, and misses the case where there is no previous sibling. I marked this as a major bug, because the only way I see to work around the issue is to write to the OMNodeEx interface, an internal implementation detail. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-360) OMNodeImpl fails to properly set parent for insertSiblingBefore
[ https://issues.apache.org/jira/browse/AXIOM-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-360: -- Fix Version/s: 1.2.12 Assignee: Andreas Veithen OMNodeImpl fails to properly set parent for insertSiblingBefore --- Key: AXIOM-360 URL: https://issues.apache.org/jira/browse/AXIOM-360 Project: Axiom Issue Type: Bug Components: LLOM Affects Versions: 1.2.11 Reporter: Eric Johnson Assignee: Andreas Veithen Fix For: 1.2.12 When attempting to use Axiom with the https://code.google.com/a/apache-extras.org/p/santuario-genxdm/, I noticed a test case that failed after trying to encrypt, then decrypt XML in the same document. Turns out it was failing because the parent OMContainer was not being set properly on the child in OMNodeImpl.insertSiblingBefore(). If you look at OMNodeImpl.insertSiblingAfter(), it has a line: ((OMNodeEx) sibling).setParent(parent); However, insertSiblingBefore() sets the parent differently, and misses the case where there is no previous sibling. I marked this as a major bug, because the only way I see to work around the issue is to write to the OMNodeEx interface, an internal implementation detail. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-361) OMNodeImpl detach, when done on the document element of a document, fails to record the state change on the OMDocumentImpl.
[ https://issues.apache.org/jira/browse/AXIOM-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-361: -- Fix Version/s: 1.2.13 OMNodeImpl detach, when done on the document element of a document, fails to record the state change on the OMDocumentImpl. --- Key: AXIOM-361 URL: https://issues.apache.org/jira/browse/AXIOM-361 Project: Axiom Issue Type: Bug Components: LLOM Affects Versions: 1.2.11 Reporter: Eric Johnson Priority: Minor Fix For: 1.2.13 When doing full document decryption in https://code.google.com/a/apache-extras.org/p/santuario-genxdm/, it is necessary to replace the document element of a document with its decrypted counterpart. However, OMNodeImpl.detach doesn't inform the document that the element has been removed, and the OMDocumentImpl.documentElement still points at the one being detached. When subsequently attempting to add in the newly decrypted form of the element, it fails, asserting that the document already has an element. The work-around here is to specifically check in the case of doing a detach on the element of a document, to set the document element of a document to null. Unfortunately, but do-able without resorting to implementation details. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-353) Need a replacement for OMXMLBuilderFactory
[ https://issues.apache.org/jira/browse/AXIOM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-353: -- Fix Version/s: (was: 1.2.12) 1.2.13 Need a replacement for OMXMLBuilderFactory -- Key: AXIOM-353 URL: https://issues.apache.org/jira/browse/AXIOM-353 Project: Axiom Issue Type: Improvement Components: API Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.13 Historically, org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory was used to create Axiom trees from XML documents (and there are still places in Axis2 where this is used). Unfortunately, this class is located in the wrong package and JAR (it is implementation independent but belongs to LLOM). Nowadays, the standard way to create an Axiom tree is to instantiate StAXOMBuilder or one of its subclasses directly. However, this is not optimal for two reasons: * It implies the assumption that every implementation of the Axiom API necessarily uses StAXOMBuilder. This means that an implementation doesn't have the freedom to provide its own builder implementation (e.g. in order to implement some special optimizations). * StAXOMBuilder belongs to a package which has impl in its name. This tends to blur the distinction between the public API and internal implementation classes. There should be an abstract API for creating builder instances. It should be defined in terms of interfaces (such as OMXMLParserWrapper). OMMetaFactory is a good candidate for this because it is already used to encapsulate an implementation of the Axiom API (there is one implementation of OMMetaFactory for LLOM and one for DOOM). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (NEETHI-9) Errors in XML object model conversions are not handled properly
[ https://issues.apache.org/jira/browse/NEETHI-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060842#comment-13060842 ] Andreas Veithen commented on NEETHI-9: -- I think that this case meets the two criteria for using an unchecked exception: * The exception occurs only if something goes badly wrong (like a missing or incompatible dependency lib). * There is nothing that the calling code could to about the error, except for reporting it to the user. Errors in XML object model conversions are not handled properly --- Key: NEETHI-9 URL: https://issues.apache.org/jira/browse/NEETHI-9 Project: Neethi Issue Type: Bug Affects Versions: 3.0 Reporter: Andreas Veithen Priority: Minor Implementations of Converter#convert return null when an error occurs during conversion. On the other hand, AssertionBuilderFactoryImpl#invokeBuilder doesn't check for a null return value. This means that when an error occurs, a null value is passed to AssertionBuilder#build, which leads to unexpected results. Also, the fact that the implementations of Converter#convert swallow most exceptions makes it hard to debug issues caused by problems during object model conversion. We have two options: 1. Let Converter#convert throw an exception if there is a problem. 2. Add a null check in AssertionBuilderFactoryImpl#invokeBuilder (to solve the first problem) and make sure that exceptions thrown in Converter#convert are logged (to solve the second problem). In this case, we need to agree on the logging API to be used (commons logging or SLF4J). Personally, I prefer option 1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (NEETHI-9) Errors in XML object model conversions are not handled properly
[ https://issues.apache.org/jira/browse/NEETHI-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved NEETHI-9. -- Resolution: Fixed Fix Version/s: 3.0.1 Errors in XML object model conversions are not handled properly --- Key: NEETHI-9 URL: https://issues.apache.org/jira/browse/NEETHI-9 Project: Neethi Issue Type: Bug Affects Versions: 3.0 Reporter: Andreas Veithen Priority: Minor Fix For: 3.0.1 Implementations of Converter#convert return null when an error occurs during conversion. On the other hand, AssertionBuilderFactoryImpl#invokeBuilder doesn't check for a null return value. This means that when an error occurs, a null value is passed to AssertionBuilder#build, which leads to unexpected results. Also, the fact that the implementations of Converter#convert swallow most exceptions makes it hard to debug issues caused by problems during object model conversion. We have two options: 1. Let Converter#convert throw an exception if there is a problem. 2. Add a null check in AssertionBuilderFactoryImpl#invokeBuilder (to solve the first problem) and make sure that exceptions thrown in Converter#convert are logged (to solve the second problem). In this case, we need to agree on the logging API to be used (commons logging or SLF4J). Personally, I prefer option 1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-370) Axiom impl doesn't exports the packages
[ https://issues.apache.org/jira/browse/AXIOM-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-370. --- Resolution: Invalid That is by design. Axiom has an abstract API and axiom-impl is an implementation of that API. Application code must not mess around with these implementation classes and are required to use the API. The case of Abdera is special because it extends the implementation from axiom-impl to create a domain specific XML object model. The correct solution in that case is to embed the axiom-impl JAR into the Abdera OSGi bundle that contains these extensions. Axiom impl doesn't exports the packages --- Key: AXIOM-370 URL: https://issues.apache.org/jira/browse/AXIOM-370 Project: Axiom Issue Type: Improvement Components: LLOM Affects Versions: 1.2.10, 1.2.11, 1.2.12 Reporter: Willem Jiang Attachments: AXIOM-370.patch Since 1.2.9, Axiom impl set the package to be private, it causes the trouble that other lib like abdera complains about it can't find the Class of Axiom impl in OSGi. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-368) org.apache.axiom.soap.impl.dom.SOAPHeaderImpl has unimplemented methods
[ https://issues.apache.org/jira/browse/AXIOM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-368: -- Fix Version/s: 1.2.13 Assignee: Andreas Veithen Summary: org.apache.axiom.soap.impl.dom.SOAPHeaderImpl has unimplemented methods (was: org.apache.axiom.soap.impl.dom.SOAPHeaderImplhas unimplemented methods ) org.apache.axiom.soap.impl.dom.SOAPHeaderImpl has unimplemented methods Key: AXIOM-368 URL: https://issues.apache.org/jira/browse/AXIOM-368 Project: Axiom Issue Type: Bug Components: DOOM Affects Versions: 1.2.11 Environment: axis2 1.5.x and 1.6 using jax-ws/jaxb Reporter: Brett Okken Assignee: Andreas Veithen Fix For: 1.2.13 Attachments: AXIOM-368.patch There are several methods in SOAPHeaderImpl which are not implemented. If the DOOM implementation of axiom is specified, the addressing module of axis will not work. It appears that the implementation of the methods from LLOM will work here as well. I will submit a patch which has that implementation copied into DOOM. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-368) org.apache.axiom.soap.impl.dom.SOAPHeaderImpl has unimplemented methods
[ https://issues.apache.org/jira/browse/AXIOM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-368. --- Resolution: Fixed org.apache.axiom.soap.impl.dom.SOAPHeaderImpl has unimplemented methods Key: AXIOM-368 URL: https://issues.apache.org/jira/browse/AXIOM-368 Project: Axiom Issue Type: Bug Components: DOOM Affects Versions: 1.2.11 Environment: axis2 1.5.x and 1.6 using jax-ws/jaxb Reporter: Brett Okken Assignee: Andreas Veithen Fix For: 1.2.13 Attachments: AXIOM-368.patch There are several methods in SOAPHeaderImpl which are not implemented. If the DOOM implementation of axiom is specified, the addressing module of axis will not work. It appears that the implementation of the methods from LLOM will work here as well. I will submit a patch which has that implementation copied into DOOM. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-316) Axiom based XML Security Implemenation
[ https://issues.apache.org/jira/browse/AXIOM-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-316. --- Resolution: Won't Fix Fix Version/s: (was: 1.3) This will probably never be included in the Axiom code base. Reasons: * This JIRA issue is stalled for more than two years and there is obviously no longer any interest of the authors to integrate that code into Axiom (and to maintain it). * In contrast to what has been claimed in one of the previous comments, the code is clearly a fork of the Santuario project (org.apache.xml.security). Although there is no legal issue with that, for obvious reasons we would have to discuss that with the Santuario folks before adding the code to Axiom. * In order to have a full Axiom-only WS-Security implementation in Axis2, one would also have to fork WSS4J. [1] explains why this is not a good approach. [1] http://markmail.org/thread/nomij6tx66fqwad2 Axiom based XML Security Implemenation -- Key: AXIOM-316 URL: https://issues.apache.org/jira/browse/AXIOM-316 Project: Axiom Issue Type: Improvement Reporter: Saliya Ekanayake Assignee: Nandana Mihindukulasooriya Attachments: thomara.zip, thomara_updated.zip Apache Axis2 has proven its performance over other Web services engines over the past couple of years. Its success mainly comes through the usage of Apache Axiom, which is an XML infoset model based on the StAX API. Axis2, however, handles Web services security by means of the Apache Rampart which in turn depends on DOM based implementations of XML security and WS-Security. The main deficiency of this is the performance loss due to object model conversion. Therefore, it is mandatory to come up with an Axiom based security implementation to regain the performance of Axis2 in the case of handling secured messages. The zip file included in the JIRA contains a completely Axiom based implementation of XML Security which implements the following two specifications. 1. XML Encryption Syntax and Processing at http://www.w3.org/TR/xmlenc-core/ 2. XML Signature Syntax and Processing (Second Edition) at http://www.w3.org/TR/xmldsig-core/ Thus, it would be useful for the Apache community and for others who use Axis2 to have this code under Apache. A WS-Security implementation based on Axiom could follow up on top of this afterwards to fulfi the requirement of an Axiom based security implementation. Thanks, Saliya -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-371) Add the version for the Axiom api bundle export package
[ https://issues.apache.org/jira/browse/AXIOM-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13062793#comment-13062793 ] Andreas Veithen commented on AXIOM-371: --- I don't think that it is possible to deploy different versions of the Axiom OSGi bundles into the same container instance. The reason is that each of the implementation bundles (axiom-impl and axiom-dom) registers a service (of type OMMetaFactory) and the axiom-api bundle tracks these services. If multiple versions are deployed, then this will cause inconsistencies. I think that a bundle that exports interfaces implemented by services registered by other bundles should always be a singleton bundle, but (not being an OSGi expert) I may be wrong here. Add the version for the Axiom api bundle export package --- Key: AXIOM-371 URL: https://issues.apache.org/jira/browse/AXIOM-371 Project: Axiom Issue Type: Improvement Components: API Reporter: Willem Jiang Assignee: Andreas Veithen Attachments: AXIOM-371.patch As the Axiom API bundle export package doesn't have version , it cause some trouble when you deploy different version of Axiom API bundle into OSGi container at the same time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (AXIOM-372) Axiom should reject attempts to create illegal namespace declarations
Axiom should reject attempts to create illegal namespace declarations - Key: AXIOM-372 URL: https://issues.apache.org/jira/browse/AXIOM-372 Project: Axiom Issue Type: Bug Components: API, DOOM, LLOM Affects Versions: 1.2.12 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor According to the Namespaces in XML 1.0 (Second Edition) specification, it is illegal to bind a namespace prefix to the empty namespace URI. Only the default namespace can have an empty URI: [Definition: If the attribute name matches PrefixedAttName, then the NCName gives the namespace prefix, used to associate element and attribute names with the namespace name in the attribute value in the scope of the element to which the declaration is attached. In such declarations, the namespace name may not be empty. ] (Note that this constraint was dropped in the Namespaces in XML 1.1 specification) OMElement#declareNamespace doesn't enforce this constraint and namespace declarations that violate this requirement are silently dropped during serialization (by code in OMSerializerUtil#isAssociated). This behavior is problematic because it may result in subtle issues such as unbound namespace prefixes. The serialization code should throw an exception if the object model contains an invalid namespace declaration. We should also make sure that Axiom itself never generates such invalid namespace declarations. Indeed, the code in OMSerializerUtil#isAssociated has the following comment: Cannot associate a prefix with an unqualifed name. However sometimes axiom creates a fake prefix name if xmns= is not in effect. If this is true, then Axiom needs to be fixed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-372) Axiom should reject attempts to create illegal namespace declarations
[ https://issues.apache.org/jira/browse/AXIOM-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068894#comment-13068894 ] Andreas Veithen commented on AXIOM-372: --- Although XML 1.1 allows writing a namespace declaration such as xmlns:p=, this actually doesn't bind the empty namespace name to the prefix, but instead undeclares the prefix, i.e. p is no longer a valid prefix in the scope where this declaration appears. Although the same syntax is used in both cases, adding a namespace declaration to bind a prefix to a (non empty) namespace URI and adding a namespace declaration to undeclare a prefix are two fundamentally different operations from the point of view of the application, and it would make sense to implement them using two different methods. Therefore the proposed solution is as follows: 1. Let OMElement#declareNamespace(String, String) and OMElement#declareNamespace(OMNamespace) throw an exception if an attempt is made to bind the empty namespace name to a prefix (instead of or in addition to throwing an exception in the serialization code). This has the additional advantage of simplifying the identification of code that (accidentally) attempts to create an invalid namespace binding. 2. Add a new method undeclarePrefix(String) to OMElement that allows creating a namespace declaration that undeclares a prefix (and which meant to be used only by XML 1.1 aware code). Axiom should reject attempts to create illegal namespace declarations - Key: AXIOM-372 URL: https://issues.apache.org/jira/browse/AXIOM-372 Project: Axiom Issue Type: Bug Components: API, DOOM, LLOM Affects Versions: 1.2.12 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor According to the Namespaces in XML 1.0 (Second Edition) specification, it is illegal to bind a namespace prefix to the empty namespace URI. Only the default namespace can have an empty URI: [Definition: If the attribute name matches PrefixedAttName, then the NCName gives the namespace prefix, used to associate element and attribute names with the namespace name in the attribute value in the scope of the element to which the declaration is attached. In such declarations, the namespace name may not be empty. ] (Note that this constraint was dropped in the Namespaces in XML 1.1 specification) OMElement#declareNamespace doesn't enforce this constraint and namespace declarations that violate this requirement are silently dropped during serialization (by code in OMSerializerUtil#isAssociated). This behavior is problematic because it may result in subtle issues such as unbound namespace prefixes. The serialization code should throw an exception if the object model contains an invalid namespace declaration. We should also make sure that Axiom itself never generates such invalid namespace declarations. Indeed, the code in OMSerializerUtil#isAssociated has the following comment: Cannot associate a prefix with an unqualifed name. However sometimes axiom creates a fake prefix name if xmns= is not in effect. If this is true, then Axiom needs to be fixed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-372) Axiom should reject attempts to create illegal namespace declarations
[ https://issues.apache.org/jira/browse/AXIOM-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068923#comment-13068923 ] Andreas Veithen commented on AXIOM-372: --- As a corollary of the above, neither XML 1.0 nor XML 1.1 allows creating prefixed elements or attributes with an empty namespace name. When attempting to create such invalid information items, the current behavior of OMFactory is inconsistent: in some cases, the prefix is silently dropped, in other cases the invalid information item is actually created, resulting in problems during serialization. This should be changed so that an exception is thrown by the relevant methods in OMFactory. Axiom should reject attempts to create illegal namespace declarations - Key: AXIOM-372 URL: https://issues.apache.org/jira/browse/AXIOM-372 Project: Axiom Issue Type: Bug Components: API, DOOM, LLOM Affects Versions: 1.2.12 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor According to the Namespaces in XML 1.0 (Second Edition) specification, it is illegal to bind a namespace prefix to the empty namespace URI. Only the default namespace can have an empty URI: [Definition: If the attribute name matches PrefixedAttName, then the NCName gives the namespace prefix, used to associate element and attribute names with the namespace name in the attribute value in the scope of the element to which the declaration is attached. In such declarations, the namespace name may not be empty. ] (Note that this constraint was dropped in the Namespaces in XML 1.1 specification) OMElement#declareNamespace doesn't enforce this constraint and namespace declarations that violate this requirement are silently dropped during serialization (by code in OMSerializerUtil#isAssociated). This behavior is problematic because it may result in subtle issues such as unbound namespace prefixes. The serialization code should throw an exception if the object model contains an invalid namespace declaration. We should also make sure that Axiom itself never generates such invalid namespace declarations. Indeed, the code in OMSerializerUtil#isAssociated has the following comment: Cannot associate a prefix with an unqualifed name. However sometimes axiom creates a fake prefix name if xmns= is not in effect. If this is true, then Axiom needs to be fixed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-373) Generated namespace prefixes not properly used by some OMFactories
[ https://issues.apache.org/jira/browse/AXIOM-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-373: -- Fix Version/s: 1.2.13 Assignee: Andreas Veithen Labels: (was: autogenerated namespaces) Generated namespace prefixes not properly used by some OMFactories -- Key: AXIOM-373 URL: https://issues.apache.org/jira/browse/AXIOM-373 Project: Axiom Issue Type: Bug Components: DOOM Affects Versions: 1.2.10 Reporter: James Grahn Assignee: Andreas Veithen Fix For: 1.2.13 Given this code: OMDOMFactory factory = new OMDOMFactory(); OMElement element = factory.createOMElement(name, ns, null); I expected this output: generatedNamespace:name xmlns:generatedNamespace=ns/ This was the actual output: name xmlns:generatedNamespace=ns xmlns=ns/ While the generated element is within the expected namespace, the output's use of a default namespace where none is necessary is a problem, particularly if you wish to use prefixed elements as frequently as possible. In fact, the generated prefix may never be used as long as the default is available. This problem can be ameliorated in two lines of counter-intuitive code: OMNamespace ns = element.findNamespace(ns, null); element.setNamespace(ns); After running those additional lines of code, the output will match the expectation, but that code is hard to justify. This bug was observed in: OMDOMFactory, DOMSOAPFactory, SOAP11Factory (dom), SOAP12Factory (dom). This bug does not occur in: OMLinkedListImplFactory, SOAP11Factory (llom), SOAP12Factory (llom). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-373) Generated namespace prefixes not properly used by some OMFactories
[ https://issues.apache.org/jira/browse/AXIOM-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-373. --- Resolution: Fixed Generated namespace prefixes not properly used by some OMFactories -- Key: AXIOM-373 URL: https://issues.apache.org/jira/browse/AXIOM-373 Project: Axiom Issue Type: Bug Components: DOOM Affects Versions: 1.2.10 Reporter: James Grahn Assignee: Andreas Veithen Fix For: 1.2.13 Given this code: OMDOMFactory factory = new OMDOMFactory(); OMElement element = factory.createOMElement(name, ns, null); I expected this output: generatedNamespace:name xmlns:generatedNamespace=ns/ This was the actual output: name xmlns:generatedNamespace=ns xmlns=ns/ While the generated element is within the expected namespace, the output's use of a default namespace where none is necessary is a problem, particularly if you wish to use prefixed elements as frequently as possible. In fact, the generated prefix may never be used as long as the default is available. This problem can be ameliorated in two lines of counter-intuitive code: OMNamespace ns = element.findNamespace(ns, null); element.setNamespace(ns); After running those additional lines of code, the output will match the expectation, but that code is hard to justify. This bug was observed in: OMDOMFactory, DOMSOAPFactory, SOAP11Factory (dom), SOAP12Factory (dom). This bug does not occur in: OMLinkedListImplFactory, SOAP11Factory (llom), SOAP12Factory (llom). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-92) Axiom changes the namespce prefix only in the namespace declaration
[
https://issues.apache.org/jira/browse/AXIOM-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved AXIOM-92.
--
Resolution: Fixed
Fix Version/s: 1.2.13
Assignee: Andreas Veithen
This issue has actually been solved by the change to SOAPBuilderHelper in
r1147476.
Axiom changes the namespce prefix only in the namespace declaration
---
Key: AXIOM-92
URL: https://issues.apache.org/jira/browse/AXIOM-92
Project: Axiom
Issue Type: Bug
Reporter: Amila Chinthaka Suriarachchi
Assignee: Andreas Veithen
Fix For: 1.2.13
String xmlString = s:Envelope
xmlns:s=\http://schemas.xmlsoap.org/soap/envelope/\;\n +
s:Body\n +
s:Fault\n +
faultcodes:Client/faultcode\n +
faultstring xml:lang=\en-US\The creator of this
fault did not specify a Reason./faultstring\n +
detail\n +
AppBaseFault i:type=\AppDerivedFault\
xmlns=\http://xwsinterop/soapwsdl/faults\;
xmlns:i=\http://www.w3.org/2001/XMLSchema-instance\;\n +
ErrorInt50/ErrorInt\n +
ErrorStringThis is a test error string for
fault tests./ErrorString\n +
ErrorEmployee\n +
Age30/Age\n +
NameIndigo Developer/Name\n +
HireDate2009-11-17T02:09:48.394-08:00/HireDate\n +
ID12345/ID\n +
Manager\n +
Age50/Age\n +
NameIndigo Developer/Name\n +
HireDate2009-11-17T02:09:48.394-08:00/HireDate\n +
ID34567/ID\n +
Manager i:nil=\true\/\n +
/Manager\n +
/ErrorEmployee\n +
/AppBaseFault\n +
/detail\n +
/s:Fault\n +
/s:Body/s:Envelope;
try {
XMLStreamReader xmlStreamReader =
StAXUtils.createXMLStreamReader(new
ByteArrayInputStream(xmlString.getBytes()));
StAXSOAPModelBuilder builder = new
StAXSOAPModelBuilder(xmlStreamReader);
SOAPEnvelope envelope =
(SOAPEnvelope)builder.getDocumentElement();
XMLStreamReader newReader =
envelope.getBody().getFault().getDetail().getFirstElement().getXMLStreamReaderWithoutCaching();
while (!newReader.isStartElement()){
newReader.next();
}
System.out.println(Element name == + newReader.getName());
System.out.println(type == +
newReader.getAttributeValue(http://www.w3.org/2001/XMLSchema-instance,type;));
System.out.println(Namespace == +
newReader.getNamespaceContext().getNamespaceURI());
System.out.println(Namespace == +
newReader.getNamespaceContext().getNamespaceURI(axis2ns1));
} catch (XMLStreamException e) {
}
This code produce following out put.
lement name == {http://xwsinterop/soapwsdl/faults}AppBaseFault
type == AppDerivedFault
Namespace == null
Namespace == http://xwsinterop/soapwsdl/faults
the namespace prefix has changed to axis2ns1 but type still have the previous
value instead of axis2ns1:AppDerivedFault.
This give an exception at ADB.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (AXIOM-374) Behavior of OMFactory#createOMElement(QName [, OMContainer]) is inconsistent between LLOM and DOOM
Behavior of OMFactory#createOMElement(QName [, OMContainer]) is inconsistent between LLOM and DOOM -- Key: AXIOM-374 URL: https://issues.apache.org/jira/browse/AXIOM-374 Project: Axiom Issue Type: Bug Components: DOOM Affects Versions: 1.2.12 Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.13 The createOMElement(String, OMNamespace), createOMElement(String, OMNamespace, OMContainer) and createOMElement(String, String, String) methods support auto-generating a namespace prefix (by passing a null prefix) and creating an element in the default namespace (by passing an empty string as prefix). This choice doesn't exist for the createOMElement(QName) and createOMElement(QName, OMContainer) methods because the prefix in a QName object can never be null. There is an inconsistency in the behavior of LLOM and DOOM when an empty prefix is passed in the QName object. LLOM will auto-generate a prefix, while DOOM will create an element in the default namespace. In the case of DOOM, this appears to be a bug because the corresponding createOMElement method contains the following condition: qname.getPrefix() != null However, the return value of QName#getPrefix() is never null, and the code that would auto-generate a prefix is unreachable. On the other hand, the desired behavior depends on the use case, and there are situations where one would like to create an element in the default namespace if the prefix in the QName is an empty string. Proposed solution: 1. Make sure that DOOM has the same behavior as LLOM, i.e. auto-generate a prefix if QName#getPrefix() returns an empty string. 2. Add additional methods to OMFactory that create an element from a QName, but that allow to specify the intended behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-75) Namespace declaration cannot be removed from OMElement
[ https://issues.apache.org/jira/browse/AXIOM-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-75. -- Resolution: Fixed Fix Version/s: (was: 1.3) 1.2.13 Assignee: Andreas Veithen This can actually be done by using Iterator#remove() on the iterator returned by getAllDeclaredNamespaces(). This has always worked, but is now officially supported (i.e. it is explicitly mentioned in the Javadoc) and I've added a test case for this. Namespace declaration cannot be removed from OMElement -- Key: AXIOM-75 URL: https://issues.apache.org/jira/browse/AXIOM-75 Project: Axiom Issue Type: Bug Environment: Windows Reporter: Toshiro Takase Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 Once an useless namespace declaration is declared to an OMElement, the namespace declaration cannot be removed forever. In DOM, we can remove namespace declarations by using Element.removeAttribute() . But, in AXIOM, we cannot remove namespace declarations by OMElement.removeAttribute() . Maybe, we need OMElement.removeDeclaredNamespace() ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-377) When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream
[ https://issues.apache.org/jira/browse/AXIOM-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071656#comment-13071656 ] Andreas Veithen commented on AXIOM-377: --- The proposed change would only work in a very limited set of scenarios. In particular for XOP/MTOM it is only guaranteed to work in scenarios where the message has a single element of type base64binary. In cases where there are multiple optimized elements, Axiom would not be able to make sure that the message can be serialized successfully. That is because of the following requirement in the XOP specs: Except for purposes of determining the root MIME part, as specified by [RFC 2387], ordering of MIME parts MUST NOT be considered significant to XOP processing or to the construction of the XOP Infoset. We need to think more carefully about this to come up with a solution that covers all reasonable scenarios. When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream -- Key: AXIOM-377 URL: https://issues.apache.org/jira/browse/AXIOM-377 Project: Axiom Issue Type: New Feature Reporter: Sadeep Jayasumana Attachments: AXIOM-377.patch This feature is particularly useful when large attachments are used. Building large attachments in memory drives the system OOM and building them on files dramatically reduces performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-377) When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream
[ https://issues.apache.org/jira/browse/AXIOM-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071713#comment-13071713 ] Andreas Veithen commented on AXIOM-377: --- A couple of things that might be interesting to take into account while thinking about this issue: * As noted in AXIOM-350, the Part/PartFactory stuff is actually not part of the public API. Therefore we could do some refactoring in that part of the code without breaking things for application code. * We may reconsider AXIOM-326. The James project recently released mime4j 0.7 and it supports pull style parsing of MIME messages. One of the problems with the current MIME code in Axiom is that it is very complex. If we get rid of that code and use mime4j instead, then this will probably make it easier to implement more sophisticated optimizations. When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream -- Key: AXIOM-377 URL: https://issues.apache.org/jira/browse/AXIOM-377 Project: Axiom Issue Type: New Feature Reporter: Sadeep Jayasumana Attachments: AXIOM-377.patch This feature is particularly useful when large attachments are used. Building large attachments in memory drives the system OOM and building them on files dramatically reduces performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Reopened] (AXIOM-326) MIME message parser and serializer based on Apache mime4j
[ https://issues.apache.org/jira/browse/AXIOM-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen reopened AXIOM-326: --- The James project recently announced the release of mime4j 0.7. It now supports pull parsing and has a mode to enforce strict MIME parsing (which is appropriate for MTOM and SwA). It is therefore a good candidate to replace our custom MIME parsing code. This would make it easier for us to solve issues such as AXIOM-61 and AXIOM-366. Not having to maintain our own MIME parser would also free resources to concentrate on higher level features such as AXIOM-377. [1] http://markmail.org/thread/2mudnp4yys37abri MIME message parser and serializer based on Apache mime4j - Key: AXIOM-326 URL: https://issues.apache.org/jira/browse/AXIOM-326 Project: Axiom Issue Type: Improvement Reporter: Oleg Kalnichevski MIME message parser and serializer based on Apache mime4j -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-377) When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream
[ https://issues.apache.org/jira/browse/AXIOM-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073157#comment-13073157 ] Andreas Veithen commented on AXIOM-377: --- AXIOM-329 expressed a similar requirement and introduced a change that enabled streaming in another very specific scenario. Referring to the discussion in [1], I think it is fair to say that we don't make Axiom a good framework by implementing multiple features for the same requirement, but with each one covering a tiny set of scenarios. [1] http://markmail.org/thread/zuagl2pzzdyramvw When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream -- Key: AXIOM-377 URL: https://issues.apache.org/jira/browse/AXIOM-377 Project: Axiom Issue Type: New Feature Reporter: Sadeep Jayasumana Attachments: AXIOM-377.patch This feature is particularly useful when large attachments are used. Building large attachments in memory drives the system OOM and building them on files dramatically reduces performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-326) MIME message parser and serializer based on Apache mime4j
[ https://issues.apache.org/jira/browse/AXIOM-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073158#comment-13073158 ] Andreas Veithen commented on AXIOM-326: --- I think that it is possible to replace our custom MIME parsing code with mime4j without breaking any existing public APIs, with one (potential) exception, namely Attachments#getIncomingAttachmentsAsSingleStream(). Probably once we hand over the input stream to mime4j it will probably (to be confirmed) no longer be possible to give access to that stream in a well defined state. The reason is that we have no control over how much buffering mime4j does. However: * I didn't find a single piece of code that is using getIncomingAttachmentsAsSingleStream(). * The method was introduced by AXIOM-329, but that use case should be covered by a proper solution for AXIOM-377 (which in turn depends on the present issue). Therefore it is reasonable to sacrifice getIncomingAttachmentsAsSingleStream (if necessary). MIME message parser and serializer based on Apache mime4j - Key: AXIOM-326 URL: https://issues.apache.org/jira/browse/AXIOM-326 Project: Axiom Issue Type: Improvement Reporter: Oleg Kalnichevski MIME message parser and serializer based on Apache mime4j -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Issue Comment Edited] (AXIOM-326) MIME message parser and serializer based on Apache mime4j
[ https://issues.apache.org/jira/browse/AXIOM-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073158#comment-13073158 ] Andreas Veithen edited comment on AXIOM-326 at 7/30/11 2:33 PM: I think that it is possible to replace our custom MIME parsing code with mime4j without breaking any existing public APIs, with one (potential) exception, namely Attachments#getIncomingAttachmentsAsSingleStream(). Probably once we hand over the input stream to mime4j it will probably (to be confirmed) no longer be possible to give access to that stream in a well defined state. The reason is that we have no control over how much buffering mime4j does. However: * I didn't find a single piece of code that is using getIncomingAttachmentsAsSingleStream(). * The method was introduced by AXIOM-329, but that use case should be covered by a proper solution for AXIOM-377 (which in turn depends on the present issue). * The method is not covered by any test case, so that we are even not sure that it still works as designed. Therefore it is reasonable to sacrifice getIncomingAttachmentsAsSingleStream (if necessary). was (Author: veithen): I think that it is possible to replace our custom MIME parsing code with mime4j without breaking any existing public APIs, with one (potential) exception, namely Attachments#getIncomingAttachmentsAsSingleStream(). Probably once we hand over the input stream to mime4j it will probably (to be confirmed) no longer be possible to give access to that stream in a well defined state. The reason is that we have no control over how much buffering mime4j does. However: * I didn't find a single piece of code that is using getIncomingAttachmentsAsSingleStream(). * The method was introduced by AXIOM-329, but that use case should be covered by a proper solution for AXIOM-377 (which in turn depends on the present issue). Therefore it is reasonable to sacrifice getIncomingAttachmentsAsSingleStream (if necessary). MIME message parser and serializer based on Apache mime4j - Key: AXIOM-326 URL: https://issues.apache.org/jira/browse/AXIOM-326 Project: Axiom Issue Type: Improvement Reporter: Oleg Kalnichevski MIME message parser and serializer based on Apache mime4j -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-379) Attachments buffered using files are not decoded
[ https://issues.apache.org/jira/browse/AXIOM-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-379. --- Resolution: Fixed Attachments buffered using files are not decoded Key: AXIOM-379 URL: https://issues.apache.org/jira/browse/AXIOM-379 Project: Axiom Issue Type: Bug Affects Versions: 1.2.12 Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.13 When PartOnFile is used (i.e. when the length is above the threshold and a file is used to buffer the attachment) and the attachment uses a Content-Transfer-Encoding other than binary, then the input stream returned by the corresponding DataHandler is incorrect. It represents the raw content of the attachment, but it should be the decoded content. This only occurs with PartOnFile; PartOnMemory(Enhanced) works correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-377) When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream
[ https://issues.apache.org/jira/browse/AXIOM-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079070#comment-13079070 ] Andreas Veithen commented on AXIOM-377: --- Here is the current plan: Attachments should return DataHandler instances that expose an interface similar to the StreamingDataHandler class used in the JAX-WS reference implementation, in particular the following method: InputStream readOnce(); This would allow application code to request the attachment to be streamed. This would also be used when an MTOM message is serialized using serializeAndConsume. In all other cases (access using the standard DataHandler methods; multiple attachments that are not accessed sequentially), the attachment would be buffered so that streaming unaware application code will continue to work as usual. It also means that streaming doesn't require any additional configuration. In principle this is almost trivial to implement. However, there are a couple of constraints related to existing code that need to be taken into account: * Axiom already defines various custom DataHandler and DataSource implementations/extensions such as CachedFileDataSource and DataHandlerExt. We need to make sure that we continue to support them if we determine that they are still necessary. * All accesses to temporary files happen through LifecycleManager/FileAccessor. FileAccessor currently also acts as a factory for DataHandler objects for attachments buffered on disk. This is a problem because we need to create DataHandler instances that support streaming, but streaming is not a concern of FileAccessor. For most of the code related to these classes, unit test coverage is insufficient or non existing (in particular for the changes in AXIOM-269) [We should forbid committing any code not covered by unit tests :-(]. Therefore we first need to write a couple of unit tests that allow us to ensure non regression for the features we want to preserve. Note that the solution is suboptimal (but works) in the following scenarios (where Sadeep's patch would simply fail): * MTOM + data binding + multiple attachments: only the last attachment can be streamed because the data binding requests all DataHandler objects before invoking the service, which means that all attachments except the last one will be buffered * forwarding an MTOM message where the attachments are in a different order than the xop:Include elements referencing them: in this case, the order in which the serializer requests the data handlers doesn't allow streaming of all attachments When a multipart message is built, there should be a way to retrieve a DataHandler to the MTOM part without reading the entire incoming stream -- Key: AXIOM-377 URL: https://issues.apache.org/jira/browse/AXIOM-377 Project: Axiom Issue Type: New Feature Reporter: Sadeep Jayasumana Assignee: Andreas Veithen Attachments: AXIOM-377.patch This feature is particularly useful when large attachments are used. Building large attachments in memory drives the system OOM and building them on files dramatically reduces performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (AXIOM-381) DataHandlerExt#deleteWhenReadOnce() doesn't work as specified
DataHandlerExt#deleteWhenReadOnce() doesn't work as specified - Key: AXIOM-381 URL: https://issues.apache.org/jira/browse/AXIOM-381 Project: Axiom Issue Type: Bug Affects Versions: 1.2.9 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 The Javadoc of DataHandlerExt#deleteWhenReadOnce() specifies the behavior of the method as follows: This method will give users an option to trigger a delete on temporary attachment file when DataHandler associated with the attachment is read once. [...] This method gives options to user to trigger a delete on attachment files when they read the dataHandler once. This suggests that the deletion of the temporary file is triggered after the stream returned by DataHandler#getInputStream() has been consumed. The code in DataHandlerExtImpl is also designed such that the method can be called before (in which case the file would be deleted after accessing the data) or after accessing the data (in which case the file would be deleted immediately). However, in practice the implementation doesn't work like that. deleteWhenReadOnce() will actually always result in a call to purgeDataSource() and delete the file immediately. The explanation is as follows: - The access counter is kept in FileAccessor and it is incremented every time getDataHandler is called on the FileAccessor. - The DataHandlerExtImpl instance is created by FileAccessor#getDataHandler. This implies that for a given DataHandlerExtImpl object, the access counter in the corresponding FileAccessor is always non zero. - DataHandlerExtImpl#deleteWhenReadOnce() checks the access counter of the FileAccessor and if it is greater than zero, calls purgeDataSource(). This will always occur because at this point the access count can't be zero. The only exception would be for DataHandlerExtImpl instances created directly (i.e. not using FileAccessor#getDataHandler). Axiom internally always uses FileAccessor#getDataHandler and never creates a DataHandlerExtImpl directly. It is also unlikely that any application code creates a DataHandlerExtImpl directly, because the code in DataHandlerExtImpl is very tightly coupled to FileAccessor, LifecycleManager and CachedFileDataSource. It should also be noted that the code in question, which was added by AXIOM-269, has zero unit test coverage. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Work started] (AXIOM-61) saveOnFile=true will alter attachments
[ https://issues.apache.org/jira/browse/AXIOM-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIOM-61 started by Andreas Veithen. saveOnFile=true will alter attachments -- Key: AXIOM-61 URL: https://issues.apache.org/jira/browse/AXIOM-61 Project: Axiom Issue Type: Bug Affects Versions: 1.2.8 Environment: Java 1.5 Reporter: Lorenzo Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 Attachments: TESTWithAttachments.zip Hi all, working with SWA messages i found this strange error: i build messages with attachment with saveAttachmentsOnFile option set true when i write the message back, attachments are modified... If i try with saveAttachmentsOnFile at false, it works fine. The really strange thing is how attachments are changed... hard to explain, just run the test. Lorenzo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Assigned] (AXIOM-61) saveOnFile=true will alter attachments
[ https://issues.apache.org/jira/browse/AXIOM-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen reassigned AXIOM-61: Assignee: Andreas Veithen saveOnFile=true will alter attachments -- Key: AXIOM-61 URL: https://issues.apache.org/jira/browse/AXIOM-61 Project: Axiom Issue Type: Bug Affects Versions: 1.2.8 Environment: Java 1.5 Reporter: Lorenzo Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 Attachments: TESTWithAttachments.zip Hi all, working with SWA messages i found this strange error: i build messages with attachment with saveAttachmentsOnFile option set true when i write the message back, attachments are modified... If i try with saveAttachmentsOnFile at false, it works fine. The really strange thing is how attachments are changed... hard to explain, just run the test. Lorenzo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-61) saveOnFile=true will alter attachments
[ https://issues.apache.org/jira/browse/AXIOM-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-61. -- Resolution: Fixed The issue is actually solved by AXIOM-326. saveOnFile=true will alter attachments -- Key: AXIOM-61 URL: https://issues.apache.org/jira/browse/AXIOM-61 Project: Axiom Issue Type: Bug Affects Versions: 1.2.8 Environment: Java 1.5 Reporter: Lorenzo Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 Attachments: TESTWithAttachments.zip Hi all, working with SWA messages i found this strange error: i build messages with attachment with saveAttachmentsOnFile option set true when i write the message back, attachments are modified... If i try with saveAttachmentsOnFile at false, it works fine. The really strange thing is how attachments are changed... hard to explain, just run the test. Lorenzo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Work started] (AXIOM-380) Error decoding base64Binary
[ https://issues.apache.org/jira/browse/AXIOM-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on AXIOM-380 started by Andreas Veithen. Error decoding base64Binary --- Key: AXIOM-380 URL: https://issues.apache.org/jira/browse/AXIOM-380 Project: Axiom Issue Type: Bug Affects Versions: 1.2.11 Environment: Axis2 1.6.0, Windows 7 Reporter: Dimitar Gospodinov Assignee: Andreas Veithen Fix For: 1.2.13 Recently I upgraded from Axis2 1.4.1 to Axis2 1.6.0. I have a web service with operation Test. One of the Test parameters is of type base64Binary. After upgrading to 1.6.0 Test stopped working - my code did not even get called. Some investigation revealed that the problem is with the base64 data. An error is generated with the following message: javax.xml.stream.XMLStreamException: Error during base64 decoding Digging a bit more revealed that the root cause is: java.io.IOException: Invalid base64 char '\n' at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.decode(AbstractBase64DecodingWriter.java:80) at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.decode(AbstractBase64DecodingWriter.java:91) at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.write(AbstractBase64DecodingWriter.java:66) at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.write(AbstractBase64DecodingWriter.java:57) at java.io.Writer.write(Writer.java:140) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:287) at org.apache.axiom.om.impl.SwitchingWrapper.writeTextTo(SwitchingWrapper.java:466) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:285) at org.apache.axiom.util.stax.XMLStreamReaderUtils.getDataHandlerFromElement(XMLStreamReaderUtils.java:237) ... 23 more The base64 data passed to the web service looks like this(exact snapshot of the HTTP request, with just the first 3 lines shown): data xmlns=MS4wMToxNDIdMS4wMjowMzAwHTEuMDM6MR8wMx4yHzAwHjQfMDEeNB8wMh0xLjA0OlBOUx0xLjA1 OjIwMTEwODAyHTEuMDY6Mh0xLjA3OkZMRkRMRUNWWh0xLjA4OkZMMDM3ODhXMB0xLjA5OjExMDgw MjAwMDcdMS4xMToxOS42OR0xLjEyOjE5LjY5HDIuMDAxOjE4HTIuMDAyOjAwHAAAgngBAAL/ There is \r\n between each line. All this used to work with 1.4.1 and now suddenly stopped with the above error. After some more investigation it turned out that if all \r\n are removed from the data element with the base64 data (basically make the base64 value a single line), everything works Ok. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-380) Error decoding base64Binary
[ https://issues.apache.org/jira/browse/AXIOM-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-380. --- Resolution: Fixed Error decoding base64Binary --- Key: AXIOM-380 URL: https://issues.apache.org/jira/browse/AXIOM-380 Project: Axiom Issue Type: Bug Affects Versions: 1.2.11 Environment: Axis2 1.6.0, Windows 7 Reporter: Dimitar Gospodinov Assignee: Andreas Veithen Fix For: 1.2.13 Recently I upgraded from Axis2 1.4.1 to Axis2 1.6.0. I have a web service with operation Test. One of the Test parameters is of type base64Binary. After upgrading to 1.6.0 Test stopped working - my code did not even get called. Some investigation revealed that the problem is with the base64 data. An error is generated with the following message: javax.xml.stream.XMLStreamException: Error during base64 decoding Digging a bit more revealed that the root cause is: java.io.IOException: Invalid base64 char '\n' at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.decode(AbstractBase64DecodingWriter.java:80) at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.decode(AbstractBase64DecodingWriter.java:91) at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.write(AbstractBase64DecodingWriter.java:66) at org.apache.axiom.util.base64.AbstractBase64DecodingWriter.write(AbstractBase64DecodingWriter.java:57) at java.io.Writer.write(Writer.java:140) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:287) at org.apache.axiom.om.impl.SwitchingWrapper.writeTextTo(SwitchingWrapper.java:466) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:285) at org.apache.axiom.util.stax.XMLStreamReaderUtils.getDataHandlerFromElement(XMLStreamReaderUtils.java:237) ... 23 more The base64 data passed to the web service looks like this(exact snapshot of the HTTP request, with just the first 3 lines shown): data xmlns=MS4wMToxNDIdMS4wMjowMzAwHTEuMDM6MR8wMx4yHzAwHjQfMDEeNB8wMh0xLjA0OlBOUx0xLjA1 OjIwMTEwODAyHTEuMDY6Mh0xLjA3OkZMRkRMRUNWWh0xLjA4OkZMMDM3ODhXMB0xLjA5OjExMDgw MjAwMDcdMS4xMToxOS42OR0xLjEyOjE5LjY5HDIuMDAxOjE4HTIuMDAyOjAwHAAAgngBAAL/ There is \r\n between each line. All this used to work with 1.4.1 and now suddenly stopped with the above error. After some more investigation it turned out that if all \r\n are removed from the data element with the base64 data (basically make the base64 value a single line), everything works Ok. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (AXIOM-382) Class loader leak caused by VMShutdownHook
Class loader leak caused by VMShutdownHook -- Key: AXIOM-382 URL: https://issues.apache.org/jira/browse/AXIOM-382 Project: Axiom Issue Type: Bug Affects Versions: 1.2.12 Reporter: Andreas Veithen The first time an attachment is buffered to file, Axiom automatically registers a shutdown hook to delete the temporary files when the VM is stopped. This shutdown hook is never unregistered. This means that if Axiom is used in a J2EE application, there will be a class loader leak when the application is restarted or redeployed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Deleted] (WSCOMMONS-571) JMSUtils.createConsumer ClassCastException while connecting to JBoss Messaging
[ https://issues.apache.org/jira/browse/WSCOMMONS-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen deleted WSCOMMONS-571: -- JMSUtils.createConsumer ClassCastException while connecting to JBoss Messaging -- Key: WSCOMMONS-571 URL: https://issues.apache.org/jira/browse/WSCOMMONS-571 Project: WS-Commons Issue Type: Bug Environment: Win XP, Eclipse Indigo, web service client(axis2 1.4) with jms transport 1.0, remote server JBoss 4.0.3 SP1 Reporter: Andrey Karandey java.lang.ClassCastException: org.jboss.mq.SpySession at org.apache.axis2.transport.jms.JMSUtils.createConsumer(JMSUtils.java:433) at org.apache.axis2.transport.jms.JMSSender.waitForResponseAndProcess(JMSSender.java:251) at org.apache.axis2.transport.jms.JMSSender.sendOverJMS(JMSSender.java:228) at org.apache.axis2.transport.jms.JMSSender.sendMessage(JMSSender.java:144) at org.apache.axis2.transport.base.AbstractTransportSender.invoke(AbstractTransportSender.java:112) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:435) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:402) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165) ... at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) JMSUtils.createConsumer trying to cast jboss.mq.SpySession to javax.jms.QueueSession, but SpySession doesn`t implement QueueSession. As a result we have ClassCastException. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Updated] (AXIOM-383) MTOM has problems when I create an attachtment from a byte array of zero elements
[ https://issues.apache.org/jira/browse/AXIOM-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated AXIOM-383: -- Affects Version/s: 1.2.5 MTOM has problems when I create an attachtment from a byte array of zero elements - Key: AXIOM-383 URL: https://issues.apache.org/jira/browse/AXIOM-383 Project: Axiom Issue Type: Bug Affects Versions: 1.2.5 Environment: Windows XP SP2, Tomcat 6.0 Reporter: Jorge Fernández Assignee: Rich Scheuerle Fix For: 1.2.6 Attachments: message1.txt If I define a DataHandler from an ByteArrayDataSource and this one from a byte array of zero elements, I get the following exception in the client: org.apache.axis2.AxisFault: Referenced Attachment not found in the MIME Message. ContentID:1.urn:uuid:0549f3f826ec3041861188639371...@apache.org at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) at client.Medici_LinkStub.fromOM(Medici_LinkStub.java:50213) at client.Medici_LinkStub.getSignalData(Medici_LinkStub.java:6500) at client.ClientUtilities.getSignalDataTest(ClientUtilities.java:600) at client.Client.main(Client.java:172) Caused by: org.apache.axiom.om.OMException: Referenced Attachment not found in the MIME Message. ContentID:1.urn:uuid:0549f3f826ec3041861188639371...@apache.org at org.apache.axiom.soap.impl.builder.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:106)Closing session... at client.Medici_LinkStub$ExtDataSegment$Factory.parse(Medici_LinkStub.java:34167) at client.Medici_LinkStub$ExtSignalData$Factory.parse(Medici_LinkStub.java:35862) at client.Medici_LinkStub$GetSignalDataResponse$Factory.parse(Medici_LinkStub.java:8777) at client.Medici_LinkStub.fromOM(Medici_LinkStub.java:49766) ... 3 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Moved] (AXIOM-383) MTOM has problems when I create an attachtment from a byte array of zero elements
[ https://issues.apache.org/jira/browse/AXIOM-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen moved AXIS2-3226 to AXIOM-383: -- Fix Version/s: (was: 1.4) 1.2.6 Key: AXIOM-383 (was: AXIS2-3226) Project: Axiom (was: Axis2) MTOM has problems when I create an attachtment from a byte array of zero elements - Key: AXIOM-383 URL: https://issues.apache.org/jira/browse/AXIOM-383 Project: Axiom Issue Type: Bug Affects Versions: 1.2.5 Environment: Windows XP SP2, Tomcat 6.0 Reporter: Jorge Fernández Assignee: Rich Scheuerle Fix For: 1.2.6 Attachments: message1.txt If I define a DataHandler from an ByteArrayDataSource and this one from a byte array of zero elements, I get the following exception in the client: org.apache.axis2.AxisFault: Referenced Attachment not found in the MIME Message. ContentID:1.urn:uuid:0549f3f826ec3041861188639371...@apache.org at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) at client.Medici_LinkStub.fromOM(Medici_LinkStub.java:50213) at client.Medici_LinkStub.getSignalData(Medici_LinkStub.java:6500) at client.ClientUtilities.getSignalDataTest(ClientUtilities.java:600) at client.Client.main(Client.java:172) Caused by: org.apache.axiom.om.OMException: Referenced Attachment not found in the MIME Message. ContentID:1.urn:uuid:0549f3f826ec3041861188639371...@apache.org at org.apache.axiom.soap.impl.builder.MTOMStAXSOAPModelBuilder.getDataHandler(MTOMStAXSOAPModelBuilder.java:106)Closing session... at client.Medici_LinkStub$ExtDataSegment$Factory.parse(Medici_LinkStub.java:34167) at client.Medici_LinkStub$ExtSignalData$Factory.parse(Medici_LinkStub.java:35862) at client.Medici_LinkStub$GetSignalDataResponse$Factory.parse(Medici_LinkStub.java:8777) at client.Medici_LinkStub.fromOM(Medici_LinkStub.java:49766) ... 3 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (WSS-312) Improve logging levels
[ https://issues.apache.org/jira/browse/WSS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088731#comment-13088731 ] Andreas Veithen commented on WSS-312: - I fully agree with Dan's comment. This is indeed an anti-pattern. Improve logging levels -- Key: WSS-312 URL: https://issues.apache.org/jira/browse/WSS-312 Project: WSS4J Issue Type: Improvement Components: WSS4J Core Affects Versions: 1.6.2 Reporter: Anubhav Sharma Assignee: Colm O hEigeartaigh Priority: Minor Fix For: 1.6.3 Attachments: 0001-Improved-logging-levels.patch In the source code at most of the places where exception is thrown, exception is logged at debug level. Ideally it should be at warn or error level. This would improve overall logging in the library. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-381) DataHandlerExt#deleteWhenReadOnce() doesn't work as specified
[ https://issues.apache.org/jira/browse/AXIOM-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-381. --- Resolution: Fixed DataHandlerExt#deleteWhenReadOnce() doesn't work as specified - Key: AXIOM-381 URL: https://issues.apache.org/jira/browse/AXIOM-381 Project: Axiom Issue Type: Bug Affects Versions: 1.2.9 Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 The Javadoc of DataHandlerExt#deleteWhenReadOnce() specifies the behavior of the method as follows: This method will give users an option to trigger a delete on temporary attachment file when DataHandler associated with the attachment is read once. [...] This method gives options to user to trigger a delete on attachment files when they read the dataHandler once. This suggests that the deletion of the temporary file is triggered after the stream returned by DataHandler#getInputStream() has been consumed. The code in DataHandlerExtImpl is also designed such that the method can be called before (in which case the file would be deleted after accessing the data) or after accessing the data (in which case the file would be deleted immediately). However, in practice the implementation doesn't work like that. deleteWhenReadOnce() will actually always result in a call to purgeDataSource() and delete the file immediately. The explanation is as follows: - The access counter is kept in FileAccessor and it is incremented every time getDataHandler is called on the FileAccessor. - The DataHandlerExtImpl instance is created by FileAccessor#getDataHandler. This implies that for a given DataHandlerExtImpl object, the access counter in the corresponding FileAccessor is always non zero. - DataHandlerExtImpl#deleteWhenReadOnce() checks the access counter of the FileAccessor and if it is greater than zero, calls purgeDataSource(). This will always occur because at this point the access count can't be zero. The only exception would be for DataHandlerExtImpl instances created directly (i.e. not using FileAccessor#getDataHandler). Axiom internally always uses FileAccessor#getDataHandler and never creates a DataHandlerExtImpl directly. It is also unlikely that any application code creates a DataHandlerExtImpl directly, because the code in DataHandlerExtImpl is very tightly coupled to FileAccessor, LifecycleManager and CachedFileDataSource. It should also be noted that the code in question, which was added by AXIOM-269, has zero unit test coverage. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Resolved] (AXIOM-361) OMNodeImpl detach, when done on the document element of a document, fails to record the state change on the OMDocumentImpl.
[ https://issues.apache.org/jira/browse/AXIOM-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved AXIOM-361. --- Resolution: Fixed Assignee: Andreas Veithen OMNodeImpl detach, when done on the document element of a document, fails to record the state change on the OMDocumentImpl. --- Key: AXIOM-361 URL: https://issues.apache.org/jira/browse/AXIOM-361 Project: Axiom Issue Type: Bug Components: LLOM Affects Versions: 1.2.11 Reporter: Eric Johnson Assignee: Andreas Veithen Priority: Minor Fix For: 1.2.13 When doing full document decryption in https://code.google.com/a/apache-extras.org/p/santuario-genxdm/, it is necessary to replace the document element of a document with its decrypted counterpart. However, OMNodeImpl.detach doesn't inform the document that the element has been removed, and the OMDocumentImpl.documentElement still points at the one being detached. When subsequently attempting to add in the newly decrypted form of the element, it fails, asserting that the document already has an element. The work-around here is to specifically check in the case of doing a detach on the element of a document, to set the document element of a document to null. Unfortunately, but do-able without resorting to implementation details. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Created] (AXIOM-385) DOOM class hierarchy is inconsistent with the Axiom interface hierarchy
DOOM class hierarchy is inconsistent with the Axiom interface hierarchy
---
Key: AXIOM-385
URL: https://issues.apache.org/jira/browse/AXIOM-385
Project: Axiom
Issue Type: Bug
Components: DOOM
Affects Versions: 1.2.12
Reporter: Andreas Veithen
The OMDocument interface extends OMContainer, but not OMNode. On the other
hand, DocumentImpl implements both OMDocument and OMNode (because it extends
NodeImpl which implements OMNode).
That causes problems with code such as this (which is perfectly consistent with
the Axiom API and which works correctly with the LLOM implementation):
if (item instanceof OMNode) {
...
OMContainer parent = ((OMNode)item).getParent();
...
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-386) Axiom add unparsable namespace elements when there is an empty namespace in an XML message
[ https://issues.apache.org/jira/browse/AXIOM-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095921#comment-13095921 ] Andreas Veithen commented on AXIOM-386: --- I believe that this was fixed by r1147476. Can you test this scenario with 1.2.13-SNAPSHOT? Axiom add unparsable namespace elements when there is an empty namespace in an XML message -- Key: AXIOM-386 URL: https://issues.apache.org/jira/browse/AXIOM-386 Project: Axiom Issue Type: Bug Components: API Affects Versions: 1.2.9 Environment: Ubuntu, Linux Reporter: Amila Jayasekara Labels: security Attachments: AXIOM-386.patch, saxparsertest.zip I have following XML, ?xml version='1.0' encoding='utf-8'?soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xenc=http://www.w3.org/2001/04/xmlenc#; soapenv:Body xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd; wsu:Id=Id-687052362 soapenv:Fault faultcodesoapenv:Server/faultcode faultstringFor input string: 1er/faultstring detail/ /soapenv:Fault /soapenv:Body /soapenv:Envelope When this is parsed through AXIOM-API, i get following, ?xml version=1.0 encoding=UTF-8? fragment xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd; xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xenc=http://www.w3.org/2001/04/xmlenc#; soapenv:Fault xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd; xmlns:xenc=http://www.w3.org/2001/04/xmlenc#; faultcode xmlns:axis2ns34=soapenv:Server/faultcode faultstring xmlns:axis2ns35=For input string: 1er/faultstring detail xmlns:axis2ns36=/detail /soapenv:Fault /fragment Note that some empty namespaces (xmlns:axis2ns34=) are added to faultcode elements. These elements cannot be parsed using a SAX parser. When parse through SAX we get following exception, [Fatal Error] :1:493: The value of the attribute prefix=xmlns,localpart=axis2ns34,rawname=xmlns:axis2ns34 is invalid. Prefixed namespace bindings may not be empty. org.xml.sax.SAXParseException: The value of the attribute prefix=xmlns,localpart=axis2ns34,rawname=xmlns:axis2ns34 is invalid. Prefixed namespace bindings may not be empty. at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.wso2.my.Client.main(Client.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) We should not re-declare namespaces for elements with empty namespaces. Thanks AmilaJ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-353) Need a replacement for OMXMLBuilderFactory
[ https://issues.apache.org/jira/browse/AXIOM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096638#comment-13096638 ] Andreas Veithen commented on AXIOM-353: --- OMXMLBuilderFactory should also define a higher level API to create XOP and MTOM builders. With the current API it is the responsibility of the application code to set up the XML parser with the correct charset encoding (which must be derived from the content type of the MIME message or the content type of the root MIME part). To illustrate the need for such a higher level API, consider the following code that appears several times in the Axiom test suite (and also in other projects): XMLStreamReader reader = StAXUtils.createXMLStreamReader(new BufferedReader( new InputStreamReader(attachments.getRootPartInputStream(; MTOMStAXSOAPModelBuilder builder = new MTOMStAXSOAPModelBuilder(reader, attachments, null); OMElement root = builder.getDocumentElement(); This code has two problems: * Converting the byte stream to a character stream before passing it to the XML parser is an anti-pattern. The XML parser does a much better job than InputStreamReader. * The code doesn't correctly take into account the character set encoding. The code shown above only works if the root MIME part is encoded with the platform default charset encoding. This shortcoming of the Axiom API leads to aberrations such as having charset autodection logic (i.e. an implementation of appendix F of the XML specification; see AXIS2-2508) in Axis2, which is something that the XML parser should be responsible for. Need a replacement for OMXMLBuilderFactory -- Key: AXIOM-353 URL: https://issues.apache.org/jira/browse/AXIOM-353 Project: Axiom Issue Type: Improvement Components: API Reporter: Andreas Veithen Assignee: Andreas Veithen Fix For: 1.2.13 Historically, org.apache.axiom.om.impl.llom.factory.OMXMLBuilderFactory was used to create Axiom trees from XML documents (and there are still places in Axis2 where this is used). Unfortunately, this class is located in the wrong package and JAR (it is implementation independent but belongs to LLOM). Nowadays, the standard way to create an Axiom tree is to instantiate StAXOMBuilder or one of its subclasses directly. However, this is not optimal for two reasons: * It implies the assumption that every implementation of the Axiom API necessarily uses StAXOMBuilder. This means that an implementation doesn't have the freedom to provide its own builder implementation (e.g. in order to implement some special optimizations). * StAXOMBuilder belongs to a package which has impl in its name. This tends to blur the distinction between the public API and internal implementation classes. There should be an abstract API for creating builder instances. It should be defined in terms of interfaces (such as OMXMLParserWrapper). OMMetaFactory is a good candidate for this because it is already used to encapsulate an implementation of the Axiom API (there is one implementation of OMMetaFactory for LLOM and one for DOOM). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
