[jira] [Commented] (KARAF-5395) ResourceImpl/RequirementImpl/CapabilityImpl do not correctly implement their OSGi interface contracts
[ https://issues.apache.org/jira/browse/KARAF-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199009#comment-16199009 ] ASF subversion and git services commented on KARAF-5395: Commit 495fbd3cb2d01eba87752cc2ec2a1f51a02d05fb in karaf's branch refs/heads/master from [~gnt] [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=495fbd3 ] [KARAF-5395] Various minor improvements > ResourceImpl/RequirementImpl/CapabilityImpl do not correctly implement their > OSGi interface contracts > - > > Key: KARAF-5395 > URL: https://issues.apache.org/jira/browse/KARAF-5395 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.2.0, 4.1.2, 4.0.10 >Reporter: Robert Varga >Assignee: Guillaume Nodet >Priority: Critical > > This is a follow-up of downstream issue tracked at > https://bugs.opendaylight.org/show_bug.cgi?id=9218. > OpenDaylight uses auto-generated features, which may end up packaging a > bundle multiple times in separate features -- which can be regarded as a bug, > but it certainly is counter-intuitive. > Using a simple test case of wanting to install all features at the same time > triggers huge memory usage spike in Felix Resolver. > Since ResourceImpl does not explictly override hashCode()/equals() according > to org.osgi.resource.Resource interface contract, every resource declaration > in a feature is treated as unique -- disregarding the fact that multiple > bundle declarations are actually pointing to the same bundle. > This cascades to both RequirementImpl and CapabilityImpl, hence each such > duplicate bundle is added to the set of Requirements to be resolved and its > capabilities are added to potential candidates -- leading to Felix Resolver > having a large problem space (what to resolve) and also having a large > solution space (how to resolve) -- leading to polynomial explosion in CPU and > memory requirements. > The amount of memory consumed by OpenDaylight Nitrogen RC3 has been observed > at 1.2GB, e.g. with a heap smaller than that, the container runs into OOM > during feature:install before actual installation starts. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5371) Race condition between FeatureService and Fileinstall
[ https://issues.apache.org/jira/browse/KARAF-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199010#comment-16199010 ] ASF subversion and git services commented on KARAF-5371: Commit 28415d0a2e10e6823ba0cef020277d712d7cb5b1 in karaf's branch refs/heads/master from [~gnt] [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=28415d0 ] [KARAF-5371] Use a defaut region to avoid having bundles not included in any region > Race condition between FeatureService and Fileinstall > - > > Key: KARAF-5371 > URL: https://issues.apache.org/jira/browse/KARAF-5371 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.1.2 >Reporter: J. Brébec >Assignee: Guillaume Nodet >Priority: Critical > Fix For: 4.2.0, 4.1.3 > > > If a bundle is installed when the FeatureService is started, then it is > possible that this bundle is not associated to the default region. as a > consequence, every services exported by this bundle are not visible from the > osgi container, until karaf is restarted. > A real usecase : > - A new karaf distribution, with a blueprint file in a folder managed by > fileinstall ; > - When the distribution is started, as fileinstall is started before the > feature bundle, and the folder are watched asynchronously, the blueprint file > is installed before or in the same time the featureservice is started > => the services exported by the blueprint file are not visible > This race condition is located in the FeatureService activator : the digraph > is loaded, and every bundle not known are added to the default region. then, > it subscribes a bundle-listener : If a bundle X is installed between the > digraph loading and the subscription of the bundle listener, then this bundle > X is not attached to the default region. > On my machine, this issue happens 70% of the time on a cold start. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-3827) Cave rest service doesn't retrieve the repositories
[
https://issues.apache.org/jira/browse/KARAF-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199003#comment-16199003
]
Francois Papon commented on KARAF-3827:
---
Hi JB,
I worked on this issue and fixed it. I also try to return JSON object instead
of XML. It's mandatory for this service to return XML or could we have JSON
response ?
> Cave rest service doesn't retrieve the repositories
> ---
>
> Key: KARAF-3827
> URL: https://issues.apache.org/jira/browse/KARAF-3827
> Project: Karaf
> Issue Type: Bug
> Components: cave-rest
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: cave-4.0.1
>
>
> Even if a repository exists:
> {code}
> karaf@root()> cave:repositories
> Name | Location
> -
> my-repository | /home/jbonofre/bin/apache-karaf-4.0.0/data/cave/my-repository
> {code}
> accessing the Cave REST API on:
> {code}
> http://localhost:8181/cave/rest/repositories
> {code}
> just give:
> {code}
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5371) Race condition between FeatureService and Fileinstall
[
https://issues.apache.org/jira/browse/KARAF-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198851#comment-16198851
]
Guillaume Nodet commented on KARAF-5371:
Could you try the following patch ?
{code}
diff --git
a/features/core/src/main/java/org/apache/karaf/features/internal/region/DigraphHelper.java
b/features/core/src/main/java/org/apache/karaf/features/internal/region/DigraphHelper.java
index 265fb94eaa..5897415c65 100644
---
a/features/core/src/main/java/org/apache/karaf/features/internal/region/DigraphHelper.java
+++
b/features/core/src/main/java/org/apache/karaf/features/internal/region/DigraphHelper.java
@@ -176,6 +176,7 @@ public final class DigraphHelper {
if (defaultRegion == null) {
defaultRegion = dg.createRegion(FeaturesServiceImpl.ROOT_REGION);
}
+dg.setDefaultRegion(defaultRegion);
// Add all unknown bundle to default region
Set ids = new HashSet<>();
for (Bundle bundle : bundleContext.getBundles()) {
{code}
> Race condition between FeatureService and Fileinstall
> -
>
> Key: KARAF-5371
> URL: https://issues.apache.org/jira/browse/KARAF-5371
> Project: Karaf
> Issue Type: Bug
> Components: karaf-feature
>Affects Versions: 4.1.2
>Reporter: J. Brébec
>Assignee: Guillaume Nodet
>Priority: Critical
> Fix For: 4.2.0, 4.1.3
>
>
> If a bundle is installed when the FeatureService is started, then it is
> possible that this bundle is not associated to the default region. as a
> consequence, every services exported by this bundle are not visible from the
> osgi container, until karaf is restarted.
> A real usecase :
> - A new karaf distribution, with a blueprint file in a folder managed by
> fileinstall ;
> - When the distribution is started, as fileinstall is started before the
> feature bundle, and the folder are watched asynchronously, the blueprint file
> is installed before or in the same time the featureservice is started
> => the services exported by the blueprint file are not visible
> This race condition is located in the FeatureService activator : the digraph
> is loaded, and every bundle not known are added to the default region. then,
> it subscribes a bundle-listener : If a bundle X is installed between the
> digraph loading and the subscription of the bundle listener, then this bundle
> X is not attached to the default region.
> On my machine, this issue happens 70% of the time on a cold start.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-4885) Karaf does not gracefully handle a feature with a prerequisite feature that is already installed
[ https://issues.apache.org/jira/browse/KARAF-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4885: Fix Version/s: (was: 4.1.3) 4.1.4 > Karaf does not gracefully handle a feature with a prerequisite feature that > is already installed > > > Key: KARAF-4885 > URL: https://issues.apache.org/jira/browse/KARAF-4885 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.0 >Reporter: Dariush Amiri >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.4 > > > Here is a project on github that reproduces this issue: > https://github.com/damiri-ts/karaf-features-issue > After more investigation, the root cause seems to be the inability of karaf > to gracefully handle situations where a child feature has a prerequisite > feature that is already installed as part of a parent feature. It's confusing > so I've included the feature definition below. Note that the aries-blueprint > feature shows up twice. > description="Something else"> > jasypt-encryption > aries-blueprint > > description="Example"> > framework > wrap > aries-blueprint > shell > shell-compat > feature > jaas > ssh > management > bundle > config > deployer > diagnostic > instance > kar > log > package > service > system > scr > jetty > pax-http-whiteboard > something-else > > This manifests itself in the logs like this: > 2016-12-05T18:23:57,843 | ERROR | FelixStartLevel | > Felix| - - | Bundle org.objectweb.asm.all > [54] Error locking mvn:org.ow2.asm/asm-all/6.0_ALPHA > (java.lang.IllegalStateException: Bundle in unexpected state.) > java.lang.IllegalStateException: Bundle in unexpected state. > at > org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:5272) [?:?] > at > org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1524) [?:?] > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:338) > > [?:?] > at java.lang.Thread.run(Thread.java:745) [?:?] > 2016-12-05T18:23:57,844 | INFO | CM Configuration Updater > (ManagedService Update: pid=[org.apache.cxf.osgi]) | > TldScanner | 189 - org.ops4j.pax.web.pax-web-jsp - > 4.4.0 | found TLD bundle://189.0:0/META-INF/c.tld > 2016-12-05T18:23:57,841 | ERROR | FelixDispatchQueue | > all | 184 - org.objectweb.asm.all - 5.0.2 | > FrameworkEvent ERROR - org.objectweb.asm.all > java.lang.IllegalStateException: Bundle in unexpected state. > at > org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:5272) [?:?] > at > org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1524) [?:?] > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:338) > > [?:?] > at java.lang.Thread.run(Thread.java:745) [?:?] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-4756) Redeploying Features in the Deploy directory with install="auto" does not work for same feature versions
[
https://issues.apache.org/jira/browse/KARAF-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-4756:
Fix Version/s: (was: 4.1.3)
4.1.4
> Redeploying Features in the Deploy directory with install="auto" does not
> work for same feature versions
>
>
> Key: KARAF-4756
> URL: https://issues.apache.org/jira/browse/KARAF-4756
> Project: Karaf
> Issue Type: Bug
> Components: karaf-feature
>Affects Versions: 4.0.6, 4.0.7, 4.0.9, 4.1.2
>Reporter: Cetra Free
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.4
>
>
> If you add a {{-features.xml}} file to the deploy directory, and then make
> any changes to the file, except the name or version, then the feature will
> stay uninstalled.
> You can manually install the feature with feature:install, but this defeats
> the purpose of having install="auto"
> Here's a simple feature:
> {code}
>
> http://karaf.apache.org/xmlns/features/v1.3.0;
> name="example" >
>
> mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
>
> camel-blueprint
>
>
> {code}
> Steps to Reproduce:
> * Plop that example in the deploy directory
> * Notice that the feature is loaded:
> {code}
> feature:list | grep example-feature
> example-feature | 1.0.0| x|
> Started | example |
> {code}
> * Change and update the file, leaving version and name the same
> * Notice that the feature stays uninstalled:
> {code}
> karaf@root()> feature:list | grep example-feature
> example-feature | 1.0.0| |
> Uninstalled | example |
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5110) Karaf 4.1.x / httplite incompatibility
[ https://issues.apache.org/jira/browse/KARAF-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5110: Fix Version/s: (was: 4.1.3) 4.1.4 > Karaf 4.1.x / httplite incompatibility > -- > > Key: KARAF-5110 > URL: https://issues.apache.org/jira/browse/KARAF-5110 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Maven 3.3.9 / MacOS 10.12.4 >Reporter: Stephen Winnall >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.4 > > Attachments: karaf-4.1.x-httplite.tbz > > > I am trying to build a Karaf assembly using Karaf 4.1.1, Java > 1.8.0_76-ea-b04, Maven 3.3.9, Netbeans 8.2 and macOS 10.12.4. I am getting an > error message, even if I omit all my own features from the build (i.e. I > build an empty Karaf): > java.lang.ClassCastException: > org.apache.felix.httplite.osgi.HttpServiceImpl cannot be cast to > org.osgi.service.http.HttpService > The problem seems to be that the latest version of > org.apache.felix.httplite.complete, which provides > org.apache.felix.httplite.osgi.HttpServiceImpl, i.e. 0.1.5, requires a > version of java.servlet that is incompatible with the rest of Karaf 4.1.1, > which - I think - expects 3.1.0. The following comes from the MANIFEST.MF of > org.apache.felix.httplite.complete-0.1.5.jar: > Import-Package: javax.servlet;version="[2.4,3)" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5110) Karaf 4.1.x / httplite incompatibility
[ https://issues.apache.org/jira/browse/KARAF-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198636#comment-16198636 ] Jean-Baptiste Onofré commented on KARAF-5110: - I'm able to reproduce the issue even with Karaf 4.2.0-SNAPSHOT. It sounds more like a Pax Web issue to me. > Karaf 4.1.x / httplite incompatibility > -- > > Key: KARAF-5110 > URL: https://issues.apache.org/jira/browse/KARAF-5110 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Maven 3.3.9 / MacOS 10.12.4 >Reporter: Stephen Winnall >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.4 > > Attachments: karaf-4.1.x-httplite.tbz > > > I am trying to build a Karaf assembly using Karaf 4.1.1, Java > 1.8.0_76-ea-b04, Maven 3.3.9, Netbeans 8.2 and macOS 10.12.4. I am getting an > error message, even if I omit all my own features from the build (i.e. I > build an empty Karaf): > java.lang.ClassCastException: > org.apache.felix.httplite.osgi.HttpServiceImpl cannot be cast to > org.osgi.service.http.HttpService > The problem seems to be that the latest version of > org.apache.felix.httplite.complete, which provides > org.apache.felix.httplite.osgi.HttpServiceImpl, i.e. 0.1.5, requires a > version of java.servlet that is incompatible with the rest of Karaf 4.1.1, > which - I think - expects 3.1.0. The following comes from the MANIFEST.MF of > org.apache.felix.httplite.complete-0.1.5.jar: > Import-Package: javax.servlet;version="[2.4,3)" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5395) ResourceImpl/RequirementImpl/CapabilityImpl do not correctly implement their OSGi interface contracts
[
https://issues.apache.org/jira/browse/KARAF-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198628#comment-16198628
]
Guillaume Nodet commented on KARAF-5395:
I haven't been able to find a solution to the issue above. Merging the
resources cause problems with features which are partially installed. This
solution can only work with simple scenarios without conditional and without
any feature dependency with the {{dependency="true"}} flag set.
I think you'll have to improve your generation mechanism to set the
{{dependency="true"}} flag on bundles where needed and to refer to other
features instead of inlining them.
> ResourceImpl/RequirementImpl/CapabilityImpl do not correctly implement their
> OSGi interface contracts
> -
>
> Key: KARAF-5395
> URL: https://issues.apache.org/jira/browse/KARAF-5395
> Project: Karaf
> Issue Type: Bug
> Components: karaf-feature
>Affects Versions: 4.2.0, 4.1.2, 4.0.10
>Reporter: Robert Varga
>Assignee: Guillaume Nodet
>Priority: Critical
>
> This is a follow-up of downstream issue tracked at
> https://bugs.opendaylight.org/show_bug.cgi?id=9218.
> OpenDaylight uses auto-generated features, which may end up packaging a
> bundle multiple times in separate features -- which can be regarded as a bug,
> but it certainly is counter-intuitive.
> Using a simple test case of wanting to install all features at the same time
> triggers huge memory usage spike in Felix Resolver.
> Since ResourceImpl does not explictly override hashCode()/equals() according
> to org.osgi.resource.Resource interface contract, every resource declaration
> in a feature is treated as unique -- disregarding the fact that multiple
> bundle declarations are actually pointing to the same bundle.
> This cascades to both RequirementImpl and CapabilityImpl, hence each such
> duplicate bundle is added to the set of Requirements to be resolved and its
> capabilities are added to potential candidates -- leading to Felix Resolver
> having a large problem space (what to resolve) and also having a large
> solution space (how to resolve) -- leading to polynomial explosion in CPU and
> memory requirements.
> The amount of memory consumed by OpenDaylight Nitrogen RC3 has been observed
> at 1.2GB, e.g. with a heap smaller than that, the container runs into OOM
> during feature:install before actual installation starts.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5354) log:get and log:set Do Not Work for a etc/log4j2.xml Configuration File
[
https://issues.apache.org/jira/browse/KARAF-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-5354:
Fix Version/s: (was: 4.1.3)
4.1.4
> log:get and log:set Do Not Work for a etc/log4j2.xml Configuration File
> ---
>
> Key: KARAF-5354
> URL: https://issues.apache.org/jira/browse/KARAF-5354
> Project: Karaf
> Issue Type: Bug
> Components: karaf-logging
>Affects Versions: 4.1.2
>Reporter: Emily Berk
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 4.2.0, 4.1.4
>
>
> Steps to reproduce:
> 1. Replace contents of {{etc/org.ops4j.pax.logging.cfg}} with
> {code}
> org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml
> {code}
> 2. Add an {{etc/log4j2.xml}} configuration file with a configuration like
> {code}
>
>
>
>
>
>
>
>
>
>
>
> {code}
> 3. Start up Karaf.
> Notice that {{log:set}} and {{log:get}} fail with
> {code}
> 2017-09-07 18:28:39,352 | ERROR | nsole user karaf | ShellUtil
> | 42 - org.apache.karaf.shell.core - 4.1.2 | Exception caught while
> executing command
> java.lang.IllegalStateException: Unrecognized configuration
> at
> org.apache.karaf.log.core.internal.LogServiceImpl.getDelegate(LogServiceImpl.java:55)
> [36:org.apache.karaf.log.core:4.1.2]
> at
> org.apache.karaf.log.core.internal.LogServiceImpl.setLevel(LogServiceImpl.java:98)
> [36:org.apache.karaf.log.core:4.1.2]
> at
> org.apache.karaf.log.command.SetLogLevel.execute(SetLogLevel.java:48)
> [36:org.apache.karaf.log.core:4.1.2]
> at
> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> [42:org.apache.karaf.shell.core:4.1.2]
> at
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
> [42:org.apache.karaf.shell.core:4.1.2]
> at
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
> [42:org.apache.karaf.shell.core:4.1.2]
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:571)
> [42:org.apache.karaf.shell.core:4.1.2]
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:497)
> [42:org.apache.karaf.shell.core:4.1.2]
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:386)
> [42:org.apache.karaf.shell.core:4.1.2]
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> [42:org.apache.karaf.shell.core:4.1.2]
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229)
> [42:org.apache.karaf.shell.core:4.1.2]
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> [42:org.apache.karaf.shell.core:4.1.2]
> 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) [?:?]
> {code}
> {{log:set}} and {{log:get}} should behave the same when using the
> {{log4j2.xml}} configuration as when using the {{org.ops4j.pax.logging.cfg}}
> configuration.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5384) Optional dependencies in MINA SSHD Core cause system bundle refreshes
[
https://issues.apache.org/jira/browse/KARAF-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198609#comment-16198609
]
Jean-Baptiste Onofré commented on KARAF-5384:
-
Good idea ! However, it's pretty tricky (in term of timing) to do that for
4.1.3, so, let me bump to 4.1.4.
> Optional dependencies in MINA SSHD Core cause system bundle refreshes
> -
>
> Key: KARAF-5384
> URL: https://issues.apache.org/jira/browse/KARAF-5384
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.1.0, 4.1.1, 4.1.2
> Environment: Fedora Linux
>Reporter: Seth Leger
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 4.1.4
>
>
> In similar fashion to KARAF-5251, if you install any feature in Karaf that
> includes:
> - Apache MINA
> - bouncycastle
> - net.i2p.crypto
> it will cause the MINA SSHD Core bundle to refresh, which in turn refreshes
> most of the core framework bundles. This has a variety of bad effects
> including:
> - Terminating the current SSH session
> - Terminating subsequent feature installations
> This is more severe than KARAF-5251 because these libraries are not part of
> the core Karaf distro so it is not possible to add them to
> {{startup.properties}} without first repackaging Karaf to contain the desired
> bundles in the {{/system}} directory.
> This also makes testing any Karaf feature that contains MINA, bouncycastle,
> or net.i2p.crypto impossible in Pax Exam (unless you use
> org.apache.karaf.features.FeaturesService.Option.NoAutoRefreshBundles or
> feature:install -r) because the refresh invalidates @Inject references in
> your test as the core bundles are refreshed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (KARAF-5371) Race condition between FeatureService and Fileinstall
[ https://issues.apache.org/jira/browse/KARAF-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J. Brébec reopened KARAF-5371: -- > Race condition between FeatureService and Fileinstall > - > > Key: KARAF-5371 > URL: https://issues.apache.org/jira/browse/KARAF-5371 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.1.2 >Reporter: J. Brébec >Assignee: Guillaume Nodet >Priority: Critical > Fix For: 4.2.0, 4.1.3 > > > If a bundle is installed when the FeatureService is started, then it is > possible that this bundle is not associated to the default region. as a > consequence, every services exported by this bundle are not visible from the > osgi container, until karaf is restarted. > A real usecase : > - A new karaf distribution, with a blueprint file in a folder managed by > fileinstall ; > - When the distribution is started, as fileinstall is started before the > feature bundle, and the folder are watched asynchronously, the blueprint file > is installed before or in the same time the featureservice is started > => the services exported by the blueprint file are not visible > This race condition is located in the FeatureService activator : the digraph > is loaded, and every bundle not known are added to the default region. then, > it subscribes a bundle-listener : If a bundle X is installed between the > digraph loading and the subscription of the bundle listener, then this bundle > X is not attached to the default region. > On my machine, this issue happens 70% of the time on a cold start. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5371) Race condition between FeatureService and Fileinstall
[
https://issues.apache.org/jira/browse/KARAF-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198586#comment-16198586
]
J. Brébec commented on KARAF-5371:
--
In fact, I can reproduce this issue in my i-test, with pax-exam. Sometime, the
call {code}bundleContext.getBundle(0){code} return a null pointer because the
calling bundle is not referenced in a region when it calls getBundle().
~ 8% of my itest fails because of this issue (for example, Arie Blueprint
Extender call getBundle(0) on every bundle registration to check if this bundle
is the system bundle)
I have fixed it locally with a (really ugly..) patch in the Activator :
{code}
final FindHook regionBundleFindHook = dg.getBundleFindHook();
register(org.osgi.framework.hooks.bundle.FindHook.class, new FindHook() {
@Override
public void find(BundleContext context, Collection bundles) {
if (bundles.size() == 1 &&
bundles.iterator().next().getBundleId() == 0) {
return;
}
regionBundleFindHook.find(context, bundles);
}
});
{code}
maybe allowing a bundle which is not in a region to see every events/bundles is
more correct, but I didn't investigate more...
> Race condition between FeatureService and Fileinstall
> -
>
> Key: KARAF-5371
> URL: https://issues.apache.org/jira/browse/KARAF-5371
> Project: Karaf
> Issue Type: Bug
> Components: karaf-feature
>Affects Versions: 4.1.2
>Reporter: J. Brébec
>Assignee: Guillaume Nodet
>Priority: Critical
> Fix For: 4.2.0, 4.1.3
>
>
> If a bundle is installed when the FeatureService is started, then it is
> possible that this bundle is not associated to the default region. as a
> consequence, every services exported by this bundle are not visible from the
> osgi container, until karaf is restarted.
> A real usecase :
> - A new karaf distribution, with a blueprint file in a folder managed by
> fileinstall ;
> - When the distribution is started, as fileinstall is started before the
> feature bundle, and the folder are watched asynchronously, the blueprint file
> is installed before or in the same time the featureservice is started
> => the services exported by the blueprint file are not visible
> This race condition is located in the FeatureService activator : the digraph
> is loaded, and every bundle not known are added to the default region. then,
> it subscribes a bundle-listener : If a bundle X is installed between the
> digraph loading and the subscription of the bundle listener, then this bundle
> X is not attached to the default region.
> On my machine, this issue happens 70% of the time on a cold start.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (KARAF-5384) Optional dependencies in MINA SSHD Core cause system bundle refreshes
[
https://issues.apache.org/jira/browse/KARAF-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198550#comment-16198550
]
Guillaume Nodet edited comment on KARAF-5384 at 10/10/17 11:59 AM:
---
Well, there are some ways to improve the current situation:
* use jline smaller bundles instead of the jline uber-bundle (this will
remove the link from mina -> ssh -> jline -> shell -> all commands)
* we could repackage ssh to isolate it more and remove the import on mina
(it's not really needed as it defaults to using built-in nio2 anyway)
* when there's a need to refresh the shell.core bundle somehow, try to detect
if there's pax-exam running and maybe do not refresh jline / ssh / shell.core
bundles
The last point could lead to other difficult problems to diagnose, but we
could easily print a big warning message. That would make casual users' life
easier, while making a few users' life a bit harder if they don't know about
this feature. But globally, I think it would be easier...
was (Author: gnt):
Well, there are some ways to improve the current situation:
* use jline smaller bundles instead of the jline uber-bundle (this will
remove the link from mina -> ssh -> jline -> shell -> all commands)
* we could repackage ssh to isolate it more and remove the import on mina
(it's not really needed as it defaults to using built-in nio2 anyway)
> Optional dependencies in MINA SSHD Core cause system bundle refreshes
> -
>
> Key: KARAF-5384
> URL: https://issues.apache.org/jira/browse/KARAF-5384
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.1.0, 4.1.1, 4.1.2
> Environment: Fedora Linux
>Reporter: Seth Leger
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 4.1.4
>
>
> In similar fashion to KARAF-5251, if you install any feature in Karaf that
> includes:
> - Apache MINA
> - bouncycastle
> - net.i2p.crypto
> it will cause the MINA SSHD Core bundle to refresh, which in turn refreshes
> most of the core framework bundles. This has a variety of bad effects
> including:
> - Terminating the current SSH session
> - Terminating subsequent feature installations
> This is more severe than KARAF-5251 because these libraries are not part of
> the core Karaf distro so it is not possible to add them to
> {{startup.properties}} without first repackaging Karaf to contain the desired
> bundles in the {{/system}} directory.
> This also makes testing any Karaf feature that contains MINA, bouncycastle,
> or net.i2p.crypto impossible in Pax Exam (unless you use
> org.apache.karaf.features.FeaturesService.Option.NoAutoRefreshBundles or
> feature:install -r) because the refresh invalidates @Inject references in
> your test as the core bundles are refreshed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5384) Optional dependencies in MINA SSHD Core cause system bundle refreshes
[
https://issues.apache.org/jira/browse/KARAF-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198550#comment-16198550
]
Guillaume Nodet commented on KARAF-5384:
Well, there are some ways to improve the current situation:
* use jline smaller bundles instead of the jline uber-bundle (this will
remove the link from mina -> ssh -> jline -> shell -> all commands)
* we could repackage ssh to isolate it more and remove the import on mina
(it's not really needed as it defaults to using built-in nio2 anyway)
> Optional dependencies in MINA SSHD Core cause system bundle refreshes
> -
>
> Key: KARAF-5384
> URL: https://issues.apache.org/jira/browse/KARAF-5384
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.1.0, 4.1.1, 4.1.2
> Environment: Fedora Linux
>Reporter: Seth Leger
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 4.1.4
>
>
> In similar fashion to KARAF-5251, if you install any feature in Karaf that
> includes:
> - Apache MINA
> - bouncycastle
> - net.i2p.crypto
> it will cause the MINA SSHD Core bundle to refresh, which in turn refreshes
> most of the core framework bundles. This has a variety of bad effects
> including:
> - Terminating the current SSH session
> - Terminating subsequent feature installations
> This is more severe than KARAF-5251 because these libraries are not part of
> the core Karaf distro so it is not possible to add them to
> {{startup.properties}} without first repackaging Karaf to contain the desired
> bundles in the {{/system}} directory.
> This also makes testing any Karaf feature that contains MINA, bouncycastle,
> or net.i2p.crypto impossible in Pax Exam (unless you use
> org.apache.karaf.features.FeaturesService.Option.NoAutoRefreshBundles or
> feature:install -r) because the refresh invalidates @Inject references in
> your test as the core bundles are refreshed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (KARAF-5415) Issue with feature resolution (CXF related)
Paolo Antinori created KARAF-5415:
-
Summary: Issue with feature resolution (CXF related)
Key: KARAF-5415
URL: https://issues.apache.org/jira/browse/KARAF-5415
Project: Karaf
Issue Type: Bug
Affects Versions: 4.1.2
Reporter: Paolo Antinori
Hi, I am facing an odd behavior I cannot explain, with the feature resolution
logic.
I suspect a bug
In the scenario that I'm going to describe here, I end up with a version of
jetty that I wouldn't expect to see installed.
0. create a new features descriptor on the filesystem:
{code}
cat >> /tmp/features.xml <<"EOF"
http://karaf.apache.org/xmlns/features/v1.0.0; name="cxf-test">
jetty
cxf-http
cxf-http
jetty
EOF
{code}
1. start a clean karaf 4.1.2
2. enable cxf repo: {{repo-add cxf 3.1.12}}
3. enable custom repo: {{feature:repo-add file:///tmp/features.xml}}
4. now the test, compare the outcome of the installation of the 3 features:
{code}
karaf@root()> feature:install test1
karaf@root()> la -l | grep -i jetty-all
# empty
karaf@root()> feature:uninstall test1
karaf@root()> feature:install test2
karaf@root()> la -l | grep -i jetty-all
# empty
karaf@root()> feature:uninstall test2
karaf@root()> feature:install test3
karaf@root()> la -l | grep -i jetty-all
142 │ Active │ 30 │ 8.1.14.v20131031 │
mvn:org.eclipse.jetty.aggregate/jetty-all-server/8.1.14.v20131031
# installs something from jetty 8 ???
{code}
So far I have not been able to understand in debug, where the error occurr or
what's causing it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5198) KAR:Create update feature file based on list of features provided
[ https://issues.apache.org/jira/browse/KARAF-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5198: Fix Version/s: (was: 4.1.3) 4.1.4 > KAR:Create update feature file based on list of features provided > - > > Key: KARAF-5198 > URL: https://issues.apache.org/jira/browse/KARAF-5198 > Project: Karaf > Issue Type: Improvement > Components: karaf-kar > Environment: N/A >Reporter: George McCone >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.2.0, 4.1.4 > > > When you create a KAR file using the kar:create command, you can give it a > list of features of the specified repo to include in the KAR file. > It appears that the feature file that is included in the KAR is copied > straight out of the repo and includes all the features regardless of the > those specified. > When the KAR is deployed, it is starting all the features in the feature > file. In many cases this is resulting in the starting of numerous other > features. > One good example of this is the cxf-dosgi repo's feature "cxf-dosgi-base" > which has a feature defined for libs needed when running outside Karaf (or at > least that is what the description says for the feature). It references a > bunch of bundles that come with core Karaf and when this feature tries to > install, it hangs the KAR deployer and Karaf won't shutdown correctly. > It would be nice if the feature file either removed those features that were > not exported, or mark the feature with install="manual", assuming KARAF-5197 > adds this capability. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-4804) Package org.apache.felix.metatype do not deploy properly
[ https://issues.apache.org/jira/browse/KARAF-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved KARAF-4804. - Resolution: Cannot Reproduce Fix Version/s: (was: 4.0.11) (was: 4.1.3) (was: 4.2.0) I'm not able to reproduce the issue with Karaf 4.2.0-SNAPSHOT or 4.1.3-SNAPSHOT. Can you please reopen this Jira if you are able to identify a scenario to reproduce it ? Thanks ! > Package org.apache.felix.metatype do not deploy properly > > > Key: KARAF-4804 > URL: https://issues.apache.org/jira/browse/KARAF-4804 > Project: Karaf > Issue Type: Bug > Components: karaf-core >Affects Versions: 4.0.5, 4.0.7 > Environment: Linux EL6, java 1.8.0u101 >Reporter: Frédérik ROULEAU >Assignee: Jean-Baptiste Onofré > > I can unfortunatly randomly reproduce the error and only on a quite slow > mono-core linux VM; When it occure, the bundle org.apache.felix.metatype does > not deploy due to an unknown mvn protocol error. Then karaf is not listening > on its RMI port. > Here is log : > INFO | jvm 1| 2016/10/25 12:10:08 | > org.apache.karaf.features.internal.util.MultiException: Error restarting > bundles > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:848) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1152) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1048) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.util.concurrent.FutureTask.run(FutureTask.java:266) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.lang.Thread.run(Thread.java:745) > INFO | jvm 1| 2016/10/25 12:10:08 | Suppressed: > org.osgi.framework.BundleException: Activator start error in bundle > org.apache.felix.metatype [34]. > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.Felix.activateBundle(Felix.java:2276) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.Felix.startBundle(Felix.java:2144) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:126 > 2) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:840) > INFO | jvm 1| 2016/10/25 12:10:08 | ... 6 more > INFO | jvm 1| 2016/10/25 12:10:08 | Caused by: > java.lang.IllegalStateException: Unknown protocol: mvn > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.j > ava:482) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.j > ava:474) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.net.URL.toExternalForm(URL.java:929) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.net.URL.toString(URL.java:915) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678) > INFO | jvm 1| 2016/10/25 12:10:08 | at > java.lang.ClassLoader.defineClass(ClassLoader.java:762) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154) > INFO | jvm 1| 2016/10/25 12:10:08 | at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542) > INFO | jvm 1| 2016/10/25 12:10:08 | at >
[jira] [Updated] (KARAF-4261) Bundle start-level seems to be ignored at Karaf restart
[
https://issues.apache.org/jira/browse/KARAF-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-4261:
Fix Version/s: (was: 4.1.3)
4.1.4
> Bundle start-level seems to be ignored at Karaf restart
> ---
>
> Key: KARAF-4261
> URL: https://issues.apache.org/jira/browse/KARAF-4261
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core, karaf-kar
>Affects Versions: 4.0.3
>Reporter: Ralf Steppacher
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.0.11, 4.1.4
>
>
> AS a workaround for CAMEL-9483 I have set a start-level for my bundles
> deployed as part of my features. This works as expected during initial
> deployment (order of deployment is according to the start levels I set), but
> not during sub-sequent starts of Karaf. It appears the start-level of the
> bundles is ignored, meaning the order of deployment of my bundles is more or
> less random and I observe the issues described in CAMEL-9483 again.
> {{bundle:list}} shows my bundles with the start-levels they have been
> originally deployed with, though.
> As a workaround I set {{karaf.clean.all = true}} in system.properties.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly
[
https://issues.apache.org/jira/browse/KARAF-4255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-4255:
Fix Version/s: (was: 4.1.3)
4.1.4
> karaf-maven-plugin does include unused feature conditional dependencies in
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.0.11, 4.1.4
>
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at:
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is
> actually met.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-4966) Provide a Update Note document
[ https://issues.apache.org/jira/browse/KARAF-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4966: Fix Version/s: (was: 4.1.3) 4.1.4 > Provide a Update Note document > -- > > Key: KARAF-4966 > URL: https://issues.apache.org/jira/browse/KARAF-4966 > Project: Karaf > Issue Type: Task > Components: karaf-documentation >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.4 > > > As we did for the update from Karaf 3.0.x to 4.0.x, we will provide a > documentation containing update notes. It should provide the key diff for > people upgrading to Karaf 4.1.x (location of the features, shell behavior, > ...). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5273) karaf-maven-plugin assembly should take feature wildcards
[ https://issues.apache.org/jira/browse/KARAF-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5273: Fix Version/s: (was: 4.1.3) 4.1.4 > karaf-maven-plugin assembly should take feature wildcards > - > > Key: KARAF-5273 > URL: https://issues.apache.org/jira/browse/KARAF-5273 > Project: Karaf > Issue Type: Improvement > Components: karaf-tooling >Reporter: Fabian Lange >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.4 > > > As per discussion in: > http://karaf.922171.n3.nabble.com/Building-custom-dist-including-all-features-of-a-repository-td4051100.html > it would be great if the assembly part of the karaf-maven-plugin would > respect wildcards for startup/boot/installed feature names. currently it only > performs an equals check, requiring dist builders to explicitly list all the > features they want. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5203) KAR:Create missing bundles that are marked conditional
[ https://issues.apache.org/jira/browse/KARAF-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5203: Fix Version/s: (was: 4.1.3) 4.1.4 > KAR:Create missing bundles that are marked conditional > -- > > Key: KARAF-5203 > URL: https://issues.apache.org/jira/browse/KARAF-5203 > Project: Karaf > Issue Type: Bug > Components: karaf-kar > Environment: N/A >Reporter: George McCone >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.2.0, 4.1.4 > > > When creating a KAR file using the KAR:CREATE commands for a feature contains > a bundle in the feature file, the bundle is not being included > in the resulting KAR. > I found this while creating a KAR for aries-rsa using the following command. > >kar:create aries-rsa-1.9.0 aries-rsa-discovery-zookeeper > When trying to start the KAR, I received errors stating that it could not > find the mvn:org.apache.aries.rsa/org.apache.aries.rsa.eapub/1.9.0 from the > repository. Checking the KAR, this bundle was not present. I manually updated > the KAR and the feature started successfully. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-4738) since karaf-maven-plugin version 3.0.3 and later the goal of install-kars takes too long time
[ https://issues.apache.org/jira/browse/KARAF-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4738: Fix Version/s: (was: 4.1.3) 4.1.4 > since karaf-maven-plugin version 3.0.3 and later the goal of install-kars > takes too long time > --- > > Key: KARAF-4738 > URL: https://issues.apache.org/jira/browse/KARAF-4738 > Project: Karaf > Issue Type: Improvement > Components: karaf-tooling >Affects Versions: 3.0.3 > Environment: Opendaylight karaf >Reporter: wu sandi >Assignee: Jean-Baptiste Onofré > Fix For: 3.0.9, 4.2.0, 4.0.11, 4.1.4 > > > In the pom.xml to build opendaylight distribution using karaf-maven-plugin > 3.0.3, I add my own features into the bootFeatures element. When I fire the > command "mvn clean install", it starts to build. During the "install kars" > resolving features, it takes too long time, about 13 minutes, to Install > bundles. It looks like some bundles and features are installed repeatedly. > The building doses't fail but success finally. If I rollabck the > karaf-maven-plugin version to 3.0.1, the "install kars" goal only takes 3 > minutes or less. Then the question is what is the difference between 3.0.3 > and 3.0.3 and how to solve this problem? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-4537) Karaf Maven Plugin should respect scope when building a feature
[ https://issues.apache.org/jira/browse/KARAF-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-4537: Fix Version/s: (was: 4.1.3) 4.1.4 > Karaf Maven Plugin should respect scope when building a feature > --- > > Key: KARAF-4537 > URL: https://issues.apache.org/jira/browse/KARAF-4537 > Project: Karaf > Issue Type: Improvement > Components: karaf-tooling >Affects Versions: 4.0.5 >Reporter: Viktor Kozlov >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.4 > > > I am building a feature without a feature template file. I list my feature > content via pom dependencies. > For example: > > > org.apache.geronimo.specs > geronimo-validation_1.1_spec > compile > > > org.apache.geronimo.specs > geronimo-el_2.2_spec > compile > > > commons-collections > commons-collections > compile > > > commons-beanutils > commons-beanutils > compile > > > org.apache.bval > org.apache.bval.bundle > compile > > > The target file is OK except I need to mark somehow whether bundle is > dependency or not. > dependency="true">mvn:org.apache.geronimo.specs/geronimo-validation_1.1_spec > I think maven runtime scope would be nice. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5204) Create dependant feature KAR files when KAR:Create find external feature dependancy
[ https://issues.apache.org/jira/browse/KARAF-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5204: Fix Version/s: (was: 4.1.3) 4.1.4 > Create dependant feature KAR files when KAR:Create find external feature > dependancy > --- > > Key: KARAF-5204 > URL: https://issues.apache.org/jira/browse/KARAF-5204 > Project: Karaf > Issue Type: Improvement > Components: karaf-kar > Environment: N/A >Reporter: George McCone >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.2.0, 4.1.4 > > > It would be nice if the KAR:Create command could create additional KAR files > to capture all the listed dependencies for the requested feature. Currently > you have to manually review the feature that you are exporting to a KAR and > look for feature references that are external to the feature. This external > feature review then has to be performed recursively on each external feature. > A good example of this is the aries-rsa repo which references the feature > "scr", which is defined in the "standard" repository. After I exported > aries-rsa, and tried to start it, it was missing the bundle > org.apache.karaf.scr:org.apache.karaf.scr.management. Manually created the > "standard" KAR to include the "scr" feature and aries-rsa-core feature then > started successfully. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5210) Seemingly random NPEs from Aether resolver
[
https://issues.apache.org/jira/browse/KARAF-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-5210:
Fix Version/s: (was: 4.1.3)
4.1.4
> Seemingly random NPEs from Aether resolver
> --
>
> Key: KARAF-5210
> URL: https://issues.apache.org/jira/browse/KARAF-5210
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.1
> Environment: Windows
>Reporter: Peter Berkman
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.4
>
> Attachments: mvnsettings.xml, org.ops4j.pax.url.mvn.cfg
>
>
> We have an installer that automates much of our Karaf and product
> installation.
> since the upgrade to Karaf 4.1, I've been getting these about every 5th
> automated install. could be timing? Happens at random places and sometimes
> with dependencies that the target doesn't have.
> One thing is that we do turn OFF internet access for maven through settings
> in the org.ops4j.pax.url.mvn.cfg and provider our out mvnsettings.xml. I
> will try and attach them later, but these are the relevant settings:
> {code}
> org.ops4j.pax.url.mvn.settings=${karaf.etc}/mvnsettings.xml
> org.ops4j.pax.url.mvn.localRepository=${karaf.data}/repo
> org.ops4j.pax.url.mvn.useFallbackRepositories=false
> org.ops4j.pax.url.mvn.defaultRepositories=
> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=true
> org.ops4j.pax.url.mvn.repositories= \
>
> file:${karaf.home}/${karaf.default.repository}@id=system.repository@snapshots,\
> file:${karaf.data}/kar@id=kar.repository@multi@snapshots
> {code}
> mvnsettings.xml:
> {code}
> http://maven.apache.org/SETTINGS/1.1.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0
> http://maven.apache.org/xsd/settings-1.1.0.xsd;>
> data/repo
>
> {code}
> Here is what the stack looks like - note that the target bundle is almost
> always different on different failures.
> {code}
> 20170614 11:24:50.512 [INFO ] pipe-feature:install -v -r ngaudit |
> 10:org.apache.karaf.features.core |
> org.apache.karaf.features.internal.service.FeaturesServiceImpl | Adding
> features: ngaudit/[10.0.0.SNAPSHOT,10.0.0.SNAPSHOT]
> 20170614 11:24:50.531 [ERROR] Thread-85 | 69:org.apache.karaf.shell.core |
> org.apache.karaf.shell.support.ShellUtil | Exception caught while executing
> command
> org.apache.karaf.features.internal.util.MultiException: Error
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:84)[10:org.apache.karaf.features.core:4.1.1]
> at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)[10:org.apache.karaf.features.core:4.1.1]
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:375)[10:org.apache.karaf.features.core:4.1.1]
> at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:372)[10:org.apache.karaf.features.core:4.1.1]
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:187)[10:org.apache.karaf.features.core:4.1.1]
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:285)[10:org.apache.karaf.features.core:4.1.1]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1170)[10:org.apache.karaf.features.core:4.1.1]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1069)[10:org.apache.karaf.features.core:4.1.1]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_92]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_92]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_92]
> Caused by: java.io.IOException: Error downloading
> mvn:org.apache.karaf.jndi/org.apache.karaf.jndi.core/4.1.1
> at
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:81)[10:org.apache.karaf.features.core:4.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_92]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_92]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_92]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_92]
> ... 3 more
> Caused by:
[jira] [Updated] (KARAF-5228) Add documentation about staged featuresBoot
[ https://issues.apache.org/jira/browse/KARAF-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5228: Fix Version/s: (was: 4.1.3) 4.1.4 > Add documentation about staged featuresBoot > --- > > Key: KARAF-5228 > URL: https://issues.apache.org/jira/browse/KARAF-5228 > Project: Karaf > Issue Type: Documentation > Components: karaf-feature >Affects Versions: 4.1.1 >Reporter: Emily Berk >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.2.0, 4.1.4 > > > Documentation should be added to clarify the relationship between features > included in parentheses and features not wrapped in parentheses. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5307) Add SchedulerMBean to mimic scheduler shell commands
[
https://issues.apache.org/jira/browse/KARAF-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-5307:
Fix Version/s: (was: 4.1.3)
4.1.4
> Add SchedulerMBean to mimic scheduler shell commands
>
>
> Key: KARAF-5307
> URL: https://issues.apache.org/jira/browse/KARAF-5307
> Project: Karaf
> Issue Type: New Feature
> Components: karaf-management, karaf-scheduler
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.4
>
>
> Now, we "control" the Karaf scheduler using the {{scheduler:*}} commands. As
> we do for the other parts of Karaf, I will add the corresponding MBean to be
> able to control the scheduler via JMX.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5384) Optional dependencies in MINA SSHD Core cause system bundle refreshes
[
https://issues.apache.org/jira/browse/KARAF-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198491#comment-16198491
]
Jean-Baptiste Onofré commented on KARAF-5384:
-
The only workaround I see is more documenting and warn users that this refresh
will happen. I don't see how to avoid this as it doesn't make sense to ship
mina as "core" Karaf dependency.
> Optional dependencies in MINA SSHD Core cause system bundle refreshes
> -
>
> Key: KARAF-5384
> URL: https://issues.apache.org/jira/browse/KARAF-5384
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
>Affects Versions: 4.1.0, 4.1.1, 4.1.2
> Environment: Fedora Linux
>Reporter: Seth Leger
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 4.1.4
>
>
> In similar fashion to KARAF-5251, if you install any feature in Karaf that
> includes:
> - Apache MINA
> - bouncycastle
> - net.i2p.crypto
> it will cause the MINA SSHD Core bundle to refresh, which in turn refreshes
> most of the core framework bundles. This has a variety of bad effects
> including:
> - Terminating the current SSH session
> - Terminating subsequent feature installations
> This is more severe than KARAF-5251 because these libraries are not part of
> the core Karaf distro so it is not possible to add them to
> {{startup.properties}} without first repackaging Karaf to contain the desired
> bundles in the {{/system}} directory.
> This also makes testing any Karaf feature that contains MINA, bouncycastle,
> or net.i2p.crypto impossible in Pax Exam (unless you use
> org.apache.karaf.features.FeaturesService.Option.NoAutoRefreshBundles or
> feature:install -r) because the refresh invalidates @Inject references in
> your test as the core bundles are refreshed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5409) feature:uninstall displays an error when the feature is installed but not started
[ https://issues.apache.org/jira/browse/KARAF-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-5409: Fix Version/s: (was: 4.1.3) 4.1.4 4.2.0 > feature:uninstall displays an error when the feature is installed but not > started > - > > Key: KARAF-5409 > URL: https://issues.apache.org/jira/browse/KARAF-5409 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.1.2 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-4336) Add support for ordering of CLI scripts and commands in karaf-maven-plugin
[
https://issues.apache.org/jira/browse/KARAF-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-4336:
Fix Version/s: (was: 4.1.3)
4.1.4
> Add support for ordering of CLI scripts and commands in karaf-maven-plugin
> --
>
> Key: KARAF-4336
> URL: https://issues.apache.org/jira/browse/KARAF-4336
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-tooling
>Affects Versions: 4.0.4
>Reporter: Martin Basovník
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.4
>
>
> {code:xml}
>
>
> setup1.cli
> setup2.cli
>
>
> feature:repo-add camel ${version.camel}
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-2511) Review and update documentation
[ https://issues.apache.org/jira/browse/KARAF-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-2511: Fix Version/s: (was: 4.1.3) 4.1.4 > Review and update documentation > --- > > Key: KARAF-2511 > URL: https://issues.apache.org/jira/browse/KARAF-2511 > Project: Karaf > Issue Type: Task > Components: karaf-documentation >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.4 > > > The documentation (manual) should be reviewed: > - The subshell part should be described (usage and configuration). > - The "code samples"/screenshots have to be updated with Karaf 3.0.0 use cases > - a global polishing, double read -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5404) CLI autocompletion issue
[
https://issues.apache.org/jira/browse/KARAF-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved KARAF-5404.
Resolution: Fixed
Fix Version/s: 4.1.3
4.2.0
> CLI autocompletion issue
>
>
> Key: KARAF-5404
> URL: https://issues.apache.org/jira/browse/KARAF-5404
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Paolo Antinori
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.2.0, 4.1.3
>
>
> In a freshly extracted Karaf 4.1.2, running on JDK9, hitting TAB just moves
> the blinking cursor.
> No autocompletion is triggered.
> If I start typing any command instead, like pressing a single {{j}} and then
> hit TAB, I get the correct suggestion.
> I suspect this is either a bug or the help message at boot should be changed
> from:
> {code}
> Apache Karaf (4.1.2)
> Hit '' for a list of available commands
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5404) CLI autocompletion issue
[
https://issues.apache.org/jira/browse/KARAF-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198322#comment-16198322
]
ASF subversion and git services commented on KARAF-5404:
Commit 4188ef858315b4276cd87d73c2747671df695dc9 in karaf's branch
refs/heads/master from [~gnt]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=4188ef8 ]
[KARAF-5404] CLI autocompletion issue
> CLI autocompletion issue
>
>
> Key: KARAF-5404
> URL: https://issues.apache.org/jira/browse/KARAF-5404
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Paolo Antinori
>Assignee: Guillaume Nodet
>Priority: Minor
>
> In a freshly extracted Karaf 4.1.2, running on JDK9, hitting TAB just moves
> the blinking cursor.
> No autocompletion is triggered.
> If I start typing any command instead, like pressing a single {{j}} and then
> hit TAB, I get the correct suggestion.
> I suspect this is either a bug or the help message at boot should be changed
> from:
> {code}
> Apache Karaf (4.1.2)
> Hit '' for a list of available commands
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5404) CLI autocompletion issue
[
https://issues.apache.org/jira/browse/KARAF-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198313#comment-16198313
]
ASF subversion and git services commented on KARAF-5404:
Commit ff9dfd469d74652ace62016768439818c8dab2be in karaf's branch
refs/heads/karaf-4.1.x from [~gnt]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=ff9dfd4 ]
[KARAF-5404] CLI autocompletion issue
> CLI autocompletion issue
>
>
> Key: KARAF-5404
> URL: https://issues.apache.org/jira/browse/KARAF-5404
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Paolo Antinori
>Assignee: Guillaume Nodet
>Priority: Minor
>
> In a freshly extracted Karaf 4.1.2, running on JDK9, hitting TAB just moves
> the blinking cursor.
> No autocompletion is triggered.
> If I start typing any command instead, like pressing a single {{j}} and then
> hit TAB, I get the correct suggestion.
> I suspect this is either a bug or the help message at boot should be changed
> from:
> {code}
> Apache Karaf (4.1.2)
> Hit '' for a list of available commands
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
