[jira] [Commented] (ARIES-1540) Blueprint NamespaceHandler can't resolve XSD in offline mode
[
https://issues.apache.org/jira/browse/ARIES-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15408734#comment-15408734
]
Niten Aggarwal commented on ARIES-1540:
---
Hi Guillaume,
Could you please let me know how to apply this fix in Karaf 4.0.5 as we are
facing same issue and cannot change aries blueprint version just by changing
features.xml. We are on karaf 4.0.5 and feature will be installed through nexus
repository directly so we cannot update this feature just for blueprint.core
version.
aries-proxy
mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.api/1.0.1
mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.cm/1.0.8
mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core.compatibility/1.0.0
mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.core/1.6.1
bundle
mvn:org.apache.karaf.bundle/org.apache.karaf.bundle.blueprintstate/4.0.5
osgi.service;effective:=active;objectClass=org.apache.aries.blueprint.services.ParserService,
osgi.extender;
osgi.extender="osgi.blueprint";uses:="org.osgi.service.blueprint.container,org.osgi.service.blueprint.reflect";version:Version="1.0"
> Blueprint NamespaceHandler can't resolve XSD in offline mode
>
>
> Key: ARIES-1540
> URL: https://issues.apache.org/jira/browse/ARIES-1540
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
>Affects Versions: blueprint-core-1.6.1
>Reporter: Jean-Baptiste Onofré
>Assignee: Guillaume Nodet
> Fix For: blueprint-core-1.6.2
>
>
> When the NamespaceHandler is offline, it fails to resolve the XSD:
> {code}
> 17:18:44,952 | WARN | pool-27-thread-1 | l$NamespaceHandlerSetImpl$Loader
> 544 | 16 - org.apache.aries.blueprint.core - 1.6.1 | Dynamically adding
> namespace handler http://cxf.apache.org/configuration/beans to bundle
> org.talend.esb.job.controller/6.2.0.SNAPSHOT
> 17:18:44,955 | WARN | pool-27-thread-1 | l$NamespaceHandlerSetImpl$Loader
> 544 | 16 - org.apache.aries.blueprint.core - 1.6.1 | Dynamically adding
> namespace handler http://cxf.apache.org/configuration/parameterized-types to
> bundle org.talend.esb.job.controller/6.2.0.SNAPSHOT
> 17:18:44,956 | ERROR | pool-27-thread-1 | container.BlueprintContainerImpl
> 437 | 16 - org.apache.aries.blueprint.core - 1.6.1 | Unable to start
> blueprint container for bundle org.talend.esb.job.controller/6.2.0.SNAPSHOT
> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name
> 'ptp:ParameterizedInt' to a(n) 'simpleType definition' component.
> at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)[:]
> at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)[:]
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.reportSchemaError(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseNamedAttr(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAttributeTraverser.traverseLocal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDAbstractTraverser.traverseAttrsAndAttrGrps(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseLocal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseNamedElement(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseGlobal(Unknown
> Source)[:]
> at
> org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown
> Source)[:]
> at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
> Source)[:]
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)[:]
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown
> Source)[:]
> at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown
> Source)[:]
> at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown
> Source)[:]
> at
>
[jira] [Resolved] (ARIES-1586) Async calls in fastbin
[ https://issues.apache.org/jira/browse/ARIES-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved ARIES-1586. Resolution: Fixed Assignee: Christian Schneider Fix Version/s: rsa-2.0.0 > Async calls in fastbin > -- > > Key: ARIES-1586 > URL: https://issues.apache.org/jira/browse/ARIES-1586 > Project: Aries > Issue Type: New Feature > Components: Remote Service Admin >Reporter: Johannes Utzig >Assignee: Christian Schneider > Fix For: rsa-2.0.0 > > > For long running remote calls it should be possible to make async remote > calls and receive e.g. a Future or osgi Promise as the result. > Details have been discussed here: > http://mail-archives.apache.org/mod_mbox/aries-dev/201607.mbox/%3CCAJLHLX_sh1oK1o2HurzvN8_kCKtegvmmf-pucJq3pTW92QqQQg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1586) Async calls in fastbin
[ https://issues.apache.org/jira/browse/ARIES-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407701#comment-15407701 ] ASF subversion and git services commented on ARIES-1586: Commit 42087ca275ad804ee8ff2fda97b6a5b480e3fd06 in aries-rsa's branch refs/heads/master from [~j.utzig] [ https://git-wip-us.apache.org/repos/asf?p=aries-rsa.git;h=42087ca ] [ARIES-1586] Async calls in fastbin remote methods can now return Future/CompletableFuture/Promise for async invocation. Also adds a Readme.md for fastbin closes #13 > Async calls in fastbin > -- > > Key: ARIES-1586 > URL: https://issues.apache.org/jira/browse/ARIES-1586 > Project: Aries > Issue Type: New Feature > Components: Remote Service Admin >Reporter: Johannes Utzig > > For long running remote calls it should be possible to make async remote > calls and receive e.g. a Future or osgi Promise as the result. > Details have been discussed here: > http://mail-archives.apache.org/mod_mbox/aries-dev/201607.mbox/%3CCAJLHLX_sh1oK1o2HurzvN8_kCKtegvmmf-pucJq3pTW92QqQQg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARIES-1588) Installation of subsystems fails due to uses constraint violation after exposing feature capabilities.
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Ross updated ARIES-1588:
-
Summary: Installation of subsystems fails due to uses constraint violation
after exposing feature capabilities. (was: Installation of subsystems fails
due to uses constraint violation)
> Installation of subsystems fails due to uses constraint violation after
> exposing feature capabilities.
> --
>
> Key: ARIES-1588
> URL: https://issues.apache.org/jira/browse/ARIES-1588
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Affects Versions: subsystem-2.1.0
>Reporter: Wouter Bancken
> Fix For: subsystem-2.1.0
>
> Attachments: pax-web-jetty-bundle-4.2.5.jar
>
>
> h4. Setup
> Two feature subsystems
> 1. Feature subsystem with fragment-hosts and fragments
> 2. Feature subsystem with other bundles
> Installation of the second subsystem fails
> h4. Issue
> Installation of the second subsystem fails with the message
> {quote}
> gogo: SubsystemException: org.osgi.service.resolver.ResolutionException: Uses
> constraint violation. Unable to resolve resource
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0] because it exports package
> 'org.apache.xbean.finder.archive' and is also exposed to it from resource
> org.apache.xbean.finder [98.0] via the following dependency chain:
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0]
> import: (osgi.wiring.package=org.apache.xbean.finder)
> export: osgi.wiring.package: org.apache.xbean.finder;
> uses:=org.apache.xbean.finder.archive
> export: osgi.wiring.package=org.apache.xbean.finder.archive
> org.apache.xbean.finder [98.0]
> {quote}
> Before failing a lot of similar messages are logged with the message "DEBUG:
> Candidate permutation failed due to a conflict between an export and import;
> will try another if possible."
> This is especially weird since pax-web-jetty-bundle does not expose the
> org.apache.xbean.finder.archive package (see attached Jar). Both
> pax-web-jetty-bundle and org.apache.xbean.finder are only present in the
> first subsystem.
> In our setup pax-web-jetty-bundle is a fragment-host for a fragment which is
> in the same (first) subsystem. Similar DEBUG statements are printed for other
> fragment-hosts in the first subsystem.
> The issue occurs since commit 4c0437de06f34321909a6132a7f2be163b2f6d5
> (ARIES-1443). In earlier versions, we had no issues for these subsystems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ARIES-1588) Installation of subsystems fails due to uses constraint violation
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Ross updated ARIES-1588:
-
Summary: Installation of subsystems fails due to uses constraint violation
(was: Installation of subsystems fails due to incorrectly detected export
packages)
> Installation of subsystems fails due to uses constraint violation
> -
>
> Key: ARIES-1588
> URL: https://issues.apache.org/jira/browse/ARIES-1588
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Affects Versions: subsystem-2.1.0
>Reporter: Wouter Bancken
> Fix For: subsystem-2.1.0
>
> Attachments: pax-web-jetty-bundle-4.2.5.jar
>
>
> h4. Setup
> Two feature subsystems
> 1. Feature subsystem with fragment-hosts and fragments
> 2. Feature subsystem with other bundles
> Installation of the second subsystem fails
> h4. Issue
> Installation of the second subsystem fails with the message
> {quote}
> gogo: SubsystemException: org.osgi.service.resolver.ResolutionException: Uses
> constraint violation. Unable to resolve resource
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0] because it exports package
> 'org.apache.xbean.finder.archive' and is also exposed to it from resource
> org.apache.xbean.finder [98.0] via the following dependency chain:
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0]
> import: (osgi.wiring.package=org.apache.xbean.finder)
> export: osgi.wiring.package: org.apache.xbean.finder;
> uses:=org.apache.xbean.finder.archive
> export: osgi.wiring.package=org.apache.xbean.finder.archive
> org.apache.xbean.finder [98.0]
> {quote}
> Before failing a lot of similar messages are logged with the message "DEBUG:
> Candidate permutation failed due to a conflict between an export and import;
> will try another if possible."
> This is especially weird since pax-web-jetty-bundle does not expose the
> org.apache.xbean.finder.archive package (see attached Jar). Both
> pax-web-jetty-bundle and org.apache.xbean.finder are only present in the
> first subsystem.
> In our setup pax-web-jetty-bundle is a fragment-host for a fragment which is
> in the same (first) subsystem. Similar DEBUG statements are printed for other
> fragment-hosts in the first subsystem.
> The issue occurs since commit 4c0437de06f34321909a6132a7f2be163b2f6d5
> (ARIES-1443). In earlier versions, we had no issues for these subsystems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to incorrectly detected export packages
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407645#comment-15407645
]
John Ross commented on ARIES-1588:
--
It would help if you're able to provide a set of subsystems that will reproduce
the issue. This could be an issue with subsystems, the resolver, or the
environment.
> Installation of subsystems fails due to incorrectly detected export packages
>
>
> Key: ARIES-1588
> URL: https://issues.apache.org/jira/browse/ARIES-1588
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Affects Versions: subsystem-2.1.0
>Reporter: Wouter Bancken
> Fix For: subsystem-2.1.0
>
> Attachments: pax-web-jetty-bundle-4.2.5.jar
>
>
> h4. Setup
> Two feature subsystems
> 1. Feature subsystem with fragment-hosts and fragments
> 2. Feature subsystem with other bundles
> Installation of the second subsystem fails
> h4. Issue
> Installation of the second subsystem fails with the message
> {quote}
> gogo: SubsystemException: org.osgi.service.resolver.ResolutionException: Uses
> constraint violation. Unable to resolve resource
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0] because it exports package
> 'org.apache.xbean.finder.archive' and is also exposed to it from resource
> org.apache.xbean.finder [98.0] via the following dependency chain:
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0]
> import: (osgi.wiring.package=org.apache.xbean.finder)
> export: osgi.wiring.package: org.apache.xbean.finder;
> uses:=org.apache.xbean.finder.archive
> export: osgi.wiring.package=org.apache.xbean.finder.archive
> org.apache.xbean.finder [98.0]
> {quote}
> Before failing a lot of similar messages are logged with the message "DEBUG:
> Candidate permutation failed due to a conflict between an export and import;
> will try another if possible."
> This is especially weird since pax-web-jetty-bundle does not expose the
> org.apache.xbean.finder.archive package (see attached Jar). Both
> pax-web-jetty-bundle and org.apache.xbean.finder are only present in the
> first subsystem.
> In our setup pax-web-jetty-bundle is a fragment-host for a fragment which is
> in the same (first) subsystem. Similar DEBUG statements are printed for other
> fragment-hosts in the first subsystem.
> The issue occurs since commit 4c0437de06f34321909a6132a7f2be163b2f6d5
> (ARIES-1443). In earlier versions, we had no issues for these subsystems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1565) Performance Improvement: unpack subsystem artifacts to tmp folder to avoid directly reading from zip archive
[ https://issues.apache.org/jira/browse/ARIES-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407635#comment-15407635 ] John Ross commented on ARIES-1565: -- It would go in as part of the next release. However, ARIES-1588 appears to be a blocker for you so that needs to be resolved as well. > Performance Improvement: unpack subsystem artifacts to tmp folder to avoid > directly reading from zip archive > > > Key: ARIES-1565 > URL: https://issues.apache.org/jira/browse/ARIES-1565 > Project: Aries > Issue Type: Improvement > Components: Subsystem, Util >Affects Versions: subsystem-2.0.8, util-1.1.2 >Reporter: Wouter Bancken > Attachments: 1565.patch, Call_Tree_2_0_8.html, > Call_Tree_John_Ross.html, Call_Tree_Wouter_Bancken.html, > aries1565-profile.png, test-service-subsystem-4.0.2-SNAPSHOT.esa > > > h4. Description > Aries copies ESA archives to a temporary zip file during the installation > phase. Afterwards, bundles are read directly from this temporary zip which > has a large impact on the startup performance of Aries applications. By > unpacking the esa artifact into the temporary folder it is unpacked only > once. Subsequent reads for the bundles (jars) can be read directly from the > folder. > h4. Pull request > https://github.com/apache/aries/compare/subsystem-2.0.x...WouterBanckenACA:io_performance_optimalisation?expand=1 > h4. Mailinglist > http://mail-archives.apache.org/mod_mbox/aries-user/201606.mbox/%3CCAL5nZgTq5FxDvURJbzcEZ9YHx6vTs3HAOuFYDYA3ec9OZbmwjA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARIES-1588) Installation of subsystems fails due to incorrectly detected export packages
[
https://issues.apache.org/jira/browse/ARIES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407619#comment-15407619
]
Tom De Wolf commented on ARIES-1588:
[~jwr...@us.ibm.com] any idea when a fix for this can be made or a roll-back of
the specific commit so that the next version of aries does not pose problems?
> Installation of subsystems fails due to incorrectly detected export packages
>
>
> Key: ARIES-1588
> URL: https://issues.apache.org/jira/browse/ARIES-1588
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
>Affects Versions: subsystem-2.1.0
>Reporter: Wouter Bancken
> Fix For: subsystem-2.1.0
>
> Attachments: pax-web-jetty-bundle-4.2.5.jar
>
>
> h4. Setup
> Two feature subsystems
> 1. Feature subsystem with fragment-hosts and fragments
> 2. Feature subsystem with other bundles
> Installation of the second subsystem fails
> h4. Issue
> Installation of the second subsystem fails with the message
> {quote}
> gogo: SubsystemException: org.osgi.service.resolver.ResolutionException: Uses
> constraint violation. Unable to resolve resource
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0] because it exports package
> 'org.apache.xbean.finder.archive' and is also exposed to it from resource
> org.apache.xbean.finder [98.0] via the following dependency chain:
> org.ops4j.pax.web.pax-web-jetty-bundle [124.0]
> import: (osgi.wiring.package=org.apache.xbean.finder)
> export: osgi.wiring.package: org.apache.xbean.finder;
> uses:=org.apache.xbean.finder.archive
> export: osgi.wiring.package=org.apache.xbean.finder.archive
> org.apache.xbean.finder [98.0]
> {quote}
> Before failing a lot of similar messages are logged with the message "DEBUG:
> Candidate permutation failed due to a conflict between an export and import;
> will try another if possible."
> This is especially weird since pax-web-jetty-bundle does not expose the
> org.apache.xbean.finder.archive package (see attached Jar). Both
> pax-web-jetty-bundle and org.apache.xbean.finder are only present in the
> first subsystem.
> In our setup pax-web-jetty-bundle is a fragment-host for a fragment which is
> in the same (first) subsystem. Similar DEBUG statements are printed for other
> fragment-hosts in the first subsystem.
> The issue occurs since commit 4c0437de06f34321909a6132a7f2be163b2f6d5
> (ARIES-1443). In earlier versions, we had no issues for these subsystems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ARIES-1565) Performance Improvement: unpack subsystem artifacts to tmp folder to avoid directly reading from zip archive
[ https://issues.apache.org/jira/browse/ARIES-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407616#comment-15407616 ] Tom De Wolf commented on ARIES-1565: [~jwr...@us.ibm.com] any idea when this can be integrated? > Performance Improvement: unpack subsystem artifacts to tmp folder to avoid > directly reading from zip archive > > > Key: ARIES-1565 > URL: https://issues.apache.org/jira/browse/ARIES-1565 > Project: Aries > Issue Type: Improvement > Components: Subsystem, Util >Affects Versions: subsystem-2.0.8, util-1.1.2 >Reporter: Wouter Bancken > Attachments: 1565.patch, Call_Tree_2_0_8.html, > Call_Tree_John_Ross.html, Call_Tree_Wouter_Bancken.html, > aries1565-profile.png, test-service-subsystem-4.0.2-SNAPSHOT.esa > > > h4. Description > Aries copies ESA archives to a temporary zip file during the installation > phase. Afterwards, bundles are read directly from this temporary zip which > has a large impact on the startup performance of Aries applications. By > unpacking the esa artifact into the temporary folder it is unpacked only > once. Subsequent reads for the bundles (jars) can be read directly from the > folder. > h4. Pull request > https://github.com/apache/aries/compare/subsystem-2.0.x...WouterBanckenACA:io_performance_optimalisation?expand=1 > h4. Mailinglist > http://mail-archives.apache.org/mod_mbox/aries-user/201606.mbox/%3CCAL5nZgTq5FxDvURJbzcEZ9YHx6vTs3HAOuFYDYA3ec9OZbmwjA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
