[jira] [Created] (KARAF-4543) Karaf core reloads unintended when custom log appenders are used
Volker Althaus created KARAF-4543: - Summary: Karaf core reloads unintended when custom log appenders are used Key: KARAF-4543 URL: https://issues.apache.org/jira/browse/KARAF-4543 Project: Karaf Issue Type: Bug Components: karaf-core, karaf-feature Affects Versions: 4.0.5 Environment: Windows 7 Reporter: Volker Althaus We use custom log appenders and now recognize unintended reloads of the Karaf core on clean start. See mailing list thread "[Karaf 4.0.5] Strange console log messages when using custom log appenders", 2016-05-11 It looks like the "framework" feature introduced in [KARAF-4129] leads to this behavior. The error disappears when this feature is removed from the boot features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (KARAF-4543) Karaf core reloads unintended when custom log appenders are used
[ https://issues.apache.org/jira/browse/KARAF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306615#comment-15306615 ] Volker Althaus edited comment on KARAF-4543 at 5/30/16 12:51 PM: - Attached a sample fragment. Copy the content of the file into a vanilla Karaf 4.0.5 and watch the clean startup. was (Author: valthaus): A sample fragment. Copy the content of the file into a vanilla Karaf 4.0.5 and watch the clean startup. > Karaf core reloads unintended when custom log appenders are used > > > Key: KARAF-4543 > URL: https://issues.apache.org/jira/browse/KARAF-4543 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.5 > Environment: Windows 7 >Reporter: Volker Althaus > Attachments: my-custom-logging-appender-1.0.zip > > > We use custom log appenders and now recognize unintended reloads of the Karaf > core on clean start. See mailing list thread "[Karaf 4.0.5] Strange console > log messages when using custom log appenders", 2016-05-11 > It looks like the "framework" feature introduced in [KARAF-4129] leads to > this behavior. The error disappears when this feature is removed from the > boot features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4543) Karaf core reloads unintended when custom log appenders are used
[ https://issues.apache.org/jira/browse/KARAF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Althaus updated KARAF-4543: -- Attachment: my-custom-logging-appender-1.0.zip A sample fragment. Copy the content of the file into a vanilla Karaf 4.0.5 and watch the clean startup. > Karaf core reloads unintended when custom log appenders are used > > > Key: KARAF-4543 > URL: https://issues.apache.org/jira/browse/KARAF-4543 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.5 > Environment: Windows 7 >Reporter: Volker Althaus > Attachments: my-custom-logging-appender-1.0.zip > > > We use custom log appenders and now recognize unintended reloads of the Karaf > core on clean start. See mailing list thread "[Karaf 4.0.5] Strange console > log messages when using custom log appenders", 2016-05-11 > It looks like the "framework" feature introduced in [KARAF-4129] leads to > this behavior. The error disappears when this feature is removed from the > boot features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4543) Karaf core reloads unintended when custom log appenders are used
[ https://issues.apache.org/jira/browse/KARAF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Althaus updated KARAF-4543: -- Attachment: logging-appender.zip A simple Maven project which creates a custom logging appender fragment. Copy the content of the resulting zip file into a vanilla Karaf 4.0.5 and watch the startup behavior. > Karaf core reloads unintended when custom log appenders are used > > > Key: KARAF-4543 > URL: https://issues.apache.org/jira/browse/KARAF-4543 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.5 > Environment: Windows 7 >Reporter: Volker Althaus > Attachments: logging-appender.zip > > > We use custom log appenders and now recognize unintended reloads of the Karaf > core on clean start. See mailing list thread "[Karaf 4.0.5] Strange console > log messages when using custom log appenders", 2016-05-11 > It looks like the "framework" feature introduced in [KARAF-4129] leads to > this behavior. The error disappears when this feature is removed from the > boot features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (KARAF-4543) Karaf core reloads unintended when custom log appenders are used
[ https://issues.apache.org/jira/browse/KARAF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306606#comment-15306606 ] Volker Althaus edited comment on KARAF-4543 at 5/30/16 12:46 PM: - Attached a simple Maven project which creates a custom logging appender fragment. Copy the content of the resulting zip file into a vanilla Karaf 4.0.5 and watch the startup behavior. was (Author: valthaus): A simple Maven project which creates a custom logging appender fragment. Copy the content of the resulting zip file into a vanilla Karaf 4.0.5 and watch the startup behavior. > Karaf core reloads unintended when custom log appenders are used > > > Key: KARAF-4543 > URL: https://issues.apache.org/jira/browse/KARAF-4543 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.5 > Environment: Windows 7 >Reporter: Volker Althaus > Attachments: logging-appender.zip > > > We use custom log appenders and now recognize unintended reloads of the Karaf > core on clean start. See mailing list thread "[Karaf 4.0.5] Strange console > log messages when using custom log appenders", 2016-05-11 > It looks like the "framework" feature introduced in [KARAF-4129] leads to > this behavior. The error disappears when this feature is removed from the > boot features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4543) Karaf core reloads unintended when custom log appenders are used
[ https://issues.apache.org/jira/browse/KARAF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Althaus updated KARAF-4543: -- Attachment: (was: logging-appender.zip) > Karaf core reloads unintended when custom log appenders are used > > > Key: KARAF-4543 > URL: https://issues.apache.org/jira/browse/KARAF-4543 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.5 > Environment: Windows 7 >Reporter: Volker Althaus > > We use custom log appenders and now recognize unintended reloads of the Karaf > core on clean start. See mailing list thread "[Karaf 4.0.5] Strange console > log messages when using custom log appenders", 2016-05-11 > It looks like the "framework" feature introduced in [KARAF-4129] leads to > this behavior. The error disappears when this feature is removed from the > boot features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (KARAF-4543) Karaf core reloads unintended when custom log appenders are used
[ https://issues.apache.org/jira/browse/KARAF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Althaus updated KARAF-4543: -- Comment: was deleted (was: Attached a simple Maven project which creates a custom logging appender fragment. Copy the content of the resulting zip file into a vanilla Karaf 4.0.5 and watch the startup behavior.) > Karaf core reloads unintended when custom log appenders are used > > > Key: KARAF-4543 > URL: https://issues.apache.org/jira/browse/KARAF-4543 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.5 > Environment: Windows 7 >Reporter: Volker Althaus > > We use custom log appenders and now recognize unintended reloads of the Karaf > core on clean start. See mailing list thread "[Karaf 4.0.5] Strange console > log messages when using custom log appenders", 2016-05-11 > It looks like the "framework" feature introduced in [KARAF-4129] leads to > this behavior. The error disappears when this feature is removed from the > boot features. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4498) Fileinstall polls too early on clean start
[
https://issues.apache.org/jira/browse/KARAF-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15339100#comment-15339100
]
Volker Althaus commented on KARAF-4498:
---
My bundle (58) seems to be installed correctly:
56 | Active | 30 | 1.0.0.6 | Apache ServiceMix :: Bundles ::
aopalliance
57 | Active | 30 | 3.2.0.1 | Apache ServiceMix :: Bundles :: cglib
58 | Active | 80 | 1.0.0| bug-use-case
59 | Active | 10 | 2.2.6.1 | Apache ServiceMix :: Bundles ::
jaxb-impl
60 | Active | 30 | 0.3.11.1 | Apache ServiceMix :: Bundles ::
not-yet-commons-ssl
The diagraph.json of
mvn:org.apache.karaf.features/org.apache.karaf.features.core/4.0.4:
{"regions":{"root":[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76]},"edges":[]}
> Fileinstall polls too early on clean start
> --
>
> Key: KARAF-4498
> URL: https://issues.apache.org/jira/browse/KARAF-4498
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.4
> Environment: Windows 7
>Reporter: Volker Althaus
> Attachments: bug-screencast.mp4, bug-setup.zip
>
>
> In the deploy folder is a bundle with a Spring driven Camel route. As boot
> features "camel-spring" and "spring-dm" are given.
> On a clean Karaf start in nearly 9 out of 10 times the CamelContext is
> started, but the "context-list" command output is empty, the Camel route
> itself however is started and running correctly.
> Is looks like fileinstall does not regard the property
> "felix.fileinstall.active.level=80" and polls too early, so likely some
> BundleListeners like the one which registers the CamelContext for the
> "context-list" command are not available yet.
> A real hot deploy at runtime works all time, the context appears correctly.
> In Karaf 2 and 3 this issue did not appear.
> Attached to this issue is a setup with the hot deploy folder and a customized
> features.cfg. Simple extract into a vanilla Karaf 4.0.4. Because it is a
> timing problem and it could be not reproducible, on demand I can also attach
> a screencast which shows the bug on my system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-4498) Fileinstall polls too early on clean start
[ https://issues.apache.org/jira/browse/KARAF-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Althaus updated KARAF-4498: -- Attachment: bug-screencast.mp4 Screencast which shows the setup and two clean Karaf starts. The first one works and the CamelContext is there, the second one fails and the context list remains empty. > Fileinstall polls too early on clean start > -- > > Key: KARAF-4498 > URL: https://issues.apache.org/jira/browse/KARAF-4498 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.0.4 > Environment: Windows 7 >Reporter: Volker Althaus > Attachments: bug-screencast.mp4, bug-setup.zip > > > In the deploy folder is a bundle with a Spring driven Camel route. As boot > features "camel-spring" and "spring-dm" are given. > On a clean Karaf start in nearly 9 out of 10 times the CamelContext is > started, but the "context-list" command output is empty, the Camel route > itself however is started and running correctly. > Is looks like fileinstall does not regard the property > "felix.fileinstall.active.level=80" and polls too early, so likely some > BundleListeners like the one which registers the CamelContext for the > "context-list" command are not available yet. > A real hot deploy at runtime works all time, the context appears correctly. > In Karaf 2 and 3 this issue did not appear. > Attached to this issue is a setup with the hot deploy folder and a customized > features.cfg. Simple extract into a vanilla Karaf 4.0.4. Because it is a > timing problem and it could be not reproducible, on demand I can also attach > a screencast which shows the bug on my system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-4498) Fileinstall polls too early on clean start
Volker Althaus created KARAF-4498: - Summary: Fileinstall polls too early on clean start Key: KARAF-4498 URL: https://issues.apache.org/jira/browse/KARAF-4498 Project: Karaf Issue Type: Bug Affects Versions: 4.0.4 Environment: Windows 7 Reporter: Volker Althaus In the deploy folder is a bundle with a Spring driven Camel route. As boot features "camel-spring" and "spring-dm" are given. On a clean Karaf start in nearly 9 out of 10 times the CamelContext is started, but the "context-list" command output is empty, the Camel route itself however is started and running correctly. Is looks like fileinstall does not regard the property "felix.fileinstall.active.level=80" and polls too early, so likely some BundleListeners like the one which registers the CamelContext for the "context-list" command are not available yet. A real hot deploy at runtime works all time, the context appears correctly. In Karaf 2 and 3 this issue did not appear. Attached to this issue is a setup with the hot deploy folder and a customized features.cfg. Simple extract into a vanilla Karaf 4.0.4. Because it is a timing problem and it could be not reproducible, on demand I can also attach a screencast which shows the bug on my system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-4498) Fileinstall polls too early on clean start
[ https://issues.apache.org/jira/browse/KARAF-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Althaus updated KARAF-4498: -- Attachment: bug-setup.zip Setup on a vanilla Karaf 4.0.4 > Fileinstall polls too early on clean start > -- > > Key: KARAF-4498 > URL: https://issues.apache.org/jira/browse/KARAF-4498 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.0.4 > Environment: Windows 7 >Reporter: Volker Althaus > Attachments: bug-setup.zip > > > In the deploy folder is a bundle with a Spring driven Camel route. As boot > features "camel-spring" and "spring-dm" are given. > On a clean Karaf start in nearly 9 out of 10 times the CamelContext is > started, but the "context-list" command output is empty, the Camel route > itself however is started and running correctly. > Is looks like fileinstall does not regard the property > "felix.fileinstall.active.level=80" and polls too early, so likely some > BundleListeners like the one which registers the CamelContext for the > "context-list" command are not available yet. > A real hot deploy at runtime works all time, the context appears correctly. > In Karaf 2 and 3 this issue did not appear. > Attached to this issue is a setup with the hot deploy folder and a customized > features.cfg. Simple extract into a vanilla Karaf 4.0.4. Because it is a > timing problem and it could be not reproducible, on demand I can also attach > a screencast which shows the bug on my system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-4498) Fileinstall polls too early on clean start
[ https://issues.apache.org/jira/browse/KARAF-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374665#comment-15374665 ] Volker Althaus commented on KARAF-4498: --- For your information: We solved the problem with the context-list command by adding the Spring and Camel bundles to the startup.properties: mvn\:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1 = 50 mvn\:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_6 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.2.0_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-aop/3.2.14.RELEASE_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-beans/3.2.14.RELEASE_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-context/3.2.14.RELEASE_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-context-support/3.2.14.RELEASE_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-expression/3.2.14.RELEASE_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-jms/3.2.14.RELEASE_1 = 50 mvn\:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-tx/3.2.14.RELEASE_1 = 50 mvn\:org.springframework.osgi/spring-osgi-annotation/1.2.1 = 50 mvn\:org.springframework.osgi/spring-osgi-core/1.2.1 = 50 mvn\:org.springframework.osgi/spring-osgi-extender/1.2.1 = 50 mvn\:org.springframework.osgi/spring-osgi-io/1.2.1 = 50 mvn\:org.apache.camel/camel-spring/2.16.3 = 50 mvn\:org.apache.camel/camel-core/2.16.3 = 50 We know this is a only a workaround which works in our custom distribution, so we hope that the base problem with fileinstall would solved in another way. > Fileinstall polls too early on clean start > -- > > Key: KARAF-4498 > URL: https://issues.apache.org/jira/browse/KARAF-4498 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.0.4 > Environment: Windows 7 >Reporter: Volker Althaus > Attachments: bug-screencast.mp4, bug-setup.zip > > > In the deploy folder is a bundle with a Spring driven Camel route. As boot > features "camel-spring" and "spring-dm" are given. > On a clean Karaf start in nearly 9 out of 10 times the CamelContext is > started, but the "context-list" command output is empty, the Camel route > itself however is started and running correctly. > Is looks like fileinstall does not regard the property > "felix.fileinstall.active.level=80" and polls too early, so likely some > BundleListeners like the one which registers the CamelContext for the > "context-list" command are not available yet. > A real hot deploy at runtime works all time, the context appears correctly. > In Karaf 2 and 3 this issue did not appear. > Attached to this issue is a setup with the hot deploy folder and a customized > features.cfg. Simple extract into a vanilla Karaf 4.0.4. Because it is a > timing problem and it could be not reproducible, on demand I can also attach > a screencast which shows the bug on my system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-5808) bundle:install mvn: with range crashes immediately
Volker Althaus created KARAF-5808: - Summary: bundle:install mvn: with range crashes immediately Key: KARAF-5808 URL: https://issues.apache.org/jira/browse/KARAF-5808 Project: Karaf Issue Type: Bug Components: karaf-shell Affects Versions: 4.2.0 Environment: Win 7 Java 8 Reporter: Volker Althaus When trying to install a bundle with mvn protocol and a range, the console (karaf, client and SSH) crashes/shuts down immediately without any exception. It doesn't matter if an appropriate bundle within the range is available, the error does always occour. Simple example: $ bunde:install mvn:foo/bar/[1,2) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KARAF-6005) Resolve of bundle with version range in a feature only works with ".m2" and not with "system" directory
Volker Althaus created KARAF-6005:
-
Summary: Resolve of bundle with version range in a feature only
works with ".m2" and not with "system" directory
Key: KARAF-6005
URL: https://issues.apache.org/jira/browse/KARAF-6005
Project: Karaf
Issue Type: Bug
Components: karaf
Affects Versions: 4.2.1
Reporter: Volker Althaus
I defined a feature with a ranged bundle version:
mvn:de.some.api/api/[1,2)
If a bundle within that range lies within the global/user Maven repo ".m2", the
bundle gets resolved.
If it resides only within the "system" folder of Karaf I get an exception:
{noformat}
karaf@root()> org.apache.karaf.features.internal.util.MultiException: Error:
Error downloading mvn:de.some.api/api/[1,2)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:91)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457)
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452)
at
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Suppressed: java.io.IOException: Error downloading
mvn:de.cenit/jaas/[3,4)
at
org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
... 3 more
Caused by: java.io.IOException: Error resolving artifact
de.some.api:api:[1,2)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:729)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:659)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:600)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:567)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:47)
at
org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
... 7 more
Caused by:
shaded.org.eclipse.aether.resolution.VersionRangeResolutionException: No
highest version found for de.some.api:api:[1,2)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolveLatestVersionRange(AetherBasedResolver.java:998)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:703)
... 12 more
{noformat}
Setting the property org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote = true as
mentioned in the mailing list does not help.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (KARAF-6005) Resolve of bundle with version range in a feature only works with ".m2" and not with "system" directory
[
https://issues.apache.org/jira/browse/KARAF-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Althaus updated KARAF-6005:
--
Description:
I defined a feature with a ranged bundle version:
mvn:de.some.api/api/[1,2)
If a bundle within that range lies within the global/user Maven repo ".m2", the
bundle gets resolved.
If it resides only within the "system" folder of Karaf I get an exception:
{noformat}
karaf@root()> org.apache.karaf.features.internal.util.MultiException: Error:
Error downloading mvn:de.some.api/api/[1,2)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:91)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457)
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452)
at
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Suppressed: java.io.IOException: Error downloading
mvn:de.some.api/api/[1,2)
at
org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
... 3 more
Caused by: java.io.IOException: Error resolving artifact
de.some.api:api:[1,2)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:729)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:659)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:600)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:567)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:47)
at
org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
... 7 more
Caused by:
shaded.org.eclipse.aether.resolution.VersionRangeResolutionException: No
highest version found for de.some.api:api:[1,2)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolveLatestVersionRange(AetherBasedResolver.java:998)
at
org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:703)
... 12 more
{noformat}
Setting the property org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote = true as
mentioned in the mailing list does not help.
was:
I defined a feature with a ranged bundle version:
mvn:de.some.api/api/[1,2)
If a bundle within that range lies within the global/user Maven repo ".m2", the
bundle gets resolved.
If it resides only within the "system" folder of Karaf I get an exception:
{noformat}
karaf@root()> org.apache.karaf.features.internal.util.MultiException: Error:
Error downloading mvn:de.some.api/api/[1,2)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:91)
at
org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457)
at
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452)
at
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
at
[jira] [Commented] (KARAF-6005) Resolve of bundle with version range in a feature only works with ".m2" and not with "system" directory
[
https://issues.apache.org/jira/browse/KARAF-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678183#comment-16678183
]
Volker Althaus commented on KARAF-6005:
---
Yes, of course. Vanilla Karaf 4.2.1.
> Resolve of bundle with version range in a feature only works with ".m2" and
> not with "system" directory
> ---
>
> Key: KARAF-6005
> URL: https://issues.apache.org/jira/browse/KARAF-6005
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.1
>Reporter: Volker Althaus
>Priority: Critical
>
> I defined a feature with a ranged bundle version:
>
> mvn:de.some.api/api/[1,2)
>
> If a bundle within that range lies within the global/user Maven repo ".m2",
> the bundle gets resolved.
> If it resides only within the "system" folder of Karaf I get an exception:
> {noformat}
> karaf@root()> org.apache.karaf.features.internal.util.MultiException: Error:
> Error downloading mvn:de.some.api/api/[1,2)
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:91)
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457)
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Suppressed: java.io.IOException: Error downloading
> mvn:de.some.api/api/[1,2)
> at
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> Caused by: java.io.IOException: Error resolving artifact
> de.some.api:api:[1,2)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:729)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:659)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:600)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:567)
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:47)
> at
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
> ... 7 more
> Caused by:
> shaded.org.eclipse.aether.resolution.VersionRangeResolutionException: No
> highest version found for de.some.api:api:[1,2)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolveLatestVersionRange(AetherBasedResolver.java:998)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:703)
> ... 12 more
> {noformat}
> Setting the property org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote = true as
> mentioned in the mailing list does not help.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6005) Resolve of bundle with version range in a feature only works with ".m2" and not with "system" directory
[
https://issues.apache.org/jira/browse/KARAF-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692749#comment-16692749
]
Volker Althaus commented on KARAF-6005:
---
Thanks for your analysis. I also suspected that the missing metadata is the
cause.
But I do not quite agree to mark the bug as "won't fix".
If I have a Maven resolution mechanism and the range resolution is an official
supported feature, it should make no difference where the artifact lies.
Even without metadata you get the versions of an artifact from the existing
directory names and files. From then on, the resolution algorithm should
actually be the same as if the data comes from the maven-metadata-local.xml.
> Resolve of bundle with version range in a feature only works with ".m2" and
> not with "system" directory
> ---
>
> Key: KARAF-6005
> URL: https://issues.apache.org/jira/browse/KARAF-6005
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.1
>Reporter: Volker Althaus
>Assignee: Grzegorz Grzybek
>Priority: Critical
>
> I defined a feature with a ranged bundle version:
>
> mvn:de.some.api/api/[1,2)
>
> If a bundle within that range lies within the global/user Maven repo ".m2",
> the bundle gets resolved.
> If it resides only within the "system" folder of Karaf I get an exception:
> {noformat}
> karaf@root()> org.apache.karaf.features.internal.util.MultiException: Error:
> Error downloading mvn:de.some.api/api/[1,2)
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:91)
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457)
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Suppressed: java.io.IOException: Error downloading
> mvn:de.some.api/api/[1,2)
> at
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:77)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> Caused by: java.io.IOException: Error resolving artifact
> de.some.api:api:[1,2)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:729)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:659)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:600)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:567)
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:47)
> at
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:60)
> ... 7 more
> Caused by:
> shaded.org.eclipse.aether.resolution.VersionRangeResolutionException: No
> highest version found for de.some.api:api:[1,2)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolveLatestVersionRange(AetherBasedResolver.java:998)
> at
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:703)
> ... 12 more
> {noformat}
> Setting
