svn commit: r440280 - in /webservices/commons/trunk/modules/axiom/modules: axiom-api/src/main/java/org/apache/axiom/om/ axiom-api/src/main/java/org/apache/axiom/om/impl/ axiom-tests/src/test/java/org/
Author: thilina
Date: Mon Sep 4 23:50:51 2006
New Revision: 440280
URL: http://svn.apache.org/viewvc?view=rev&rev=440280
Log:
Refactoring content type logic
Fixing the ImageSample Test
Modified:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/attachments/ImageSampleTest.java
Modified:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
URL:
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java?view=diff&rev=440280&r1=440279&r2=440280
==
---
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
(original)
+++
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
Mon Sep 4 23:50:51 2006
@@ -16,6 +16,7 @@
package org.apache.axiom.om;
+import org.apache.axiom.om.impl.MTOMConstants;
import org.apache.axiom.om.util.UUIDGenerator;
import org.apache.axiom.soap.SOAP11Constants;
import org.apache.axiom.soap.SOAP12Constants;
@@ -56,19 +57,20 @@
public String getContentType() {
String SOAPContentType;
-if (isOptimized()) {
-if (isSoap11) {
-SOAPContentType = SOAP11Constants.SOAP_11_CONTENT_TYPE;
-} else {
-SOAPContentType = SOAP12Constants.SOAP_12_CONTENT_TYPE;
-}
-return this.getContentTypeForMime(SOAPContentType);
+if (isSoap11) {
+SOAPContentType = SOAP11Constants.SOAP_11_CONTENT_TYPE;
} else {
-if (!isSoap11) {
-return SOAP12Constants.SOAP_12_CONTENT_TYPE;
-} else {
-return SOAP11Constants.SOAP_11_CONTENT_TYPE;
-}
+SOAPContentType = SOAP12Constants.SOAP_12_CONTENT_TYPE;
+}
+// MTOM is given priority
+if (isOptimized()) {
+return this.getContentTypeForMime(SOAPContentType,
MTOMConstants.MTOM_TYPE);
+} else if (isDoingSWA())
+{
+ return this.getContentTypeForMime(SOAPContentType,
MTOMConstants.SWA_TYPE);
+}
+else {
+return SOAPContentType;
}
}
@@ -150,14 +152,14 @@
this.doingSWA = doingSWA;
}
- public String getContentTypeForMime(String SOAPContentType) {
+ public String getContentTypeForMime(String SOAPContentType, String
type) {
StringBuffer sb = new StringBuffer();
sb.append("multipart/related");
sb.append("; ");
sb.append("boundary=");
sb.append(getMimeBoundary());
- sb.append("; ");
- sb.append("type=\"application/xop+xml\"");
+ sb.append("; ");
+ sb.append("type=\""+type+"\"");
sb.append("; ");
sb.append("start=\"<" + getRootContentId() + ">\"");
sb.append("; ");
Modified:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
URL:
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java?view=diff&rev=440280&r1=440279&r2=440280
==
---
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
(original)
+++
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
Mon Sep 4 23:50:51 2006
@@ -20,6 +20,8 @@
import org.apache.axiom.om.OMException;
import org.apache.axiom.om.OMOutputFormat;
import org.apache.axiom.om.OMText;
+import org.apache.axiom.soap.SOAP11Constants;
+import org.apache.axiom.soap.SOAP12Constants;
import javax.activation.DataHandler;
import javax.mail.MessagingException;
@@ -127,12 +129,36 @@
outStream.write(new byte[]{45, 45});
}
-public static void writeSOAPWithAttachementsMessage(OMElement
element,OutputStream outputStream, Map attachmentMap)
+public static void writeSOAPWithAttachmentsMessage(StringWriter
writer,OutputStream outputStream, Map attachmentMap,OMOutputFormat format)
{
+// String SOAPContentType;
+// if (format.isSOAP11()) {
+//SOAPContentType = SOAP11Constants.SOAP_11_CONTENT_TYPE;
+//} else {
+//SOAPContentType = SOAP12Constants.SOAP_12_CONTENT_TYPE;
+//}
+//startWritingMime(outputStream, format.getMimeBou
[jira] Commented: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[
http://issues.apache.org/jira/browse/WSCOMMONS-78?page=comments#action_12432572
]
Jochen Wiedmann commented on WSCOMMONS-78:
--
In the meantime, I have detected that Axis 2 depends much, much more on these
deprecated API's than I had expected. Unfortunately that means, that the
serialization stuff in Axis 2 is most likely broken, at least if it depends on
the same assumptions, which are implicit in the API. (Basically, it is assumed
that all namespaces are declared in the top level elements, which is of course
recommendable, but cannot be trusted.)
I'll try to understand the serialization framework in Axis 2 first, before I'll
continue my work.
> Including a schema without namespace into a schema with namespace is not
> possible
> -
>
> Key: WSCOMMONS-78
> URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
> Project: WS-Commons
> Issue Type: Bug
> Components: XmlSchema
>Reporter: Jochen Wiedmann
> Attachments: XmlSchema-include-handling.patch,
> XmlSchema-Include-Without-Namespace.patch
>
>
> The XML Schema specification states in "4.2.1 Assembling a schema for a
> single target namespace from multiple schema definition documents":
> 2 One of the following must be true:
> ...
> 2.3 SII has no targetNamespace [attribute] (but SII' does).
> 3 The appropriate case among the following must be true:
> ...
> 3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
> d item's parent must include not only definitions
> or declarations corresponding to the appropriate members of its own
> [children], but also components identical to all the - schema components- of
> I,
> except that anywhere the - absent- target namespace name would have
> appeared, the - actual value- of the targetNamespace [attribute] of SII' is
> used.
> In particular, it replaces - absent- in the following places:
> 3.2.1 The {target namespace} of named schema components, both at the top
> level and (in the case of nested type definitions and nested attribute and
> element declarations whose code was qualified) nested within definitions;
> 3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
> In other words, it is possible to include a schema without namespace, as if
> it had the namespace of the including schema.
> Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
> The patch includes a simple test case and could be applied, if this bug is
> fixed.
> Suggested resolution, as realized in JaxMeXS: If such a schema is being
> parsed, then mutable instances of QName should be created, which would always
> return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (WSCOMMONS-83) TCPMon appends listen port to target host when using an external ip.
TCPMon appends listen port to target host when using an external ip. Key: WSCOMMONS-83 URL: http://issues.apache.org/jira/browse/WSCOMMONS-83 Project: WS-Commons Issue Type: Bug Reporter: Dinesh Premalal Priority: Blocker When sending a request to external ip, TCPMonitor appends "listen port" to "target host". It need to be target port that should append to target host. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r440241 - in /webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema: ./ constants/ utils/
Author: dims
Date: Mon Sep 4 20:53:36 2006
New Revision: 440241
URL: http://svn.apache.org/viewvc?view=rev&rev=440241
Log:
get rid of javax.xml.XMLConstants
Modified:
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/constants/Constants.java
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/NamespaceMap.java
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/NodeNamespaceContext.java
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/PrefixCollector.java
Modified:
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
URL:
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java?view=diff&rev=440241&r1=440240&r2=440241
==
---
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
(original)
+++
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
Mon Sep 4 20:53:36 2006
@@ -22,7 +22,6 @@
import java.util.StringTokenizer;
import java.util.Vector;
-import javax.xml.XMLConstants;
import javax.xml.namespace.NamespaceContext;
import javax.xml.namespace.QName;
import javax.xml.parsers.DocumentBuilderFactory;
@@ -503,16 +502,16 @@
final String localName;
final String prefix;
if (offset == -1) {
- uri = pContext.getNamespaceURI(XMLConstants.DEFAULT_NS_PREFIX);
- if (XMLConstants.NULL_NS_URI.equals(uri)) {
+ uri = pContext.getNamespaceURI(Constants.DEFAULT_NS_PREFIX);
+ if (Constants.NULL_NS_URI.equals(uri)) {
return new QName(schema.targetNamespace, pName);
}
localName = pName;
- prefix = XMLConstants.DEFAULT_NS_PREFIX;
+ prefix = Constants.DEFAULT_NS_PREFIX;
} else {
prefix = pName.substring(0, offset);
uri = pContext.getNamespaceURI(prefix);
- if (uri == null || XMLConstants.NULL_NS_URI.equals(uri)) {
+ if (uri == null || Constants.NULL_NS_URI.equals(uri)) {
throw new IllegalStateException("The prefix " + prefix
+ " is not bound.");
}
localName = pName.substring(offset+1);
@@ -1294,7 +1293,7 @@
ctx = new NodeNamespaceContext(attrEl);
}
String namespace = ctx.getNamespaceURI(prefix);
-if (!XMLConstants.NULL_NS_URI.equals(namespace)) {
+if (!Constants.NULL_NS_URI.equals(namespace)) {
Attr nsAttr =
attrEl.getOwnerDocument().createAttribute("xmlns:" + prefix);
nsAttr.setValue(namespace);
attrs.add(nsAttr);
Modified:
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java
URL:
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java?view=diff&rev=440241&r1=440240&r2=440241
==
---
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java
(original)
+++
webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java
Mon Sep 4 20:53:36 2006
@@ -16,6 +16,8 @@
package org.apache.ws.commons.schema;
+import org.apache.ws.commons.schema.constants.Constants;
+import org.apache.ws.commons.schema.utils.NamespacePrefixList;
import org.w3c.dom.Attr;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
@@ -23,20 +25,14 @@
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import org.w3c.dom.Text;
-import org.xml.sax.helpers.NamespaceSupport;
-import org.apache.ws.commons.schema.constants.Constants;
-import org.apache.ws.commons.schema.utils.NamespacePrefixList;
-import javax.xml.XMLConstants;
+import javax.xml.namespace.QName;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
-import javax.xml.namespace.NamespaceContext;
-import javax.xml.namespace.QName;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.Hashtable;
-import java.util.Iterator;
public class XmlSchemaSerial
[jira] Commented: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[
http://issues.apache.org/jira/browse/WSCOMMONS-78?page=comments#action_12432559
]
Davanum Srinivas commented on WSCOMMONS-78:
---
I've applied WSCOMMONS-81, Can you please sync up with latest SVN and submit a
new patch for this bug report.
thanks,
dims
> Including a schema without namespace into a schema with namespace is not
> possible
> -
>
> Key: WSCOMMONS-78
> URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
> Project: WS-Commons
> Issue Type: Bug
> Components: XmlSchema
>Reporter: Jochen Wiedmann
> Attachments: XmlSchema-include-handling.patch,
> XmlSchema-Include-Without-Namespace.patch
>
>
> The XML Schema specification states in "4.2.1 Assembling a schema for a
> single target namespace from multiple schema definition documents":
> 2 One of the following must be true:
> ...
> 2.3 SII has no targetNamespace [attribute] (but SII' does).
> 3 The appropriate case among the following must be true:
> ...
> 3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
> d item's parent must include not only definitions
> or declarations corresponding to the appropriate members of its own
> [children], but also components identical to all the - schema components- of
> I,
> except that anywhere the - absent- target namespace name would have
> appeared, the - actual value- of the targetNamespace [attribute] of SII' is
> used.
> In particular, it replaces - absent- in the following places:
> 3.2.1 The {target namespace} of named schema components, both at the top
> level and (in the case of nested type definitions and nested attribute and
> element declarations whose code was qualified) nested within definitions;
> 3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
> In other words, it is possible to include a schema without namespace, as if
> it had the namespace of the including schema.
> Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
> The patch includes a simple test case and could be applied, if this bug is
> fixed.
> Suggested resolution, as realized in JaxMeXS: If such a schema is being
> parsed, then mutable instances of QName should be created, which would always
> return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (WSCOMMONS-81) Proper namespace handling
[ http://issues.apache.org/jira/browse/WSCOMMONS-81?page=all ] Davanum Srinivas resolved WSCOMMONS-81. --- Resolution: Fixed Applied with a few minor tweaks. -- dims > Proper namespace handling > - > > Key: WSCOMMONS-81 > URL: http://issues.apache.org/jira/browse/WSCOMMONS-81 > Project: WS-Commons > Issue Type: Bug > Components: XmlSchema >Reporter: Jochen Wiedmann >Priority: Critical > Attachments: XmlSchema-namespace-handling.patch > > > The namespace handling of XmlSchema is severely broken in several aspects: > - The code for namespace handling is duplicated all over the SchemaBuilder > class. > - Namespace declarations are typically honoured only, if they occur at the > schema level. > The attached patch fixes the namespace handling in the parser. No attempt is > made to fix the serialization. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r440228 [1/3] - in /webservices/commons/trunk/modules/XmlSchema/src: main/java/org/apache/ws/commons/schema/ main/java/org/apache/ws/commons/schema/utils/ test/java/tests/ test/test-resour
Author: dims Date: Mon Sep 4 20:10:32 2006 New Revision: 440228 URL: http://svn.apache.org/viewvc?view=rev&rev=440228 Log: Fix for WSCOMMONS-81 - Proper namespace handling Added: webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/NamespaceContextOwner.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/NamespaceMap.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/NamespacePrefixList.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/NodeNamespaceContext.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/PrefixCollector.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/TargetNamespaceValidator.java webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/includedWithoutNamespace.xsd webservices/commons/trunk/modules/XmlSchema/src/test/test-resources/includingWithNamespace.xsd Removed: webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/utils/Tokenizer.java Modified: webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchema.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java webservices/commons/trunk/modules/XmlSchema/src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java webservices/commons/trunk/modules/XmlSchema/src/test/java/tests/IncludeTest.java webservices/commons/trunk/modules/XmlSchema/src/test/java/tests/TestSimpleRestriction.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding WSCOMMONS-82 - DOMHASH implementation on AXIOM
Hi Hasalaka,
Comments inline...
On 9/4/06, Hasalaka Waravita <[EMAIL PROTECTED]> wrote:
Ruwan
One of question and a comment
1) Do u consider doing client side caching as well ?, considering most
business scenarios, it can be useful too.
Of course, but not at this moment.
2) Performance of digest algo is not linear with the size of the String, so
it would be useful decide to compute hash(and cache) or not depending on
the
size if the input first
Well, then that depends on the time it takes to 'compute the output and
construct the OM tree' and the 'digest generation and searching the Map'.
But it will be a bit complex. Will see. A good point.
On 9/4/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote:
>
> Hi Ruwan,
>
> On 9/4/06, Ruwan Linton <[EMAIL PROTECTED]> wrote:
> > Hi Ruchith,
> >
> > Yes of course, but I have several concerns.
> >
> > 1. I am going to use this digest value for caching stuff, and if the
> digest
> > value generation time takes more time than invoking the method itself
> then
> > it is useless. Since we need to convert OMElement to DOM in this
> approach
> > (C14N) it will have some performance drawbacks I guess.
>
> Hmm... DOOM is same as OM ... and it has all properties of OM in
> addition to the DOM behaviour... maybe the additional conversion step
> using the stax events from the partially read soap env and the
> incoming stream might be a bit of an overhead.
>
> >
> > 2. How about comments, my implementation of DOMHASH (That's the normal
> > behaviour of DOMHASH as well) dosent take comments in to account,
which
> is
> > required for checking the equality of two OMNodes, for caching.
>
> Well .. you can do C14N ignoring comments:
>
> Document doc =
> DocumentBuilderFactory.newInstance
> ().newDocumentBuilder().parse("/path/to/your/xml");
>
> byte[] out = Canonicalizer.getInstance(
>
> Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS).canonicalizeSubtree(
> doc.getDocumentElement());
>
> >
> > 3. I dont know weather I am right or wrong here (I dont have a deep
> > understanding of C14N), but it takes namespace declarations in to
> account
> > and we need to neglect namespace declarations and subtitue the
namespace
> URI
> > instead.
>
> Good point ... Agreed !
>
> In the case where two XML elements carries different prefixes in
> namespace declarations we cannot use C14N to compare.
>
> Thanks,
> Ruchith
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Thanks,
Ruwan
Re: Regarding WSCOMMONS-82 - DOMHASH implementation on AXIOM
Hi Ruchith,
On 9/4/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote:
Hi Ruwan,
On 9/4/06, Ruwan Linton <[EMAIL PROTECTED]> wrote:
> Hi Ruchith,
>
> Yes of course, but I have several concerns.
>
> 1. I am going to use this digest value for caching stuff, and if the
digest
> value generation time takes more time than invoking the method itself
then
> it is useless. Since we need to convert OMElement to DOM in this
approach
> (C14N) it will have some performance drawbacks I guess.
Hmm... DOOM is same as OM ... and it has all properties of OM in
addition to the DOM behaviour... maybe the additional conversion step
using the stax events from the partially read soap env and the
incoming stream might be a bit of an overhead.
>
> 2. How about comments, my implementation of DOMHASH (That's the normal
> behaviour of DOMHASH as well) dosent take comments in to account, which
is
> required for checking the equality of two OMNodes, for caching.
Well .. you can do C14N ignoring comments:
Document doc =
DocumentBuilderFactory.newInstance
().newDocumentBuilder().parse("/path/to/your/xml");
byte[] out = Canonicalizer.getInstance(
Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS).canonicalizeSubtree(
doc.getDocumentElement());
>
> 3. I dont know weather I am right or wrong here (I dont have a deep
> understanding of C14N), but it takes namespace declarations in to
account
> and we need to neglect namespace declarations and subtitue the namespace
URI
> instead.
Good point ... Agreed !
In the case where two XML elements carries different prefixes in
namespace declarations we cannot use C14N to compare.
Yes, exactly. If two clients send requests with the same namespace URI but
with seperate namesapce declarations then C14N is going to fail in caching.
Thanks for the comments.
Thanks,
Ruchith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r440146 - /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
Author: chinthaka
Date: Mon Sep 4 11:22:02 2006
New Revision: 440146
URL: http://svn.apache.org/viewvc?view=rev&rev=440146
Log:
Fixing a compilation error. Thilina, you might wanna fix this later :)
Modified:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
Modified:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
URL:
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java?view=diff&rev=440146&r1=440145&r2=440146
==
---
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
(original)
+++
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
Mon Sep 4 11:22:02 2006
@@ -18,14 +18,17 @@
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMException;
+import org.apache.axiom.om.OMOutputFormat;
import org.apache.axiom.om.OMText;
import javax.activation.DataHandler;
import javax.mail.MessagingException;
import javax.mail.internet.MimeBodyPart;
+import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.io.StringWriter;
+import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.Map;
@@ -44,10 +47,10 @@
"text/xml; charset=" + charSetEncoding);
MimeBodyPart rootMimeBodyPart = new MimeBodyPart();
rootMimeBodyPart.setDataHandler(dh);
-
+
rootMimeBodyPart.addHeader("content-type",
-"application/xop+xml; charset=" + charSetEncoding +
- "; type=\""+SOAPContentType+"\";");
+"application/xop+xml; charset=" + charSetEncoding +
+"; type=\""+SOAPContentType+"\";");
rootMimeBodyPart.addHeader("content-transfer-encoding", "binary");
rootMimeBodyPart.addHeader("content-id","<"+contentId+">");
@@ -107,7 +110,7 @@
* @throws MessagingException
*/
public static void writeBodyPart(OutputStream outStream,
- MimeBodyPart part,
+ MimeBodyPart part,
String boundary) throws IOException,
MessagingException {
outStream.write(CRLF);
@@ -126,6 +129,10 @@
public static void writeSOAPWithAttachementsMessage(OMElement
element,OutputStream outputStream, Map attachmentMap)
{
-
+
+}
+
+public static void writeSOAPWithAttachmentsMessage(StringWriter
bufferedSOAPBody, ByteArrayOutputStream bytesOut, HashMap hashMap,
OMOutputFormat format2) {
+//TODO : Thilina please implement this :)
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding WSCOMMONS-82 - DOMHASH implementation on AXIOM
Ruwan
One of question and a comment
1) Do u consider doing client side caching as well ?, considering most
business scenarios, it can be useful too.
2) Performance of digest algo is not linear with the size of the String, so
it would be useful decide to compute hash(and cache) or not depending on the
size if the input first
On 9/4/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote:
Hi Ruwan,
On 9/4/06, Ruwan Linton <[EMAIL PROTECTED]> wrote:
> Hi Ruchith,
>
> Yes of course, but I have several concerns.
>
> 1. I am going to use this digest value for caching stuff, and if the
digest
> value generation time takes more time than invoking the method itself
then
> it is useless. Since we need to convert OMElement to DOM in this
approach
> (C14N) it will have some performance drawbacks I guess.
Hmm... DOOM is same as OM ... and it has all properties of OM in
addition to the DOM behaviour... maybe the additional conversion step
using the stax events from the partially read soap env and the
incoming stream might be a bit of an overhead.
>
> 2. How about comments, my implementation of DOMHASH (That's the normal
> behaviour of DOMHASH as well) dosent take comments in to account, which
is
> required for checking the equality of two OMNodes, for caching.
Well .. you can do C14N ignoring comments:
Document doc =
DocumentBuilderFactory.newInstance
().newDocumentBuilder().parse("/path/to/your/xml");
byte[] out = Canonicalizer.getInstance(
Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS).canonicalizeSubtree(
doc.getDocumentElement());
>
> 3. I dont know weather I am right or wrong here (I dont have a deep
> understanding of C14N), but it takes namespace declarations in to
account
> and we need to neglect namespace declarations and subtitue the namespace
URI
> instead.
Good point ... Agreed !
In the case where two XML elements carries different prefixes in
namespace declarations we cannot use C14N to compare.
Thanks,
Ruchith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[
http://issues.apache.org/jira/browse/WSCOMMONS-78?page=comments#action_12432522
]
Jochen Wiedmann commented on WSCOMMONS-78:
--
Did you apply the patch for WSCOMMONS-81 in advance? In either case, we should
resolve that one first.
> Including a schema without namespace into a schema with namespace is not
> possible
> -
>
> Key: WSCOMMONS-78
> URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
> Project: WS-Commons
> Issue Type: Bug
> Components: XmlSchema
>Reporter: Jochen Wiedmann
> Attachments: XmlSchema-include-handling.patch,
> XmlSchema-Include-Without-Namespace.patch
>
>
> The XML Schema specification states in "4.2.1 Assembling a schema for a
> single target namespace from multiple schema definition documents":
> 2 One of the following must be true:
> ...
> 2.3 SII has no targetNamespace [attribute] (but SII' does).
> 3 The appropriate case among the following must be true:
> ...
> 3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
> d item's parent must include not only definitions
> or declarations corresponding to the appropriate members of its own
> [children], but also components identical to all the - schema components- of
> I,
> except that anywhere the - absent- target namespace name would have
> appeared, the - actual value- of the targetNamespace [attribute] of SII' is
> used.
> In particular, it replaces - absent- in the following places:
> 3.2.1 The {target namespace} of named schema components, both at the top
> level and (in the case of nested type definitions and nested attribute and
> element declarations whose code was qualified) nested within definitions;
> 3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
> In other words, it is possible to include a schema without namespace, as if
> it had the namespace of the including schema.
> Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
> The patch includes a simple test case and could be applied, if this bug is
> fixed.
> Suggested resolution, as realized in JaxMeXS: If such a schema is being
> parsed, then mutable instances of QName should be created, which would always
> return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding WSCOMMONS-82 - DOMHASH implementation on AXIOM
Hi Ruwan,
On 9/4/06, Ruwan Linton <[EMAIL PROTECTED]> wrote:
Hi Ruchith,
Yes of course, but I have several concerns.
1. I am going to use this digest value for caching stuff, and if the digest
value generation time takes more time than invoking the method itself then
it is useless. Since we need to convert OMElement to DOM in this approach
(C14N) it will have some performance drawbacks I guess.
Hmm... DOOM is same as OM ... and it has all properties of OM in
addition to the DOM behaviour... maybe the additional conversion step
using the stax events from the partially read soap env and the
incoming stream might be a bit of an overhead.
2. How about comments, my implementation of DOMHASH (That's the normal
behaviour of DOMHASH as well) dosent take comments in to account, which is
required for checking the equality of two OMNodes, for caching.
Well .. you can do C14N ignoring comments:
Document doc =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("/path/to/your/xml");
byte[] out = Canonicalizer.getInstance(
Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS).canonicalizeSubtree(doc.getDocumentElement());
3. I dont know weather I am right or wrong here (I dont have a deep
understanding of C14N), but it takes namespace declarations in to account
and we need to neglect namespace declarations and subtitue the namespace URI
instead.
Good point ... Agreed !
In the case where two XML elements carries different prefixes in
namespace declarations we cannot use C14N to compare.
Thanks,
Ruchith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WSCOMMONS-76) StAX Filter [ Data conversion, extraction, or do something between XMLStreamReader and StAXBuilder]
[ http://issues.apache.org/jira/browse/WSCOMMONS-76?page=comments#action_12432515 ] Takahide Nogayama commented on WSCOMMONS-76: Example remove Security header) Web service "webservice1" need process security header whose SOAP actor is "webservice1" and must not process security header whose SOAP actor is not "ws1". In constructor of StAXBuilder, filter is inserted between XMLStreamReader and StAXBuilder. And builder and messageContext is set to filter here. [StaXBuilder] -> [Filter] -> [XMLStreamReader] Filter get actor information from MessageContext. The following is received message and filter also receives this message from XMLStreamReader. StAXBuilder can avoid creating OMElement whose actor is not "webservice1". http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";> StAXBuilder receive the following messages from filter. http://schemas.xmlsoap.org/soap/envelope/"; xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";> > StAX Filter [ Data conversion, extraction, or do something between > XMLStreamReader and StAXBuilder] > --- > > Key: WSCOMMONS-76 > URL: http://issues.apache.org/jira/browse/WSCOMMONS-76 > Project: WS-Commons > Issue Type: New Feature > Components: AXIOM > Environment: windows >Reporter: Takahide Nogayama > Attachments: patchAXIOM_to_moduleaxiom-apisrcmainjava.txt, > patchAXIS2_to_moduleskernelsrc.txt, src_demo.zip, StAX_filter_architecture.ppt > > > Filter is interface and extends XMLStreamReader. Filter wraps > XMLStreamReader. And XMLStreamReader of StAXBuilder is replaced by Filter. > In building phase, next() method must be invoked on each event. filter get > result of next() from XMLStreamReader, and do some process, then return the > result to StAXBuilder. > We can set Object on filter. Filter get some information from it and set > result on it to transfer the result. > We can set StAXBuilder on filter. Filter get OMDocument from the builder. If > filter want to know past information, the OMDocument has it. > If StAXBuilder has lastNode() method, Filter can make reference list to > OMNode. this is commneted in > http://issues.apache.org/jira/browse/WSCOMMONS-75 . > Example1) > SOAP header has some child elements. and they has actor Attribute. it > indicates which intermediary should process the element. > ExtractMyActorSOAPHeaderFilter.java is implementation of Filter for this > example. The filter monitors locaName at first, > If START_ELEMENT whose actor does not equals myactor is found, The filter > invokes next() until the element's END_ELEMENT. > Thus, The soap header elements which has other's actor are not transfered to > StAXBuilder. We can ommit creating fruitness OM. > Example2) > If StAXBuilder has lastNode() method, Filter can make reference list. The > list has OMNode whose actor indicates myactor. > After building, If we want to access Security header elements which has > myactor, we can access the element directry by using the reference list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WSCOMMONS-76) StAX Filter [ Data conversion, extraction, or do something between XMLStreamReader and StAXBuilder]
[ http://issues.apache.org/jira/browse/WSCOMMONS-76?page=comments#action_12432513 ] Takahide Nogayama commented on WSCOMMONS-76: Objective of StAX Filter is mainly performance improvement. - Avoid creating fruitless OMElements If there are many unnecessary Elements in XML, and if StAX Filter remove them before StAXBuilder, we can save CPU and Memory resources about creating OMElements. i.e. Others SOAP headers are unnecessary elements. - Avoid creating duplicate OMElements If there are many Elements to be converted in XML, StAXOMBuilder creates OMElements of raw data then converts it to another OMElements. There exists double OMElements they have same meaning. If user only uses converted OMElements, Creating raw OMElements are fruitless process. If StAX Filter converts XML data before StAXBuilder, StAXOMBuilder creates only OMElements of converted data. - Avoid fruitless traverse Searching OM tree can consume many CPU resources, if target OMElement is in edge of the OM tree or the target OMElement is not exists. If we get candidates for this search, we can only search in the candidate set. StAXOMBuilder invokes next() against all XML events. And StAX Filter pick up candidate and put it to candidate set in the next() invocation. Then we can use the candidate set for searching OMElement. > StAX Filter [ Data conversion, extraction, or do something between > XMLStreamReader and StAXBuilder] > --- > > Key: WSCOMMONS-76 > URL: http://issues.apache.org/jira/browse/WSCOMMONS-76 > Project: WS-Commons > Issue Type: New Feature > Components: AXIOM > Environment: windows >Reporter: Takahide Nogayama > Attachments: patchAXIOM_to_moduleaxiom-apisrcmainjava.txt, > patchAXIS2_to_moduleskernelsrc.txt, src_demo.zip, StAX_filter_architecture.ppt > > > Filter is interface and extends XMLStreamReader. Filter wraps > XMLStreamReader. And XMLStreamReader of StAXBuilder is replaced by Filter. > In building phase, next() method must be invoked on each event. filter get > result of next() from XMLStreamReader, and do some process, then return the > result to StAXBuilder. > We can set Object on filter. Filter get some information from it and set > result on it to transfer the result. > We can set StAXBuilder on filter. Filter get OMDocument from the builder. If > filter want to know past information, the OMDocument has it. > If StAXBuilder has lastNode() method, Filter can make reference list to > OMNode. this is commneted in > http://issues.apache.org/jira/browse/WSCOMMONS-75 . > Example1) > SOAP header has some child elements. and they has actor Attribute. it > indicates which intermediary should process the element. > ExtractMyActorSOAPHeaderFilter.java is implementation of Filter for this > example. The filter monitors locaName at first, > If START_ELEMENT whose actor does not equals myactor is found, The filter > invokes next() until the element's END_ELEMENT. > Thus, The soap header elements which has other's actor are not transfered to > StAXBuilder. We can ommit creating fruitness OM. > Example2) > If StAXBuilder has lastNode() method, Filter can make reference list. The > list has OMNode whose actor indicates myactor. > After building, If we want to access Security header elements which has > myactor, we can access the element directry by using the reference list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[
http://issues.apache.org/jira/browse/WSCOMMONS-78?page=comments#action_12432512
]
Davanum Srinivas commented on WSCOMMONS-78:
---
I tried cleaning up...no luck :(
patching file src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
Hunk #1 FAILED at 27.
Hunk #2 succeeded at 41 (offset -3 lines).
Hunk #3 succeeded at 75 with fuzz 1 (offset -3 lines).
Hunk #4 succeeded at 225 (offset -3 lines).
Hunk #5 FAILED at 273.
Hunk #6 FAILED at 500.
Hunk #7 succeeded at 1309 (offset 108 lines).
Hunk #8 succeeded at 1330 (offset 108 lines).
Hunk #9 succeeded at 1508 (offset 140 lines).
Hunk #10 succeeded at 1811 (offset 240 lines).
Hunk #11 succeeded at 1858 (offset 240 lines).
Hunk #12 FAILED at 1880.
Hunk #13 succeeded at 2084 (offset 241 lines).
Hunk #14 succeeded at 2151 (offset 256 lines).
4 out of 14 hunks FAILED -- saving rejects to file
src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java.rej
patching file
src/main/java/org/apache/ws/commons/schema/utils/TargetNamespaceValidator.java
patching file
src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java
patching file src/main/java/org/apache/ws/commons/schema/XmlSchemaException.java
patching file src/main/java/org/apache/ws/commons/schema/XmlSchema.java
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
5 out of 5 hunks ignored -- saving rejects to file
src/main/java/org/apache/ws/commons/schema/XmlSchema.java.rej
patching file
src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java
Hunk #1 succeeded at 93 (offset -4 lines).
patching file src/main/java/org/apache/ws/commons/schema/XmlSchemaType.java
patching file src/test/java/tests/CircularSchemaTest.java
patching file src/test/java/tests/IncludeTest.java
Hunk #2 FAILED at 120.
Hunk #3 FAILED at 127.
2 out of 3 hunks FAILED -- saving rejects to file
src/test/java/tests/IncludeTest.java.rej
patching file src/test/test-resources/includedWithoutNamespace.xsd
patching file src/test/test-resources/includingWithNamespace.xsd
> Including a schema without namespace into a schema with namespace is not
> possible
> -
>
> Key: WSCOMMONS-78
> URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
> Project: WS-Commons
> Issue Type: Bug
> Components: XmlSchema
>Reporter: Jochen Wiedmann
> Attachments: XmlSchema-include-handling.patch,
> XmlSchema-Include-Without-Namespace.patch
>
>
> The XML Schema specification states in "4.2.1 Assembling a schema for a
> single target namespace from multiple schema definition documents":
> 2 One of the following must be true:
> ...
> 2.3 SII has no targetNamespace [attribute] (but SII' does).
> 3 The appropriate case among the following must be true:
> ...
> 3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
> d item's parent must include not only definitions
> or declarations corresponding to the appropriate members of its own
> [children], but also components identical to all the - schema components- of
> I,
> except that anywhere the - absent- target namespace name would have
> appeared, the - actual value- of the targetNamespace [attribute] of SII' is
> used.
> In particular, it replaces - absent- in the following places:
> 3.2.1 The {target namespace} of named schema components, both at the top
> level and (in the case of nested type definitions and nested attribute and
> element declarations whose code was qualified) nested within definitions;
> 3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
> In other words, it is possible to include a schema without namespace, as if
> it had the namespace of the including schema.
> Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
> The patch includes a simple test case and could be applied, if this bug is
> fixed.
> Suggested resolution, as realized in JaxMeXS: If such a schema is being
> parsed, then mutable instances of QName should be created, which would always
> return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please review: WSCOMMONS-78
Hey Joe, the patch is bad. Can you please run "svn diff" and upload the diff? the current patch in XmlSchema-include-handling.patch seems to have diff's for files under .svn directory. -- dims On 9/4/06, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, I have attached a somewhat larger patch in WSCOMMONS-78, which fixes the handling of xs:include and xs:redefine in XmlSchema. It also fixes some invalid assumptions by changing the API: - It is an invalid assumption, that a system ID can be mapped to a unique schema. Fact is, that a schema can be included multiple times and from schemas with different target namespaces. (In any case, the included schema absorbs the including schemas.) - The same holds true for xs:redefine - It is an invalid assumption, that a target namespace can be mapped to a single schema. For example, it is quite possible, that multiple imports occur to schemas with the same namespace, but a different system ID. Additionally, an imported schema may include another schema with the same target namespace. Due to the API changes, I won't commit this patch without an explicit acknowledge by someone else, who reviewed the patch. Please be so kind and do this as soon as possible. Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please review: WSCOMMONS-78
Hi, I have attached a somewhat larger patch in WSCOMMONS-78, which fixes the handling of xs:include and xs:redefine in XmlSchema. It also fixes some invalid assumptions by changing the API: - It is an invalid assumption, that a system ID can be mapped to a unique schema. Fact is, that a schema can be included multiple times and from schemas with different target namespaces. (In any case, the included schema absorbs the including schemas.) - The same holds true for xs:redefine - It is an invalid assumption, that a target namespace can be mapped to a single schema. For example, it is quite possible, that multiple imports occur to schemas with the same namespace, but a different system ID. Additionally, an imported schema may include another schema with the same target namespace. Due to the API changes, I won't commit this patch without an explicit acknowledge by someone else, who reviewed the patch. Please be so kind and do this as soon as possible. Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r440000 - in /webservices/commons/trunk/modules/axiom/modules: axiom-api/src/main/java/org/apache/axiom/attachments/ axiom-api/src/main/java/org/apache/axiom/attachments/utils/ axiom-api/s
Author: thilina
Date: Mon Sep 4 02:51:04 2006
New Revision: 44
URL: http://svn.apache.org/viewvc?view=rev&rev=44
Log:
Removing ImageIO & ImageDataSource, which were giving troubles to some users.
People can use native java classes to achieve the functionality provided by
these classes.
Moving DataHandler utils to a more suitable home.
Moved the contentType generation logic to OMOutputFormat, which is the only
class uses it.
Added:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/DataHandlerUtils.java
(with props)
Removed:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/DataHandlerUtils.java
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/ImageDataSource.java
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/ImageIO.java
Modified:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/MIMEOutputUtils.java
webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/org/apache/axiom/om/impl/dom/TextImpl.java
webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/om/impl/llom/OMTextImpl.java
webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/attachments/ImageSampleTest.java
webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/attachments/MIMEHelperTest.java
webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/IteratorTest.java
webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/MIMEOutputUtilsTest.java
Added:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/DataHandlerUtils.java
URL:
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/DataHandlerUtils.java?view=auto&rev=44
==
---
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/DataHandlerUtils.java
(added)
+++
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/DataHandlerUtils.java
Mon Sep 4 02:51:04 2006
@@ -0,0 +1,39 @@
+/*
+ * Copyright 2004 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+package org.apache.axiom.attachments.utils;
+
+
+import org.apache.axiom.attachments.ByteArrayDataSource;
+import org.apache.axiom.om.util.Base64;
+
+import javax.activation.DataHandler;
+
+public class DataHandlerUtils {
+
+ public static Object getDataHandlerFromText(String value, String mimeType)
+ {
+ ByteArrayDataSource dataSource;
+ byte[] data = Base64.decode(value);
+ if (mimeType != null) {
+ dataSource = new ByteArrayDataSource(data, mimeType);
+ } else {
+ // Assumes type as application/octet-stream
+ dataSource = new ByteArrayDataSource(data);
+ }
+ return new DataHandler(dataSource);
+ }
+}
Propchange:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/utils/DataHandlerUtils.java
--
svn:executable = *
Modified:
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
URL:
http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java?view=diff&rev=44&r1=43&r2=44
==
---
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
(original)
+++
webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMOutputFormat.java
Mon Sep 4 02:51:04 2006
@@ -16,7 +16,6 @@
package org.apache.axiom.om;
-import org.apa
[jira] Updated: (WSCOMMONS-82) DOMHASH implementation on AXIOM
[ http://issues.apache.org/jira/browse/WSCOMMONS-82?page=all ] Ruwan Linton updated WSCOMMONS-82: -- Attachment: DOMHASH_implementation.patch Earlier patch was wrong, please apply this patch (I have used Java generics which is only supported in JDK 1.5, but Axiom is using JDK 1.4) > DOMHASH implementation on AXIOM > --- > > Key: WSCOMMONS-82 > URL: http://issues.apache.org/jira/browse/WSCOMMONS-82 > Project: WS-Commons > Issue Type: New Feature > Components: AXIOM >Reporter: Ruwan Linton >Priority: Minor > Attachments: DOMHASH_implementation.patch, patch.txt > > > I am going to add the DOMHASH algorithm implementation on AXIOM, so that we > can generate a unique digest value for the OMNodes possessing the same > content. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding WSCOMMONS-82 - DOMHASH implementation on AXIOM
Hi Ruchith, Yes of course, but I have several concerns. 1. I am going to use this digest value for caching stuff, and if the digest value generation time takes more time than invoking the method itself then it is useless. Since we need to convert OMElement to DOM in this approach (C14N) it will have some performance drawbacks I guess. 2. How about comments, my implementation of DOMHASH (That's the normal behaviour of DOMHASH as well) dosent take comments in to account, which is required for checking the equality of two OMNodes, for caching. 3. I dont know weather I am right or wrong here (I dont have a deep understanding of C14N), but it takes namespace declarations in to account and we need to neglect namespace declarations and subtitue the namespace URI instead. BTW, I have done the implementation and I think it is good to use something in AXIOM rather than using some other (performance) Thanks, Ruwan. On 9/4/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: Hi Ruwan, If you are looking to compare two semantically equal XML elements how about using C14N and then calculating the digest C14Ned XML. If you convert the OMElement to DOOM then you can use the C14N implementation available in XML-Security for this. Thanks, Ruchith On 9/4/06, Ruwan Linton <[EMAIL PROTECTED]> wrote: > Hi, > > This is regarding the Jira, > > Key: WSCOMMONS-82 > URL: http://issues.apache.org/jira/browse/WSCOMMONS-82 > > I am going to add the DOMHASH implementation to the AXIOM. The domhash > algorithm is a digest generation algorithm that gives a unique digest value > for a given XML node. This is required to compare two XML nodes for the XML > content equality. > > I am in the process of implementing a caching module for the Axis2 and it is > required to keep the digest value of the SOAP request OM representation with > the output SOAP response, so that if a request with the same digest value > arises again I can simply send the Response without re calculating that. In > order to do so, I need to have a good mechanism which dosent count comments > and various namespace declarations in generating the digest value. > > I cant use any of the existing XML comparing mechanisms like XMLUnit since > all those takes comments also in to account. So I have implemented the > DOMHASH algorithm in the axiom-api, I have added this functionality through > a helper class since I have realized that changing the api is not effective. > The helper class is availabal as the patch.txt and the class is in the ' > org.apache.axiom.om.util.DigestGenerator'. You can get the digest value by > calling the getDigest method by giving the OMNode or OMDocument and the > digest algorithm (MD5 or SHA1). > > Thanks, > Ruwan. > > -- www.ruchith.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (WSCOMMONS-78) Including a schema without namespace into a schema with namespace is not possible
[ http://issues.apache.org/jira/browse/WSCOMMONS-78?page=all ]
Jochen Wiedmann updated WSCOMMONS-78:
-
Attachment: XmlSchema-include-handling.patch
The attached patch is based on the patch, which is provided in WSCOMMONS-81.
Note, that the patch introduces some incompatible API changes. However, these
changes are caused by design errors in the API. For example, it is invalid to
assume, that a schema with a given system ID can be included only once.
Likewise, it is invalid to assume that only one schema with a given target
namespace exists.
> Including a schema without namespace into a schema with namespace is not
> possible
> -
>
> Key: WSCOMMONS-78
> URL: http://issues.apache.org/jira/browse/WSCOMMONS-78
> Project: WS-Commons
> Issue Type: Bug
> Components: XmlSchema
>Reporter: Jochen Wiedmann
> Attachments: XmlSchema-include-handling.patch,
> XmlSchema-Include-Without-Namespace.patch
>
>
> The XML Schema specification states in "4.2.1 Assembling a schema for a
> single target namespace from multiple schema definition documents":
> 2 One of the following must be true:
> ...
> 2.3 SII has no targetNamespace [attribute] (but SII' does).
> 3 The appropriate case among the following must be true:
> ...
> 3.2 If clause 2.3 above is satisfied, then the schema corresponding to the
> d item's parent must include not only definitions
> or declarations corresponding to the appropriate members of its own
> [children], but also components identical to all the - schema components- of
> I,
> except that anywhere the - absent- target namespace name would have
> appeared, the - actual value- of the targetNamespace [attribute] of SII' is
> used.
> In particular, it replaces - absent- in the following places:
> 3.2.1 The {target namespace} of named schema components, both at the top
> level and (in the case of nested type definitions and nested attribute and
> element declarations whose code was qualified) nested within definitions;
> 3.2.2 The {namespace constraint} of a wildcard, whether negated or not;
> In other words, it is possible to include a schema without namespace, as if
> it had the namespace of the including schema.
> Unfortunately this fails with XmlSchema, as the attached patch demonstrates.
> The patch includes a simple test case and could be applied, if this bug is
> fixed.
> Suggested resolution, as realized in JaxMeXS: If such a schema is being
> parsed, then mutable instances of QName should be created, which would always
> return the target namespace of the schema.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding WSCOMMONS-82 - DOMHASH implementation on AXIOM
Hi Ruwan, If you are looking to compare two semantically equal XML elements how about using C14N and then calculating the digest C14Ned XML. If you convert the OMElement to DOOM then you can use the C14N implementation available in XML-Security for this. Thanks, Ruchith On 9/4/06, Ruwan Linton <[EMAIL PROTECTED]> wrote: Hi, This is regarding the Jira, Key: WSCOMMONS-82 URL: http://issues.apache.org/jira/browse/WSCOMMONS-82 I am going to add the DOMHASH implementation to the AXIOM. The domhash algorithm is a digest generation algorithm that gives a unique digest value for a given XML node. This is required to compare two XML nodes for the XML content equality. I am in the process of implementing a caching module for the Axis2 and it is required to keep the digest value of the SOAP request OM representation with the output SOAP response, so that if a request with the same digest value arises again I can simply send the Response without re calculating that. In order to do so, I need to have a good mechanism which dosent count comments and various namespace declarations in generating the digest value. I cant use any of the existing XML comparing mechanisms like XMLUnit since all those takes comments also in to account. So I have implemented the DOMHASH algorithm in the axiom-api, I have added this functionality through a helper class since I have realized that changing the api is not effective. The helper class is availabal as the patch.txt and the class is in the ' org.apache.axiom.om.util.DigestGenerator'. You can get the digest value by calling the getDigest method by giving the OMNode or OMDocument and the digest algorithm (MD5 or SHA1). Thanks, Ruwan. -- www.ruchith.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Regarding WSCOMMONS-82 - DOMHASH implementation on AXIOM
Hi, This is regarding the Jira, Key: WSCOMMONS-82 URL: http://issues.apache.org/jira/browse/WSCOMMONS-82 I am going to add the DOMHASH implementation to the AXIOM. The domhash algorithm is a digest generation algorithm that gives a unique digest value for a given XML node. This is required to compare two XML nodes for the XML content equality. I am in the process of implementing a caching module for the Axis2 and it is required to keep the digest value of the SOAP request OM representation with the output SOAP response, so that if a request with the same digest value arises again I can simply send the Response without re calculating that. In order to do so, I need to have a good mechanism which dosent count comments and various namespace declarations in generating the digest value. I cant use any of the existing XML comparing mechanisms like XMLUnit since all those takes comments also in to account. So I have implemented the DOMHASH algorithm in the axiom-api, I have added this functionality through a helper class since I have realized that changing the api is not effective. The helper class is availabal as the patch.txt and the class is in the ' org.apache.axiom.om.util.DigestGenerator'. You can get the digest value by calling the getDigest method by giving the OMNode or OMDocument and the digest algorithm (MD5 or SHA1). Thanks, Ruwan.
