from:"Hudson \(JIRA\)"

[jira] [Commented] (AXIOM-311) Improve the Axiom test suite

2016-05-04 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15271412#comment-15271412
 ] 

Hudson commented on AXIOM-311:
--

SUCCESS: Integrated in axiom-trunk #2685 (See 
[https://builds.apache.org/job/axiom-trunk/2685/])
AXIOM-311: Remove some old tests for scenarios that are extensively covered by 
other tests. (veithen: rev 1742325)
* 
axiom/systests/old-tests/src/test/java/org/apache/axiom/om/impl/serializer/OMSerializerTest.java


> 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
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-486) AxiomTestVerb should not extend TestVerb

2016-09-25 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15521660#comment-15521660
 ] 

Hudson commented on AXIOM-486:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2782 (See 
[https://builds.apache.org/job/axiom-trunk/2782/])
AXIOM-486: Deprecate AxiomTestVerb. (veithen: rev 1762243)
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestCloseWithSystemId.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestDetachWithDOM.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestDetachWithSAXSource.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestDetachWithStream.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/container/TestAddChildWithIncompleteSibling.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestAddAttributeReplace.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestAddAttributeReuseExistingPrefix.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestDetachWithDifferentBuilder.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetAllDeclaredNamespacesRemove.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestAddAttribute.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestDeclareNamespace.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestDetach.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestDiscard.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestGetAllAttributes.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestGetAllDeclaredNamespaces.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestGetAttribute.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestGetAttributeValue.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/omdom/attr/TestSetValueOnNamespaceDeclaration.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/headerblock/TestSetRoleWithoutExistingNamespaceDecl.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/mtom/TestBuilderDetach.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/AxiomTestVerb.java
* (add) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/AxiomTruth.java


> AxiomTestVerb should not extend TestVerb
> 
>
> Key: AXIOM-486
> URL: https://issues.apache.org/jira/browse/AXIOM-486
> Project: Axiom
>  Issue Type: Improvement
>Affects Versions: 1.2.19
>Reporter: Christian Gruber
>Priority: Minor
>
> AxiomTestVerb currently extends TestVerb, presumably to permit someone to 
> only have to statically import AxiomTestVerb.assertThat; However, TestVerb 
> was not built for extension, will be marked final in more upcoming versions 
> of Truth, especially 1.0.
> The fix is simple.  Extend AbstractVerb if (and only if) you need its 
> functionality, and otherwise simply statically import both 
> AxiomTestVerb.assertThat and Truth.assertThat since the overloads are not 
> ambiguous in their type signatures (and erasure). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-486) AxiomTestVerb should not extend TestVerb

2016-09-26 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15522433#comment-15522433
 ] 

Hudson commented on AXIOM-486:
--

UNSTABLE: Integrated in Jenkins build axiom-trunk #2783 (See 
[https://builds.apache.org/job/axiom-trunk/2783/])
AXIOM-486: Remove AxiomTestVerb. (veithen: rev 1762287)
* (delete) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/AxiomTestVerb.java


> AxiomTestVerb should not extend TestVerb
> 
>
> Key: AXIOM-486
> URL: https://issues.apache.org/jira/browse/AXIOM-486
> Project: Axiom
>  Issue Type: Improvement
>Affects Versions: 1.2.19
>Reporter: Christian Gruber
>Priority: Minor
>
> AxiomTestVerb currently extends TestVerb, presumably to permit someone to 
> only have to statically import AxiomTestVerb.assertThat; However, TestVerb 
> was not built for extension, will be marked final in more upcoming versions 
> of Truth, especially 1.0.
> The fix is simple.  Extend AbstractVerb if (and only if) you need its 
> functionality, and otherwise simply statically import both 
> AxiomTestVerb.assertThat and Truth.assertThat since the overloads are not 
> ambiguous in their type signatures (and erasure). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-487) IllegalStateException when parsing Source document

2016-10-09 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15560238#comment-15560238
 ] 

Hudson commented on AXIOM-487:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2785 (See 
[https://builds.apache.org/job/axiom-trunk/2785/])
AXIOM-487: Add support for namespace unaware attributes to XmlHandler. 
(veithen: rev 1763989)
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/impl/builder/BuildableContext.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/impl/builder/BuilderHandler.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/impl/builder/Context.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/impl/builder/UnwrappingContext.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/stream/NullXmlHandler.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/stream/XmlHandler.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/stream/XmlHandlerWrapper.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/stream/dom/DOMReader.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/stream/sax/ContentHandlerXmlHandler.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/stream/serializer/Serializer.java
* (edit) 
axiom/aspects/core-aspects/src/main/java/org/apache/axiom/core/stream/stax/pull/StAXPivot.java
* (edit) 
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/common/SAXResultContentHandler.java
* (edit) 
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/stream/stax/push/XMLStreamWriterHandler.java


> IllegalStateException when parsing Source document
> --
>
> Key: AXIOM-487
> URL: https://issues.apache.org/jira/browse/AXIOM-487
> Project: Axiom
>  Issue Type: Bug
>Affects Versions: 1.2.17, 1.2.19
>Reporter: Victor
>
> Hello,
> I tried to parse a java.xml.transform.Source (a DOMSource) using the 
> following code:
> {code}
> final OMXMLParserWrapper builder = 
> OMXMLBuilderFactory.createOMBuilder(factory, source);
> final OMElement bodyContent = builder.getDocumentElement();
> {code}
> The document contains:
> {code:xml}
> 
>  xmlns:tns="http://petals.ow2.org/talend/ArticleImporterJob/; 
> xmlns:jaxb="http://jaxb.dev.java.net/array;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> 
> 
> 0
> 
> 
> 
> 
>  xmlns:xop="http://www.w3.org/2004/08/xop/include; href="cid:fileResult" />
> 
> 
> 
> 
> 
> {code}
> And I got the following error:
> {noformat}
> java.lang.IllegalStateException
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$updateLocalName(AxiomNamedInformationItemSupport.aj:142)
>   at 
> org.apache.axiom.om.impl.llom.OMAttributeImpl.updateLocalName(OMAttributeImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$updateLocalName(AxiomNamedInformationItemSupport.aj)
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$coreGetLocalName(AxiomNamedInformationItemSupport.aj:147)
>   at 
> org.apache.axiom.om.impl.llom.OMAttributeImpl.coreGetLocalName(OMAttributeImpl.java:1)
>   at 
> org.apache.axiom.core.NSAwareAttributeMatcher.getName(NSAwareAttributeMatcher.java:84)
>   at 
> org.apache.axiom.core.CoreElementSupport.ajc$interMethod$org_apache_axiom_core_CoreElementSupport$org_apache_axiom_core_CoreElement$coreSetAttribute(CoreElementSupport.aj:96)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.coreSetAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$internalAppendAttribute(AxiomElementSupport.aj:282)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalAppendAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$internalAppendAttribute(AxiomElementSupport.aj)
>   at 
>

[jira] [Commented] (AXIOM-485) Pull parser loops infinitely attempting to count namespaces for document with redundant namespaces

2016-08-28 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15443569#comment-15443569
 ] 

Hudson commented on AXIOM-485:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #38 (See 
[https://builds.apache.org/job/axiom-1.2.x/38/])
AXIOM-485: Merge the regression test (r1758113) to the 1.2 branch and fix a bug 
in Navigator.loadNamespaces. (veithen: rev 1758118)
* (edit) axiom
* (edit) 
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/common/serializer/pull/Navigator.java
* (edit) axiom/testing
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java
* (add) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetXMLStreamReaderWithPreserveNamespaceContext2.java
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/element/AXIOM-485.xml


> Pull parser loops infinitely attempting to count namespaces for document with 
> redundant namespaces
> --
>
> Key: AXIOM-485
> URL: https://issues.apache.org/jira/browse/AXIOM-485
> Project: Axiom
>  Issue Type: Bug
>  Components: LLOM
>Affects Versions: 1.2.19
> Environment: openjdk version "1.8.0_91"
> OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK Server VM (build 25.91-b14, mixed mode)
> running on Fedora release 22 (Twenty Two)
>Reporter: Sergey Kuznetsov
>Priority: Minor
>  Labels: parser
>
> Method 
> ??org.apache.axiom.om.impl.common.serializer.pull.Navigator#loadNamespaces?? 
> getting stuck in while-true loop when document has multiple redundant 
> namespace declarations like this one
> {code:xml}
> 
> http://schemas.xmlsoap.org/soap/envelope/;
>   xmlns:m="ns://example">
> 
> 
> 
> 1
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-485) Pull parser loops infinitely attempting to count namespaces for document with redundant namespaces

2016-08-28 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15443517#comment-15443517
 ] 

Hudson commented on AXIOM-485:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2778 (See 
[https://builds.apache.org/job/axiom-trunk/2778/])
Add a regression test for AXIOM-485 (which affects the 1.2 branch, but not the 
trunk). (veithen: rev 1758113)
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java
* (add) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetXMLStreamReaderWithPreserveNamespaceContext2.java
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/element/AXIOM-485.xml


> Pull parser loops infinitely attempting to count namespaces for document with 
> redundant namespaces
> --
>
> Key: AXIOM-485
> URL: https://issues.apache.org/jira/browse/AXIOM-485
> Project: Axiom
>  Issue Type: Bug
>  Components: LLOM
>Affects Versions: 1.2.19
> Environment: openjdk version "1.8.0_91"
> OpenJDK Runtime Environment (build 1.8.0_91-b14)
> OpenJDK Server VM (build 25.91-b14, mixed mode)
> running on Fedora release 22 (Twenty Two)
>Reporter: Sergey Kuznetsov
>Priority: Minor
>  Labels: parser
>
> Method 
> ??org.apache.axiom.om.impl.common.serializer.pull.Navigator#loadNamespaces?? 
> getting stuck in while-true loop when document has multiple redundant 
> namespace declarations like this one
> {code:xml}
> 
> http://schemas.xmlsoap.org/soap/envelope/;
>   xmlns:m="ns://example">
> 
> 
> 
> 1
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-487) IllegalStateException when parsing Source document

2016-10-09 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15560075#comment-15560075
 ] 

Hudson commented on AXIOM-487:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2784 (See 
[https://builds.apache.org/job/axiom-trunk/2784/])
Add an assertion about the behavior of DOM's lookupNamespaceURI method in the 
presence of a namespace declaration added using a namespace unaware API (namely 
setAttribute). This corresponds to the case described in AXIOM-487. (veithen: 
rev 1763981)
* (edit) 
axiom/testing/dom-testsuite/src/main/java/org/apache/axiom/ts/dom/DOMTestSuiteBuilder.java
* (add) 
axiom/testing/dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestLookupNamespaceURINamespaceDeclarationAsNSUnawareAttribute.java


> IllegalStateException when parsing Source document
> --
>
> Key: AXIOM-487
> URL: https://issues.apache.org/jira/browse/AXIOM-487
> Project: Axiom
>  Issue Type: Bug
>Affects Versions: 1.2.17, 1.2.19
>Reporter: Victor
>
> Hello,
> I tried to parse a java.xml.transform.Source (a DOMSource) using the 
> following code:
> {code}
> final OMXMLParserWrapper builder = 
> OMXMLBuilderFactory.createOMBuilder(factory, source);
> final OMElement bodyContent = builder.getDocumentElement();
> {code}
> The document contains:
> {code:xml}
> 
>  xmlns:tns="http://petals.ow2.org/talend/ArticleImporterJob/; 
> xmlns:jaxb="http://jaxb.dev.java.net/array;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> 
> 
> 0
> 
> 
> 
> 
>  xmlns:xop="http://www.w3.org/2004/08/xop/include; href="cid:fileResult" />
> 
> 
> 
> 
> 
> {code}
> And I got the following error:
> {noformat}
> java.lang.IllegalStateException
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$updateLocalName(AxiomNamedInformationItemSupport.aj:142)
>   at 
> org.apache.axiom.om.impl.llom.OMAttributeImpl.updateLocalName(OMAttributeImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$updateLocalName(AxiomNamedInformationItemSupport.aj)
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$coreGetLocalName(AxiomNamedInformationItemSupport.aj:147)
>   at 
> org.apache.axiom.om.impl.llom.OMAttributeImpl.coreGetLocalName(OMAttributeImpl.java:1)
>   at 
> org.apache.axiom.core.NSAwareAttributeMatcher.getName(NSAwareAttributeMatcher.java:84)
>   at 
> org.apache.axiom.core.CoreElementSupport.ajc$interMethod$org_apache_axiom_core_CoreElementSupport$org_apache_axiom_core_CoreElement$coreSetAttribute(CoreElementSupport.aj:96)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.coreSetAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$internalAppendAttribute(AxiomElementSupport.aj:282)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalAppendAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$internalAppendAttribute(AxiomElementSupport.aj)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$addAttribute(AxiomElementSupport.aj:296)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.addAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$addAttribute(AxiomElementSupport.aj)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$addAttribute(AxiomElementSupport.aj:312)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.addAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.builder.StAXBuilder.processAttributes(StAXBuilder.java:247)
>   at 
>

[jira] [Commented] (AXIOM-487) IllegalStateException when processing DOMSource with namespace unaware attributes

2016-10-09 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15560667#comment-15560667
 ] 

Hudson commented on AXIOM-487:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2788 (See 
[https://builds.apache.org/job/axiom-trunk/2788/])
AXIOM-487: Change the methods that create builders from DOM trees so that 
namespace unaware nodes are converted to namespace aware nodes (if this can be 
done without knowing the namespace context) or trigger meaningful exceptions. 
(veithen: rev 1764013)
* (edit) 
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/common/factory/BuilderSpec.java
* (add) 
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/common/factory/NSUnawareNodeFilter.java
* (add) 
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/common/factory/NSUnawareNodeFilterHandler.java
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java
* (add) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestCreateOMBuilderFromDOMWithNSUnawareNamespaceDeclaration.java
* (add) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestCreateOMBuilderFromDOMWithNSUnawarePrefixedAttribute.java
* (add) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestCreateOMBuilderFromDOMWithNSUnawareUnprefixedAttribute.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/OMElementSubject.java


> IllegalStateException when processing DOMSource with namespace unaware 
> attributes
> -
>
> Key: AXIOM-487
> URL: https://issues.apache.org/jira/browse/AXIOM-487
> Project: Axiom
>  Issue Type: Bug
>  Components: DOOM, LLOM
>Affects Versions: 1.2.17, 1.2.19
>Reporter: Victor
>Priority: Minor
>
> Hello,
> I tried to parse a java.xml.transform.Source (a DOMSource) using the 
> following code:
> {code}
> final OMXMLParserWrapper builder = 
> OMXMLBuilderFactory.createOMBuilder(factory, source);
> final OMElement bodyContent = builder.getDocumentElement();
> {code}
> The document contains:
> {code:xml}
> 
>  xmlns:tns="http://petals.ow2.org/talend/ArticleImporterJob/; 
> xmlns:jaxb="http://jaxb.dev.java.net/array;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> 
> 
> 0
> 
> 
> 
> 
>  xmlns:xop="http://www.w3.org/2004/08/xop/include; href="cid:fileResult" />
> 
> 
> 
> 
> 
> {code}
> And I got the following error:
> {noformat}
> java.lang.IllegalStateException
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$updateLocalName(AxiomNamedInformationItemSupport.aj:142)
>   at 
> org.apache.axiom.om.impl.llom.OMAttributeImpl.updateLocalName(OMAttributeImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$updateLocalName(AxiomNamedInformationItemSupport.aj)
>   at 
> org.apache.axiom.om.impl.common.AxiomNamedInformationItemSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomNamedInformationItemSupport$org_apache_axiom_om_impl_intf_AxiomNamedInformationItem$coreGetLocalName(AxiomNamedInformationItemSupport.aj:147)
>   at 
> org.apache.axiom.om.impl.llom.OMAttributeImpl.coreGetLocalName(OMAttributeImpl.java:1)
>   at 
> org.apache.axiom.core.NSAwareAttributeMatcher.getName(NSAwareAttributeMatcher.java:84)
>   at 
> org.apache.axiom.core.CoreElementSupport.ajc$interMethod$org_apache_axiom_core_CoreElementSupport$org_apache_axiom_core_CoreElement$coreSetAttribute(CoreElementSupport.aj:96)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.coreSetAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethod$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$internalAppendAttribute(AxiomElementSupport.aj:282)
>   at 
> org.apache.axiom.om.impl.llom.OMElementImpl.internalAppendAttribute(OMElementImpl.java:1)
>   at 
> org.apache.axiom.om.impl.common.AxiomElementSupport.ajc$interMethodDispatch1$org_apache_axiom_om_impl_common_AxiomElementSupport$org_apache_axiom_om_impl_intf_AxiomElement$internalAppendAttribute(AxiomElementSupport.aj)
>   at 
>

[jira] [Commented] (AXIOM-397) OMChildrenNamespaceIterator.isEqual ignores second parameter

2017-04-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973501#comment-15973501
 ] 

Hudson commented on AXIOM-397:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #52 (See 
[https://builds.apache.org/job/axiom-1.2.x/52/])
AXIOM-397: Merge r1791831 to the 1.2 branch. (veithen: rev 1791832)
* (edit) axiom
* (edit) 
axiom/axiom-compat/src/main/java/org/apache/axiom/om/impl/traverse/OMChildrenNamespaceIterator.java


> OMChildrenNamespaceIterator.isEqual ignores second parameter
> 
>
> Key: AXIOM-397
> URL: https://issues.apache.org/jira/browse/AXIOM-397
> Project: Axiom
>  Issue Type: Bug
>  Components: DOOM, LLOM
>Affects Versions: 1.2.9, 1.2.12
> Environment: N/A
>Reporter: Simon Matic Langford
>Assignee: Andreas Veithen
> Fix For: 1.2.13
>
>
> Whilst debugging an issue with SOAPHeader.getChildrenWithNamespaceURI() we 
> discovered that OMChildrenNamespaceIterator.isEqual() ignores the 
> "currentQName" parameter. This renders it rather useless. We found on 1.2.9, 
> but have verified it's not fixed in 1.2.12 and can't see an existing issue 
> for it in any of the unreleased versions:
> public boolean isEqual(QName searchQName, QName currentQName) {
> return 
> searchQName.getNamespaceURI().equals(searchQName.getNamespaceURI());
> }
> should read:
> public boolean isEqual(QName searchQName, QName currentQName) {
> return 
> searchQName.getNamespaceURI().equals(currentQName.getNamespaceURI());
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-397) OMChildrenNamespaceIterator.isEqual ignores second parameter

2017-04-18 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973448#comment-15973448
 ] 

Hudson commented on AXIOM-397:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2826 (See 
[https://builds.apache.org/job/axiom-trunk/2826/])
Apply the fix for AXIOM-397 to the deprecated copy of 
OMChildrenNamespaceIterator in axiom-compat as well. (veithen: rev 1791831)
* (edit) 
axiom/axiom-compat/src/main/java/org/apache/axiom/om/impl/traverse/OMChildrenNamespaceIterator.java


> OMChildrenNamespaceIterator.isEqual ignores second parameter
> 
>
> Key: AXIOM-397
> URL: https://issues.apache.org/jira/browse/AXIOM-397
> Project: Axiom
>  Issue Type: Bug
>  Components: DOOM, LLOM
>Affects Versions: 1.2.9, 1.2.12
> Environment: N/A
>Reporter: Simon Matic Langford
>Assignee: Andreas Veithen
> Fix For: 1.2.13
>
>
> Whilst debugging an issue with SOAPHeader.getChildrenWithNamespaceURI() we 
> discovered that OMChildrenNamespaceIterator.isEqual() ignores the 
> "currentQName" parameter. This renders it rather useless. We found on 1.2.9, 
> but have verified it's not fixed in 1.2.12 and can't see an existing issue 
> for it in any of the unreleased versions:
> public boolean isEqual(QName searchQName, QName currentQName) {
> return 
> searchQName.getNamespaceURI().equals(searchQName.getNamespaceURI());
> }
> should read:
> public boolean isEqual(QName searchQName, QName currentQName) {
> return 
> searchQName.getNamespaceURI().equals(currentQName.getNamespaceURI());
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (WODEN-243) Code error in org.apache.woden.internal.DOMWSDLWriter

2017-08-20 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/WODEN-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134470#comment-16134470
 ] 

Hudson commented on WODEN-243:
--

FAILURE: Integrated in Jenkins build woden-trunk #1231 (See 
[https://builds.apache.org/job/woden-trunk/1231/])
WODEN-243: Fix obvious bug. (veithen: rev 1805564)
* (edit) 
woden/woden-core/src/main/java/org/apache/woden/internal/DOMWSDLWriter.java


> Code error in org.apache.woden.internal.DOMWSDLWriter
> -
>
> Key: WODEN-243
> URL: https://issues.apache.org/jira/browse/WODEN-243
> Project: Woden
>  Issue Type: Bug
>  Components: Parser
>Affects Versions: M10
>Reporter: Jeff Thomas
>
> Looks like a small error in the DOMWSDLWriter:
> The check on line 767 should be against the 'interfaceName' and not the 
> 'name' attribute.
> {code:java}
> 760  QName name = service.getName();
> 761   if (name != null){
> 762   DOMUtils.printAttribute(Constants.ATTR_NAME,
> 763   name.getLocalPart(),
> 764   pw);
> 765   }
> 766   QName interfaceName = service.getInterfaceName();
> 767   if (name != null){
> 768   
> 769   
> DOMUtils.printQualifiedAttribute(Constants.ATTR_INTERFACE,
> 770   interfaceName,des, pw);
> 771   }
> {code}
> This could lead to a NullPointerException in printQualifiedAttribute.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-467) Cannot read "quoted-printable" encoded data from MIME part

2017-05-14 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16009730#comment-16009730
 ] 

Hudson commented on AXIOM-467:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2835 (See 
[https://builds.apache.org/job/axiom-trunk/2835/])
Upgrade mime4j and remove the workaround for AXIOM-467. (veithen: rev 1795105)
* (edit) axiom/axiom-api/src/main/java/org/apache/axiom/mime/MultipartBody.java
* (edit) axiom/axiom-api/src/main/java/org/apache/axiom/mime/PartImpl.java
* (delete) 
axiom/axiom-api/src/main/java/org/apache/axiom/mime/QuotedPrintableInputStream.java
* (edit) axiom/pom.xml


> Cannot read "quoted-printable" encoded data from MIME part
> --
>
> Key: AXIOM-467
> URL: https://issues.apache.org/jira/browse/AXIOM-467
> Project: Axiom
>  Issue Type: Bug
>  Components: API
>Affects Versions: 1.2.13, 1.2.14
>Reporter: Detelin Hadzhiev
>Assignee: Andreas Veithen
> Fix For: 1.2.15
>
> Attachments: axiom-1.2.13.patch, axiom_1.2.7.patch, 
> MtomInvalidQPAttachment.txt
>
>
> Processing "quoted-printable" encoded data in the axiom v.1.2.13 seems to be 
> backward incompatible as it was in the axiom. 1.2.7.
> I provided one and the same test case which illustrates how the test is 
> working in the axiom 1.2.7 but not in 1.2.13.
> In the axiom 1.2.13 I got the following exception:
> org.apache.axiom.om.OMException: org.apache.axiom.ext.io.StreamCopyException: 
> Error reading from source
>   at 
> org.apache.axiom.attachments.PartContentFactory.createPartContent(PartContentFactory.java:153)
>   at org.apache.axiom.attachments.PartImpl.fetch(PartImpl.java:176)
>   at org.apache.axiom.attachments.PartImpl.getContent(PartImpl.java:149)
>   at 
> org.apache.axiom.attachments.PartImpl.getInputStream(PartImpl.java:224)
>   at 
> org.apache.axiom.attachments.PartDataSource.getInputStream(PartDataSource.java:44)
>   at javax.activation.DataHandler.getInputStream(DataHandler.java:238)
>   at 
> org.apache.axiom.attachments.QuotedPrintablePartTest.testReadStreamFromPart(QuotedPrintablePartTest.java:38)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at junit.framework.TestCase.runTest(TestCase.java:168)
>   at junit.framework.TestCase.runBare(TestCase.java:134)
>   at junit.framework.TestResult$1.protect(TestResult.java:110)
>   at junit.framework.TestResult.runProtected(TestResult.java:128)
>   at junit.framework.TestResult.run(TestResult.java:113)
>   at junit.framework.TestCase.run(TestCase.java:124)
>   at junit.framework.TestSuite.runTest(TestSuite.java:243)
>   at junit.framework.TestSuite.run(TestSuite.java:238)
>   at 
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.axiom.ext.io.StreamCopyException: Error reading from 
> source
>   at 
> org.apache.axiom.attachments.utils.BAAOutputStream.readFrom(BAAOutputStream.java:114)
>   at 
> org.apache.axiom.attachments.impl.BufferUtils.inputStream2OutputStream(BufferUtils.java:76)
>   at 
> org.apache.axiom.attachments.PartContentFactory.createPartContent(PartContentFactory.java:119)
>   ... 24 more
> Caused by: java.io.IOException: Found LF without CR
>   at 
> org.apache.james.mime4j.codec.QuotedPrintableInputStream.read0(QuotedPrintableInputStream.java:195)
>   at 
> org.apache.james.mime4j.codec.QuotedPrintableInputStream.read(QuotedPrintableInputStream.java:317)
>   at 
> org.apache.axiom.attachments.utils.BAAOutputStream.readFrom(BAAOutputStream.java:112)
>   ... 26 more
> The root cause of this exception is that AXIOM forces usage of the STRICT 
> mode of MIME4J for decoding found in org.apache.axiom.attachments.MIMEMessage 
> class
> MimeConfig config = new MimeConfig();
> config.setStrictParsing(true);
> The default behavior MIME4J is SILENT(relaxed)  mode, if the strict parsing 
> is not enforced that the test will pass successfully.



--
This message was sent

[jira] [Commented] (AXIOM-424) axiom bundles does not have MANIFEST.MF as first entry of the zip

2017-05-22 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16019635#comment-16019635
 ] 

Hudson commented on AXIOM-424:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2853 (See 
[https://builds.apache.org/job/axiom-trunk/2853/])
Use maven-bundle-plugin instead of maven-shade-plugin to include aspects and 
components into OSGi bundles. This should also solve AXIOM-424. (veithen: rev 
1795801)
* (edit) axiom/aspects/core-aspects/pom.xml
* (edit) axiom/aspects/dom-aspects/pom.xml
* (edit) axiom/aspects/fom-aspects/pom.xml
* (edit) axiom/aspects/om-aspects/pom.xml
* (edit) axiom/aspects/pom.xml
* (edit) axiom/aspects/shared-aspects/pom.xml
* (edit) axiom/axiom-api/pom.xml
* (edit) axiom/buildutils/pom.xml
* (delete) axiom/buildutils/shade-osgi
* (edit) axiom/components/base64-utils/pom.xml
* (edit) axiom/components/core-streams/pom.xml
* (edit) axiom/components/pom.xml
* (edit) axiom/components/xml-utils/pom.xml
* (edit) axiom/implementations/axiom-dom/pom.xml
* (edit) axiom/implementations/axiom-impl/pom.xml
* (edit) axiom/implementations/fom-impl/pom.xml
* (edit) axiom/implementations/pom.xml
* (edit) axiom/pom.xml


> axiom bundles does not have MANIFEST.MF as first entry of the zip
> -
>
> Key: AXIOM-424
> URL: https://issues.apache.org/jira/browse/AXIOM-424
> Project: Axiom
>  Issue Type: Bug
>  Components: DOOM, LLOM
>Affects Versions: 1.2.13
> Environment: Karaf 2.2.6
>Reporter: Tomas Forsman
>
> The problem occurs when trying to install axiom-impl (or axiom-dom) from 
> within a karaf-feature
> 
> 
> mvn:org.apache.ws.commons.axiom/axiom-api/1.2.13
> mvn:org.apache.ws.commons.axiom/axiom-dom/1.2.13
> mvn:org.apache.ws.commons.axiom/axiom-impl/1.2.13
> 
> Typeing "feature:install axiom-test" from within karaf will give the 
> following error:
> "Error executing command: Manifest not present in the first entry of the zip 
> mvn:org.apache.ws.commons.axiom/axiom-impl/1.2.13"
> OpenJPA had the same issue and has solved it: 
> https://issues.apache.org/jira/browse/OPENJPA-1737
> "This issue only shows up when you do a features:install because the
> features service is looking at the MANIFEST.MF right upfront to
> determine if it needs to install the bundle or if there's already a
> suitable bundle available in the container." -- 
> http://mail-archives.apache.org/mod_mbox/karaf-user/201106.mbox/%3cbanlktim7gvyowqwazryufoohcj0la2y...@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-311) Improve the Axiom test suite

2017-05-27 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027386#comment-16027386
 ] 

Hudson commented on AXIOM-311:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2857 (See 
[https://builds.apache.org/job/axiom-trunk/2857/])
AXIOM-311: Remove redundant test and eliminate dependency between old-tests and 
the axiom-api test-jar. (veithen: rev 1796374)
* (edit) axiom/systests/old-tests/pom.xml
* (delete) 
axiom/systests/old-tests/src/test/java/org/apache/axiom/om/SpacesTest.java
* (delete) axiom/systests/old-tests/src/test/resources/spaces.xml
* (delete) axiom/systests/old-tests/src/test/resources/spaces2.xml
AXIOM-311: Migrate StAXOMBuilderTest. (veithen: rev 1796371)
* (delete) 
axiom/systests/old-tests/src/test/java/org/apache/axiom/om/impl/builder
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java
* (add) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestClose.java


> 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
>
> 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 was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-311) Improve the Axiom test suite

2017-05-27 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027594#comment-16027594
 ] 

Hudson commented on AXIOM-311:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2860 (See 
[https://builds.apache.org/job/axiom-trunk/2860/])
AXIOM-311: Remove the axiom-api test-jar. (veithen: rev 1796444)
* (edit) axiom/axiom-api/pom.xml
* (delete) 
axiom/axiom-api/src/test/resources/soap/soap11/additional-element-after-body.xml
* (delete) axiom/axiom-api/src/test/resources/soap/soap11/bodyNotQualified.xml
* (delete) axiom/axiom-api/src/test/resources/soap/soap11/empty-header.xml
* (delete) axiom/axiom-api/src/test/resources/soap/soap11/emtyBodymessage.xml
* (delete) 
axiom/axiom-api/src/test/resources/soap/soap11/faultelements-with-comment.xml
* (delete) axiom/axiom-api/src/test/resources/soap/soap11/minimalMessage.xml
* (delete) 
axiom/axiom-api/src/test/resources/soap/soap11/reallyReallyBigMessage.xml
* (delete) axiom/axiom-api/src/test/resources/soap/soap11/soapfault.xml
* (delete) axiom/axiom-api/src/test/resources/soap/soap11/whitespacedMessage.xml
* (delete) axiom/axiom-api/src/test/resources/soap/soap12
* (edit) axiom/implementations/axiom-dom/pom.xml
* (edit) axiom/implementations/axiom-impl/pom.xml
* (add) axiom/testing/axiom-testsuite/src/main/resources/soap
* (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/additional-element-after-body.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/bodyNotQualified.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/empty-header.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/emtyBodymessage.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/faultelements-with-comment.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/minimalMessage.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/reallyReallyBigMessage.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/soapfault.xml
* (add) 
axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/whitespacedMessage.xml
* (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap12


> 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
>
> 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

[jira] [Commented] (AXIOM-375) Simplify the OMElement#declareNamespace(String, String) API

2017-06-04 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/AXIOM-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036239#comment-16036239
 ] 

Hudson commented on AXIOM-375:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2878 (See 
[https://builds.apache.org/job/axiom-trunk/2878/])
AXIOM-375: Remove the legacy behavior for declareNamespace. (veithen: rev 
1797563)
* (edit) 
axiom/aspects/om-aspects/src/main/java/org/apache/axiom/om/impl/mixin/AxiomElementSupport.aj
* (edit) axiom/axiom-api/src/main/java/org/apache/axiom/om/OMElement.java
* (edit) axiom/src/site/markdown/release-notes/1.3.0.md
* (edit) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java
* (add) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestDeclareNamespaceWithEmptyPrefix.java
* (delete) 
axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestDeclareNamespaceWithGeneratedPrefix2.java


> Simplify the OMElement#declareNamespace(String, String) API
> ---
>
> Key: AXIOM-375
> URL: https://issues.apache.org/jira/browse/AXIOM-375
> Project: Axiom
>  Issue Type: Improvement
>  Components: API
>Reporter: Andreas Veithen
>Priority: Minor
> Fix For: 1.3.0
>
>
> OMElement#declareNamespace(String, String) auto-generates a prefix if the 
> prefix is either null or the empty string. There are several issues with this:
> 1. It is inconsistent with other APIs (in particular 
> OMElement#declareNamespace(OMNamespace) which make a distinction between null 
> (indicating that a prefix should be generated) and the empty string (meaning 
> the default namespace).
> 2. It is not possible to use OMElement#declareNamespace(String, String) to 
> declare a default namespace. This is especially annoying when the prefix is 
> provided as a variable, in which case one has to write something like this:
> if (prefix.length() == 0) {
> nextElem.declareDefaultNamespace(uri);
> } else {
> nextElem.declareNamespace(uri, prefix);
> }
> 3. It is obviously not necessary to support two different ways to indicate 
> that a prefix should be generated. One (prefix == null) should be enough.
> This should be changed in the next major release (1.3). To make the 
> transition easier, the Javadoc in 1.2.x should be updated to indicate that 
> using an empty string is deprecated and the code should generate a warning if 
> the method is invoked in this way.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-40) XmlSchemaForm Turkish Character Problem

2017-05-04 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997334#comment-15997334
 ] 

Hudson commented on XMLSCHEMA-40:
-

SUCCESS: Integrated in Jenkins build xmlschema-trunk #207 (See 
[https://builds.apache.org/job/xmlschema-trunk/207/])
[XMLSCHEMA-40] Don't use the locale/toLowerCase and instead use the raw 
strings.  Performs better as well. (dkulp: rev 1793859)
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/XmlSchemaForm.java


> XmlSchemaForm Turkish Character Problem
> ---
>
> Key: XMLSCHEMA-40
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-40
> Project: XmlSchema
>  Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Java 8
> Locale Turkish (TR)
> -Duser.language=tr
>Reporter: Özhan Düz
>Assignee: Daniel Kulp
> Fix For: 2.2.2
>
>
> Hi,
> org.apache.ws.commons.schema.XmlSchemaForm.toString() returns
> *qualıfıed* instead of *qualified* (dotless i).
> Possible correct solution:
> {code:java}
> @Override
> public String toString() {
> return super.toString().toLowerCase(Locale.ENGLISH);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-44) Make XmlSchemaCollection get* APIs null-safe.

2017-05-04 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997409#comment-15997409
 ] 

Hudson commented on XMLSCHEMA-44:
-

SUCCESS: Integrated in Jenkins build xmlschema-trunk #208 (See 
[https://builds.apache.org/job/xmlschema-trunk/208/])
[XMLSCHEMA-44] Make XmlSchemaCollection get* APIs null-safe.  Patch from Gary 
Gregory applied (dkulp: rev 1793862)
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java


> Make XmlSchemaCollection get* APIs null-safe.
> -
>
> Key: XMLSCHEMA-44
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-44
> Project: XmlSchema
>  Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Gary Gregory
>Assignee: Daniel Kulp
> Fix For: 2.2.2
>
> Attachments: ggregory-xmlschema-core-null-safe.diff
>
>
> Make XmlSchemaCollection get* APIs null-safe.
> The following methods in XmlSchemaCollection throw an NPE when given null as 
> input. 
> This patch adds null guard clauses to each method.
> - org.apache.ws.commons.schema.XmlSchemaCollection.getAttributeByQName(QName)
> - org.apache.ws.commons.schema.XmlSchemaCollection.getElementByQName(QName)
> - 
> org.apache.ws.commons.schema.XmlSchemaCollection.getAttributeGroupByQName(QName)
> - org.apache.ws.commons.schema.XmlSchemaCollection.getGroupByQName(QName)
> - org.apache.ws.commons.schema.XmlSchemaCollection.getNotationByQName(QName)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-52) Downloads page doesn't provide checksums or signatures

2018-05-29 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493307#comment-16493307
 ] 

Hudson commented on XMLSCHEMA-52:
-

SUCCESS: Integrated in Jenkins build xmlschema-trunk #238 (See 
[https://builds.apache.org/job/xmlschema-trunk/238/])
XMLSCHEMA-52 - Downloads page doesn't provide checksums or signatures 
(coheigea: rev 1832438)
* (edit) src/site/apt/index.apt
* (edit) src/site/site.xml
* (add) src/site/xdoc
* (add) src/site/xdoc/download.xml


> Downloads page doesn't provide checksums or signatures
> --
>
> Key: XMLSCHEMA-52
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-52
> Project: XmlSchema
>  Issue Type: Bug
>Reporter: Mike Kienenberger
>Priority: Major
>
> There's no XML Schema project download page.  The link immediately redirects 
> to the mirror download page.
> [http://www.apache.org/dyn/closer.cgi/ws/xmlschema/]
>  
> No project download page means no ability to find and download the checksum 
> and signature files to verify the integrity of the release.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-53) Illegal reflective access by org.apache.ws.commons.schema.utils.DOMUtil

2018-08-06 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570044#comment-16570044
 ] 

Hudson commented on XMLSCHEMA-53:
-

SUCCESS: Integrated in Jenkins build xmlschema-trunk #251 (See 
[https://builds.apache.org/job/xmlschema-trunk/251/])
XMLSCHEMA-53: Drop support for DOM 2. (veithen: rev 1837502)
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/utils/DOMUtil.java


> Illegal reflective access by org.apache.ws.commons.schema.utils.DOMUtil 
> 
>
> Key: XMLSCHEMA-53
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-53
> Project: XmlSchema
>  Issue Type: Bug
>Reporter: Matthew Chegash
>Priority: Major
>
> When using java 10, the following compile-time warning occurs:
> WARNING: An illegal reflective access operation has occurred
>  WARNING: Illegal reflective access by 
> org.apache.ws.commons.schema.utils.DOMUtil 
> ([file:/workforce/builds/current_integration/workforce/web/WEB-INF/lib/XmlSchema-1.4.7.jar|file:///workforce/builds/current_integration/workforce/web/WEB-INF/lib/XmlSchema-1.4.7.jar])
>  to method 
> com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.getXmlEncoding()
>  WARNING: Please consider reporting this to the maintainers of 
> org.apache.ws.commons.schema.utils.DOMUtil
>  WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
>  WARNING: All illegal access operations will be denied in a future release



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-492) Axiom unable to parse MTOM (SOAP 1.2) messages generated by JAX-WS

2018-11-12 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684533#comment-16684533
 ] 

Hudson commented on AXIOM-492:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #79 (See 
[https://builds.apache.org/job/axiom-1.2.x/79/])
Backport fix for AXIOM-492 (r1846368) to the 1.2 branch. (veithen: rev 1846473)
* (edit) axiom
* (edit) 
axiom/axiom-api/src/main/java/org/apache/axiom/om/OMXMLBuilderFactory.java
* (edit) axiom/pom.xml
* (add) axiom/systests/jaxws-tests
* (edit) axiom/systests/jaxws-tests/pom.xml
* (edit) axiom/systests/jaxws-tests/src/test/java/MTOMTest.java
* (edit) axiom/systests/pom.xml
* (edit) axiom/testing
* (edit) axiom/testing/spring-ws-testsuite/pom.xml


> Axiom unable to parse MTOM (SOAP 1.2) messages generated by JAX-WS
> --
>
> Key: AXIOM-492
> URL: https://issues.apache.org/jira/browse/AXIOM-492
> Project: Axiom
>  Issue Type: Bug
>Affects Versions: 1.2.21
>Reporter: Andreas Veithen
>Assignee: Andreas Veithen
>Priority: Major
> Fix For: 1.2.22
>
>
> This problem was originally reported here: 
> https://stackoverflow.com/questions/53044283/.
> Axiom fails to parse MTOM messages generated by the JAX-WS reference 
> implementation. This occurs only with SOAP 1.2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-492) Axiom unable to parse MTOM (SOAP 1.2) messages generated by JAX-WS

2018-11-11 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683104#comment-16683104
 ] 

Hudson commented on AXIOM-492:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2977 (See 
[https://builds.apache.org/job/axiom-trunk/2977/])
AXIOM-492: Fix incorrect parsing of MIME headers for MTOM. (veithen: rev 
1846368)
* (edit) axiom/axiom-api/pom.xml
* (edit) 
axiom/axiom-api/src/main/java/org/apache/axiom/om/OMXMLBuilderFactory.java
* (edit) axiom/pom.xml
* (add) axiom/systests/jaxws-tests
* (add) axiom/systests/jaxws-tests/pom.xml
* (add) axiom/systests/jaxws-tests/src
* (add) axiom/systests/jaxws-tests/src/test
* (add) axiom/systests/jaxws-tests/src/test/java
* (add) axiom/systests/jaxws-tests/src/test/java/MTOMTest.java
* (add) axiom/systests/jaxws-tests/src/test/wsdl
* (add) axiom/systests/jaxws-tests/src/test/wsdl/image-upload.wsdl
* (edit) axiom/systests/pom.xml
* (edit) axiom/testing/spring-ws-testsuite/pom.xml


> Axiom unable to parse MTOM (SOAP 1.2) messages generated by JAX-WS
> --
>
> Key: AXIOM-492
> URL: https://issues.apache.org/jira/browse/AXIOM-492
> Project: Axiom
>  Issue Type: Bug
>Affects Versions: 1.2.21
>Reporter: Andreas Veithen
>Assignee: Andreas Veithen
>Priority: Major
>
> This problem was originally reported here: 
> https://stackoverflow.com/questions/53044283/.
> Axiom fails to parse MTOM messages generated by the JAX-WS reference 
> implementation. This occurs only with SOAP 1.2.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-493) LifecycleManagerImpl doesn't delete FileAccesor references correctly

2018-11-15 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688661#comment-16688661
 ] 

Hudson commented on AXIOM-493:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2979 (See 
[https://builds.apache.org/job/axiom-trunk/2979/])
AXIOM-493: Fix memory leak in LifecycleManagerImpl.

Patch provided by Mustafa Solmaz.

No regression test here because we would like to get rid of that class in a 
future Axiom version anyway.

This closes #2. (veithen: rev 1846677)
* (edit) 
axiom/axiom-api/src/main/java/org/apache/axiom/attachments/lifecycle/impl/LifecycleManagerImpl.java


> LifecycleManagerImpl doesn't delete FileAccesor references correctly
> 
>
> Key: AXIOM-493
> URL: https://issues.apache.org/jira/browse/AXIOM-493
> Project: Axiom
>  Issue Type: Bug
>  Components: API
>Affects Versions: 1.2.21
>Reporter: Mustafa Solmaz
>Priority: Major
>
> Hi,
> we had a memory leak on our webservice project. When debugging, we noticed 
> that the LifecycleManagerImpl does not clean up its hashtable correctly. 
> While looking through the code, I noticed that the _create_ (line 72) method 
> fills the table with the filename, but uses the file name reference on 
> _delete_ (line 91, 138, 206).
> Kind regards,
> Mustafa



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-493) LifecycleManagerImpl doesn't delete FileAccesor references correctly

2018-11-15 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688699#comment-16688699
 ] 

Hudson commented on AXIOM-493:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #80 (See 
[https://builds.apache.org/job/axiom-1.2.x/80/])
AXIOM-493: Merge r1846677 to the 1.2 branch. (veithen: rev 1846678)
* (edit) axiom
* (edit) 
axiom/axiom-api/src/main/java/org/apache/axiom/attachments/lifecycle/impl/LifecycleManagerImpl.java


> LifecycleManagerImpl doesn't delete FileAccesor references correctly
> 
>
> Key: AXIOM-493
> URL: https://issues.apache.org/jira/browse/AXIOM-493
> Project: Axiom
>  Issue Type: Bug
>  Components: API
>Affects Versions: 1.2.21
>Reporter: Mustafa Solmaz
>Priority: Major
>
> Hi,
> we had a memory leak on our webservice project. When debugging, we noticed 
> that the LifecycleManagerImpl does not clean up its hashtable correctly. 
> While looking through the code, I noticed that the _create_ (line 72) method 
> fills the table with the filename, but uses the file name reference on 
> _delete_ (line 91, 138, 206).
> Kind regards,
> Mustafa



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-494) Google Truth 0.37 compatibility

2019-01-06 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735176#comment-16735176
 ] 

Hudson commented on AXIOM-494:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #90 (See 
[https://builds.apache.org/job/axiom-1.2.x/90/])
AXIOM-494: Merge r1796489 and r1850517 to the 1.2 branch. (veithen: rev 1850543)
* (edit) axiom
* (edit) axiom/pom.xml
* (edit) axiom/testing
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/AbstractOMContainerSubject.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/AxiomTruth.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/OMAttributeSubject.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/OMContainerSubject.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/OMElementSubject.java
* (edit) axiom/testing/xml-truth
* (edit) 
axiom/testing/xml-truth/src/main/java/org/apache/axiom/truth/xml/XMLSubject.java
* (edit) 
axiom/testing/xml-truth/src/main/java/org/apache/axiom/truth/xml/XMLTruth.java


> Google Truth 0.37 compatibility
> ---
>
> Key: AXIOM-494
> URL: https://issues.apache.org/jira/browse/AXIOM-494
> Project: Axiom
>  Issue Type: Task
>Reporter: Simon Legner
>Priority: Major
>  Labels: xml-truth
> Attachments: google-truth-042.patch
>
>
> [Google Truth 0.37|https://github.com/google/truth/releases/tag/release_0_37] 
> deprecated/removed {{FailureStrategy}} in favour of {{FailureMetadata}} as 
> well as {{SubjectFactory}} in favour of {{Subject.Factory}}.
> The attached patch addresses those issues and updates Google Truth to 0.42



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-494) Google Truth 0.37 compatibility

2019-01-05 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735052#comment-16735052
 ] 

Hudson commented on AXIOM-494:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2994 (See 
[https://builds.apache.org/job/axiom-trunk/2994/])
AXIOM-494: Upgrade to Google Truth 0.42.

Patch provided by Simon Legner.

This closes #6. (veithen: rev 1850517)
* (edit) axiom/pom.xml
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/AbstractOMContainerSubject.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/AxiomTruth.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/OMAttributeSubject.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/OMContainerSubject.java
* (edit) 
axiom/testing/axiom-truth/src/main/java/org/apache/axiom/truth/OMElementSubject.java
* (edit) 
axiom/testing/xml-truth/src/main/java/org/apache/axiom/truth/xml/XMLSubject.java
* (edit) 
axiom/testing/xml-truth/src/main/java/org/apache/axiom/truth/xml/XMLTruth.java


> Google Truth 0.37 compatibility
> ---
>
> Key: AXIOM-494
> URL: https://issues.apache.org/jira/browse/AXIOM-494
> Project: Axiom
>  Issue Type: Task
>Reporter: Simon Legner
>Priority: Major
>  Labels: xml-truth
> Attachments: google-truth-042.patch
>
>
> [Google Truth 0.37|https://github.com/google/truth/releases/tag/release_0_37] 
> deprecated/removed {{FailureStrategy}} in favour of {{FailureMetadata}} as 
> well as {{SubjectFactory}} in favour of {{Subject.Factory}}.
> The attached patch addresses those issues and updates Google Truth to 0.42



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-494) Google Truth 0.37 compatibility

2019-01-08 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16737677#comment-16737677
 ] 

Hudson commented on AXIOM-494:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #2996 (See 
[https://builds.apache.org/job/axiom-trunk/2996/])
Fix Javadoc error related to the changes introduced by AXIOM-494. (veithen: rev 
1850810)
* (edit) 
axiom/testing/xml-truth/src/main/java/org/apache/axiom/truth/xml/XMLTruth.java


> Google Truth 0.37 compatibility
> ---
>
> Key: AXIOM-494
> URL: https://issues.apache.org/jira/browse/AXIOM-494
> Project: Axiom
>  Issue Type: Task
>Reporter: Simon Legner
>Priority: Major
>  Labels: xml-truth
> Fix For: 1.2.22
>
> Attachments: google-truth-042.patch
>
>
> [Google Truth 0.37|https://github.com/google/truth/releases/tag/release_0_37] 
> deprecated/removed {{FailureStrategy}} in favour of {{FailureMetadata}} as 
> well as {{SubjectFactory}} in favour of {{Subject.Factory}}.
> The attached patch addresses those issues and updates Google Truth to 0.42



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-494) Google Truth 0.37 compatibility

2019-01-08 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16737696#comment-16737696
 ] 

Hudson commented on AXIOM-494:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #94 (See 
[https://builds.apache.org/job/axiom-1.2.x/94/])
AXIOM-494: Merge r1850810 to the 1.2 branch. (veithen: rev 1850811)
* (edit) axiom
* (edit) axiom/testing
* (edit) axiom/testing/xml-truth
* (edit) 
axiom/testing/xml-truth/src/main/java/org/apache/axiom/truth/xml/XMLTruth.java


> Google Truth 0.37 compatibility
> ---
>
> Key: AXIOM-494
> URL: https://issues.apache.org/jira/browse/AXIOM-494
> Project: Axiom
>  Issue Type: Task
>Reporter: Simon Legner
>Priority: Major
>  Labels: xml-truth
> Fix For: 1.2.22
>
> Attachments: google-truth-042.patch
>
>
> [Google Truth 0.37|https://github.com/google/truth/releases/tag/release_0_37] 
> deprecated/removed {{FailureStrategy}} in favour of {{FailureMetadata}} as 
> well as {{SubjectFactory}} in favour of {{Subject.Factory}}.
> The attached patch addresses those issues and updates Google Truth to 0.42



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-495) MemoryBlobInputStream reset() broken

2019-02-16 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770235#comment-16770235
 ] 

Hudson commented on AXIOM-495:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #97 (See 
[https://builds.apache.org/job/axiom-1.2.x/97/])
AXIOM-495: Merge r1853727 to the 1.2 branch (with changes). (veithen: rev 
1853728)
* (edit) axiom
* (edit) 
axiom/axiom-api/src/main/java/org/apache/axiom/blob/MemoryBlobInputStream.java
* (add) 
axiom/axiom-api/src/test/java/org/apache/axiom/blob/suite/TestResetWithoutMark.java
* (edit) 
axiom/axiom-api/src/test/java/org/apache/axiom/blob/suite/WritableBlobTestSuiteBuilder.java


> MemoryBlobInputStream reset() broken
> 
>
> Key: AXIOM-495
> URL: https://issues.apache.org/jira/browse/AXIOM-495
> Project: Axiom
>  Issue Type: Bug
>Affects Versions: 1.2.20
>Reporter: Ralf Hauser
>Assignee: Andreas Veithen
>Priority: Minor
>
> When markSupported() is true, doing a reset() before the first read should be 
> possible.
> With org.apache.axiom.blob.MemoryBlobInputStream this is not true, while 
> before reset(), available() returns a value > 0, after reset(), it is 0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-495) MemoryBlobInputStream reset() broken

2019-02-16 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770231#comment-16770231
 ] 

Hudson commented on AXIOM-495:
--

SUCCESS: Integrated in Jenkins build axiom-trunk #3004 (See 
[https://builds.apache.org/job/axiom-trunk/3004/])
AXIOM-495: Correct behavior of MemoryBlobInputStream when reset() is called 
without mark(). (veithen: rev 1853727)
* (edit) 
axiom/axiom-api/src/main/java/org/apache/axiom/blob/MemoryBlobInputStreamImpl.java
* (add) 
axiom/axiom-api/src/test/java/org/apache/axiom/blob/suite/TestResetWithoutMark.java
* (edit) 
axiom/axiom-api/src/test/java/org/apache/axiom/blob/suite/WritableBlobTestSuiteBuilder.java


> MemoryBlobInputStream reset() broken
> 
>
> Key: AXIOM-495
> URL: https://issues.apache.org/jira/browse/AXIOM-495
> Project: Axiom
>  Issue Type: Bug
>Affects Versions: 1.2.20
>Reporter: Ralf Hauser
>Assignee: Andreas Veithen
>Priority: Minor
>
> When markSupported() is true, doing a reset() before the first read should be 
> possible.
> With org.apache.axiom.blob.MemoryBlobInputStream this is not true, while 
> before reset(), available() returns a value > 0, after reset(), it is 0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-56) Element defined in a base type sometimes isn't visited by an XmlSchemaWalker's visitor

2019-05-31 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852816#comment-16852816
 ] 

Hudson commented on XMLSCHEMA-56:
-

SUCCESS: Integrated in Jenkins build xmlschema-trunk #307 (See 
[https://builds.apache.org/job/xmlschema-trunk/307/])
XMLSCHEMA-56 - Element defined in a base type sometimes isn't visited by an 
XmlSchemaWalker's visitor. Thanks to kgi. This closes #4. (coheigea: rev 
1860436)
* (add) 
xmlschema-walker/src/main/java/org/apache/ws/commons/schema/walker/SchemasByNamespace.java
* (edit) 
xmlschema-walker/src/main/java/org/apache/ws/commons/schema/walker/XmlSchemaScope.java
* (edit) 
xmlschema-walker/src/main/java/org/apache/ws/commons/schema/walker/XmlSchemaWalker.java
* (add) 
xmlschema-walker/src/test/java/org/apache/ws/commons/schema/walker/TestMultipleFilesPerNamespace.java
* (edit) 
xmlschema-walker/src/test/java/org/apache/ws/commons/schema/walker/TestSchemaWalker.java
* (add) xmlschema-walker/src/test/resources/test_mfpn2_included1.xsd
* (add) xmlschema-walker/src/test/resources/test_mfpn2_included2.xsd
* (add) xmlschema-walker/src/test/resources/test_mfpn_included1.xsd
* (add) xmlschema-walker/src/test/resources/test_mfpn_included2.xsd
* (add) xmlschema-walker/src/test/resources/test_mfpn_included3.xsd
* (add) 
xmlschema-walker/src/test/resources/test_multiple_files_per_namespace.xsd
* (add) 
xmlschema-walker/src/test/resources/test_multiple_files_per_namespace2.xsd


> Element defined in a base type sometimes isn't visited by an 
> XmlSchemaWalker's visitor
> --
>
> Key: XMLSCHEMA-56
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-56
> Project: XmlSchema
>  Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: openSUSE Leap 15
> open-jdk 11 (but I've tried 1.8 and same thing happens)
> xmlschema 2.2.3 and 2.2.4 (core and walker)
>Reporter: Kevin
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.2.5
>
> Attachments: walk2.tar
>
>
> EDIT 9 May 2019: I have found the source of this bug. It is in the 
> org.apache.ws.commons.schema.walker package. Here, both the XmlSchemaWalker 
> and XmlSchemaScope classes use HashMaps to store XmlSchemas indexed by 
> namespace. For example, in the XmlSchemaWalker's first constructor, each 
> schema in the given XmlSchemaCollection (the argument) is added to 
> schemasByNamespace (the HashMap). The problem is that if two or more xsd 
> files have schemas with the same target namespace (which is legal, and indeed 
> useful), and they are in the schema collection (e.g. one file is included by 
> another using ), each call to schemasByNamespace.put(namespace, 
> schema) will overwrite the previously put schema for that namespace. Then, 
> for example, when XmlSchemaScope looks up a schema by namespace and calls 
> schema.getTypeByName(...) around line 326 that type will not be found unless 
> it was defined in the last schema for that namespace to be stored in the Map. 
> This results in the behaviour I reported, where an element in a base type 
> (i.e. one which was extended using ) was not visited by the 
> walker: the base type was not found because a schema with the same target 
> namespace defined in an included xsd file was found in the map instead of the 
> one defining the type.
> One way to remedy this is for the schemasByNamespace member variables in both 
> XmlSchemaWalker and XmlSchemaScope to store a list of schemas for each 
> namespace, i.e. be a Map> rather than a Map XmlSchema>. Then, whenever looking up, for example, a type defined in a 
> schema with a certain namespace, access the list of XmlSchemas using 
> schemasByNamespace.get(namespace), and then iterate through the list of 
> schemas calling getTypeByName(...) until the type in question is found.
> --- original bug report:
> (EDIT: I have attached a new version of the project (walk2.tar) which takes 
> the path to the xsd files as a command line argument. It should now be 
> possible to use the .class files without recompiling.)
> Hi,
> I have a strange issue where the element in a base type (i.e. one which is 
> extended by another type) is not visited by the xmlschema-walker. It is 
> strange because it only happens in some instances of the test project (i.e. 
> when I copy all project files to a new directory it will sometimes happen in 
> that directory and sometimes not!). I cannot for the life of me discern a 
> pattern.
> This occurs with both 2.2.3 and 2.2.4 of xmlschema (core and walker). I am on 
> openSUSE Leap 15 and openjdk 11 (but I've tried 1.8 and same thing happens).
> Please see my attached tar file. There are two xsd files in the "xsd" 
> directory. The first is "test.xsd". It defines a type "Test" which extends 
> the type

[jira] [Commented] (AXIOM-424) axiom bundles does not have MANIFEST.MF as first entry of the zip

2019-05-04 Thread Hudson (JIRA)



[ 
https://issues.apache.org/jira/browse/AXIOM-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833075#comment-16833075
 ] 

Hudson commented on AXIOM-424:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #100 (See 
[https://builds.apache.org/job/axiom-1.2.x/100/])
Merge r1795801 to the 1.2 branch. Should fix AXIOM-424. (veithen: rev 1858603)
* (edit) axiom
* (edit) axiom/aspects/core-aspects/pom.xml
* (edit) axiom/aspects/dom-aspects/pom.xml
* (edit) axiom/aspects/fom-aspects/pom.xml
* (edit) axiom/aspects/om-aspects/pom.xml
* (edit) axiom/aspects/pom.xml
* (edit) axiom/aspects/shared-aspects/pom.xml
* (edit) axiom/axiom-api/pom.xml
* (edit) axiom/axiom-c14n/pom.xml
* (edit) axiom/axiom-jaxb/pom.xml
* (edit) axiom/buildutils/pom.xml
* (delete) axiom/buildutils/shade-osgi
* (edit) axiom/components/xml-utils/pom.xml
* (edit) axiom/implementations/axiom-dom/pom.xml
* (edit) axiom/implementations/axiom-impl/pom.xml
* (edit) axiom/implementations/fom-impl
* (edit) axiom/implementations/fom-impl/pom.xml
* (edit) axiom/implementations/pom.xml
* (edit) axiom/pom.xml


> axiom bundles does not have MANIFEST.MF as first entry of the zip
> -
>
> Key: AXIOM-424
> URL: https://issues.apache.org/jira/browse/AXIOM-424
> Project: Axiom
>  Issue Type: Bug
>  Components: DOOM, LLOM
>Affects Versions: 1.2.13
> Environment: Karaf 2.2.6
>Reporter: Tomas Forsman
>Priority: Major
> Fix For: 1.2.23
>
>
> The problem occurs when trying to install axiom-impl (or axiom-dom) from 
> within a karaf-feature
> 
> 
> mvn:org.apache.ws.commons.axiom/axiom-api/1.2.13
> mvn:org.apache.ws.commons.axiom/axiom-dom/1.2.13
> mvn:org.apache.ws.commons.axiom/axiom-impl/1.2.13
> 
> Typeing "feature:install axiom-test" from within karaf will give the 
> following error:
> "Error executing command: Manifest not present in the first entry of the zip 
> mvn:org.apache.ws.commons.axiom/axiom-impl/1.2.13"
> OpenJPA had the same issue and has solved it: 
> https://issues.apache.org/jira/browse/OPENJPA-1737
> "This issue only shows up when you do a features:install because the
> features service is looking at the MANIFEST.MF right upfront to
> determine if it needs to install the bundle or if there's already a
> suitable bundle available in the container." -- 
> http://mail-archives.apache.org/mod_mbox/karaf-user/201106.mbox/%3cbanlktim7gvyowqwazryufoohcj0la2y...@mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-51) Problem with included schemas with attribute group references

2020-01-03 Thread Hudson (Jira)



[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007533#comment-17007533
 ] 

Hudson commented on XMLSCHEMA-51:
-

SUCCESS: Integrated in Jenkins build xmlschema-master #345 (See 
[https://builds.apache.org/job/xmlschema-master/345/])
XMLSCHEMA-51 Problem with included schemas with attribute group (coheigea: rev 
4980f932c5dda824f3c1ebaccf8b90da3f10e828)
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
* (add) xmlschema-core/src/test/resources/include-union-without-ns/root.xsd
* (add) xmlschema-core/src/test/resources/include-union-without-ns/datatypes.xsd
* (edit) xmlschema-core/src/test/java/tests/IncludeTest.java


> Problem with included schemas with attribute group references
> -
>
> Key: XMLSCHEMA-51
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-51
> Project: XmlSchema
>  Issue Type: Question
>Reporter: Fady Moussallam
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.2.5
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hello,
> I am using version 2.2.3.
> I have a problem with a combination of included schemas and attribute group 
> references.
> Say you have schemaA including schemaB. schemaB does not have a default 
> namespace, nor a target namespace, since it is meant to be included. It 
> therefore inherits the namespace of the including schema (in this case 
> schemaA).
> The problem arises if schemaB contains markup like this:
> {code}
> 
>  ...
>  
> {code}
> In org.apache.ws.commons.schema.SchemaBuilder#handleAttributeGroupRef the 
> reference QName is obtained with the getRefQName(String pName, Node pNode) 
> method.
> In this method, the namespace is derived using the 
> NodeNamespaceContext.getNamespaceContext(pNode) method. This one in turn 
> determines available namespaces directly from the DOM using 
> PrefixCollector.searchAllPrefixDeclarations(pNode).
> Problem is that from a DOM standpoint schemaB does not contain any namespace 
> declarations. So the reference QName end up having no namespace.
> This seems wrong and creates problems when later on you want to find the 
> referenced group using XmlSchemaCollection#getAttributeGroupByName(QName 
> name) which returns null.
> I can fix my issue in SchemaBuilder#getRefQName by doing this:
> {code}
> ...
> if (offset == -1) {
>  uri = pContext.getNamespaceURI(Constants.DEFAULT_NS_PREFIX);
>  if (Constants.NULL_NS_URI.equals(uri)) {
>  if (currentSchema.getLogicalTargetNamespace().isEmpty()) {
>  return new QName(Constants.NULL_NS_URI, pName);
>  } else {
>  return new QName(currentSchema.getLogicalTargetNamespace(), pName);
>  }
>  }
>  localName = pName;
>  prefix = Constants.DEFAULT_NS_PREFIX;
>  } else {
> ...
> {code}
> But I am not sure if there are any side effects.
> Any opinion or advice on this would be very appreciated.
> Thank you
>  
> Fady
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-51) Problem with included schemas with attribute group references

2020-01-03 Thread Hudson (Jira)



[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007507#comment-17007507
 ] 

Hudson commented on XMLSCHEMA-51:
-

FAILURE: Integrated in Jenkins build xmlschema-master-analysis #79 (See 
[https://builds.apache.org/job/xmlschema-master-analysis/79/])
XMLSCHEMA-51 Problem with included schemas with attribute group (coheigea: rev 
4980f932c5dda824f3c1ebaccf8b90da3f10e828)
* (edit) xmlschema-core/src/test/java/tests/IncludeTest.java
* (add) xmlschema-core/src/test/resources/include-union-without-ns/root.xsd
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
* (add) xmlschema-core/src/test/resources/include-union-without-ns/datatypes.xsd


> Problem with included schemas with attribute group references
> -
>
> Key: XMLSCHEMA-51
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-51
> Project: XmlSchema
>  Issue Type: Question
>Reporter: Fady Moussallam
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.2.5
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hello,
> I am using version 2.2.3.
> I have a problem with a combination of included schemas and attribute group 
> references.
> Say you have schemaA including schemaB. schemaB does not have a default 
> namespace, nor a target namespace, since it is meant to be included. It 
> therefore inherits the namespace of the including schema (in this case 
> schemaA).
> The problem arises if schemaB contains markup like this:
> {code}
> 
>  ...
>  
> {code}
> In org.apache.ws.commons.schema.SchemaBuilder#handleAttributeGroupRef the 
> reference QName is obtained with the getRefQName(String pName, Node pNode) 
> method.
> In this method, the namespace is derived using the 
> NodeNamespaceContext.getNamespaceContext(pNode) method. This one in turn 
> determines available namespaces directly from the DOM using 
> PrefixCollector.searchAllPrefixDeclarations(pNode).
> Problem is that from a DOM standpoint schemaB does not contain any namespace 
> declarations. So the reference QName end up having no namespace.
> This seems wrong and creates problems when later on you want to find the 
> referenced group using XmlSchemaCollection#getAttributeGroupByName(QName 
> name) which returns null.
> I can fix my issue in SchemaBuilder#getRefQName by doing this:
> {code}
> ...
> if (offset == -1) {
>  uri = pContext.getNamespaceURI(Constants.DEFAULT_NS_PREFIX);
>  if (Constants.NULL_NS_URI.equals(uri)) {
>  if (currentSchema.getLogicalTargetNamespace().isEmpty()) {
>  return new QName(Constants.NULL_NS_URI, pName);
>  } else {
>  return new QName(currentSchema.getLogicalTargetNamespace(), pName);
>  }
>  }
>  localName = pName;
>  prefix = Constants.DEFAULT_NS_PREFIX;
>  } else {
> ...
> {code}
> But I am not sure if there are any side effects.
> Any opinion or advice on this would be very appreciated.
> Thank you
>  
> Fady
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-58) Schema version not set

2020-01-02 Thread Hudson (Jira)



[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006761#comment-17006761
 ] 

Hudson commented on XMLSCHEMA-58:
-

FAILURE: Integrated in Jenkins build xmlschema-master-analysis #77 (See 
[https://builds.apache.org/job/xmlschema-master-analysis/77/])
XMLSCHEMA-58 - Schema version not set (coheigea: rev 
6e56c44c60b1ebaf44a6ea5267458b875405bfc8)
* (add) xmlschema-core/src/test/java/tests/VersionTest.java
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
* (add) xmlschema-core/src/test/resources/version.xsd


> Schema version not set
> --
>
> Key: XMLSCHEMA-58
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-58
> Project: XmlSchema
>  Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Christoph Hösler
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.2.5
>
>
> The version field in XmlSchema is not set in Schema Builder and therefore 
> XmlSchema#getVersion() will always return null.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (XMLSCHEMA-58) Schema version not set

2020-01-02 Thread Hudson (Jira)



[ 
https://issues.apache.org/jira/browse/XMLSCHEMA-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17006762#comment-17006762
 ] 

Hudson commented on XMLSCHEMA-58:
-

SUCCESS: Integrated in Jenkins build xmlschema-master #340 (See 
[https://builds.apache.org/job/xmlschema-master/340/])
XMLSCHEMA-58 - Schema version not set (coheigea: rev 
6e56c44c60b1ebaf44a6ea5267458b875405bfc8)
* (add) xmlschema-core/src/test/resources/version.xsd
* (add) xmlschema-core/src/test/java/tests/VersionTest.java
* (edit) 
xmlschema-core/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java


> Schema version not set
> --
>
> Key: XMLSCHEMA-58
> URL: https://issues.apache.org/jira/browse/XMLSCHEMA-58
> Project: XmlSchema
>  Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Christoph Hösler
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.2.5
>
>
> The version field in XmlSchema is not set in Schema Builder and therefore 
> XmlSchema#getVersion() will always return null.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-502) Unable to use AXIOM in GraalVM Native Image application

2020-04-18 Thread Hudson (Jira)



[ 
https://issues.apache.org/jira/browse/AXIOM-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17086570#comment-17086570
 ] 

Hudson commented on AXIOM-502:
--

FAILURE: Integrated in Jenkins build axiom-1.2.x #107 (See 
[https://builds.apache.org/job/axiom-1.2.x/107/])
AXIOM-502: make AXIOM usable in GraalVM Native Image (aschrijnen: rev 
af0f71e833a496298c43d83996ea97bc4f152b6b)
* (edit) 
aspects/core-aspects/src/main/java/org/apache/axiom/core/CoreParentNodeSupport.aj
* (add) 
aspects/core-aspects/src/main/java/org/apache/axiom/core/NodesIterator.java


> Unable to use AXIOM in GraalVM Native Image application
> ---
>
> Key: AXIOM-502
> URL: https://issues.apache.org/jira/browse/AXIOM-502
> Project: Axiom
>  Issue Type: Bug
>  Components: Core Model
>Affects Versions: 1.2.22
>Reporter: Auke Schrijnen
>Assignee: Andreas Veithen
>Priority: Major
> Fix For: 1.2.23
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When building an application using the GraalVM Native Image compiler it fails 
> when AXIOM is used in the application. The GraalVM compiler fails with the 
> exception java.lang.InternalError: Enclosing method not found. (see 
> [https://github.com/oracle/graal/issues/1438]).
> This seems to be caused by missing type information for an anonymous class in 
> CoreParentNodeSupport. The IntelliJ decompiler decompiles the codeGetNodes 
> method as return {{new 1(ajc$this_, ajc$this_, axis, type, semantics);}}, 
> where 1 is the missing type. The source of this code is the anonymous 
> AbstractNodeIterator implementation in CoreParentNodeSupport.aj.
> When using the latest AXIOM version from the master branch (1.3.0-SNAPSHOT) 
> the application builds fine since the anonymous class is replaced by a 
> concrete class.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] [Commented] (AXIOM-503) WARN org.apache.axiom.util.stax.dialect.StAXDialectDetector:214 - Unable to determine dialect of the StAX implementation at jar:file:woodstox-core-6.2.0.jar

2020-05-10 Thread Hudson (Jira)



[ 
https://issues.apache.org/jira/browse/AXIOM-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103957#comment-17103957
 ] 

Hudson commented on AXIOM-503:
--

SUCCESS: Integrated in Jenkins build axiom-1.2.x #114 (See 
[https://builds.apache.org/job/axiom-1.2.x/114/])
AXIOM-503: Partial cherry-pick of 1125d28 (veithen: rev 
647477a1afd1b6af3b06fda6396b91d907ea5a25)
* (edit) 
axiom-api/src/main/java/org/apache/axiom/util/stax/dialect/StAXDialectDetector.java


> WARN org.apache.axiom.util.stax.dialect.StAXDialectDetector:214 - Unable to 
> determine dialect of the StAX implementation at 
> jar:file:woodstox-core-6.2.0.jar
> 
>
> Key: AXIOM-503
> URL: https://issues.apache.org/jira/browse/AXIOM-503
> Project: Axiom
>  Issue Type: Bug
>Affects Versions: 1.2.22
>Reporter: Jeffrey Bennett
>Assignee: Andreas Veithen
>Priority: Major
>
> I am using the latest woodstox-core.jar (6.2.0 - April 2020) and axiom-api 
> (1.2.22, Jan 2019) and am finding that Axiom does not recognize this StAX 
> implementation.  The problem seems to be 
> StaxDialectDetector.detectDialectFromJarManifest(..) which has support for 
> woodstox major versions 3, 4,and 5, but not 6.x.  It falls into a default 
> case, which returns null, and causes a warning to be generated (and a 
> DialectUnknown to be utilized).  It's not clear if there are any negative 
> consequences other than the warning log - superficially, things appear OK.
> Not knowing any better, we are choosing to simply suppress the log.  Figured 
> a bug-report might be beneficial though.
>  
> [java] 19:22:44,807 DEBUG 
> org.apache.axiom.util.stax.dialect.StAXDialectDetector:261 - StAX 
> implementation at jar:file:woodstox-core-6.2.0.jar!/ is:
>  [java] Title: Woodstox
>  [java] Symbolic name: com.fasterxml.woodstox.woodstox-core
>  [java] Vendor: FasterXML
>  [java] Version: 6.2.0
>  [java] 19:22:44,808 WARN 
> org.apache.axiom.util.stax.dialect.StAXDialectDetector:214 - Unable to 
> determine dialect of the StAX implementation at 
> jar:file:woodstox-core-6.2.0.jar!/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

[jira] Created: (AXIS2-567) Slow class loading issue

2006-04-12 Thread rob hudson (JIRA)

Slow class loading issue


 Key: AXIS2-567
 URL: http://issues.apache.org/jira/browse/AXIS2-567
 Project: Apache Axis 2.0 (Axis2)
Type: Bug

Versions: 0.94
 Environment: WinXP Axis2 Tomcat
Reporter: rob hudson


When I first connect to my webservice I get a timeout. When I try to connect 
again it works fine. I've run tomcat in debug mode and found that the service 
is taking a while to load up required jar files. If I put these jar files in 
the shared/lib directory of tomcat my service works fine straight away. Is 
there any way to instantiate a service without performing a request on at (as 
I've been doing)? Otherwise this is a bug because the classloader is taking too 
long...

-- 
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

< 1 2 3 4

301 - 339 of 339 matches

Mail list logo