[jira] [Comment Edited] (KARAF-6425) Provide a "Simple" Features Resolver
[
https://issues.apache.org/jira/browse/KARAF-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954032#comment-16954032
]
Christian Schneider edited comment on KARAF-6425 at 10/17/19 7:13 PM:
--
Oh .. there is also another best practice when not using the static distro.
Install all features in one command. That allows the resolver to minimize
refreshs.
... and of course: Avoid optional imports :)
was (Author: ch...@die-schneider.net):
Oh .. there is also another best practice when not using the static distro.
Install all features in one command. That allows the resolver to minimize
refreshs.
> Provide a "Simple" Features Resolver
>
>
> Key: KARAF-6425
> URL: https://issues.apache.org/jira/browse/KARAF-6425
> Project: Karaf
> Issue Type: New Feature
> Components: karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.3.0
>
>
> Currently, the "full" features resolver is super powerful but some users
> complain about some effect:
> 1. as it can cause refresh, it's not "predictable"
> 2. it's not easy to determine the features/bundles installed due to
> "underlying" caps/reqs resolution
> Even if I think it makes sense to keep the "full" resolver by default, it
> could be interesting to enable a "simple" resolver (configured via
> {{etc/org.apache.karaf.features.cfg}}) looking like what we had in Karaf 2.x:
> more straight forward, just using the content of the feature, and it's up to
> the user to provide complete features (even by hand or by a tool provided by
> Karaf).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KARAF-6425) Provide a "Simple" Features Resolver
[
https://issues.apache.org/jira/browse/KARAF-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954032#comment-16954032
]
Christian Schneider commented on KARAF-6425:
Oh .. there is also another best practice when not using the static distro.
Install all features in one command. That allows the resolver to minimize
refreshs.
> Provide a "Simple" Features Resolver
>
>
> Key: KARAF-6425
> URL: https://issues.apache.org/jira/browse/KARAF-6425
> Project: Karaf
> Issue Type: New Feature
> Components: karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.3.0
>
>
> Currently, the "full" features resolver is super powerful but some users
> complain about some effect:
> 1. as it can cause refresh, it's not "predictable"
> 2. it's not easy to determine the features/bundles installed due to
> "underlying" caps/reqs resolution
> Even if I think it makes sense to keep the "full" resolver by default, it
> could be interesting to enable a "simple" resolver (configured via
> {{etc/org.apache.karaf.features.cfg}}) looking like what we had in Karaf 2.x:
> more straight forward, just using the content of the feature, and it's up to
> the user to provide complete features (even by hand or by a tool provided by
> Karaf).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KARAF-6425) Provide a "Simple" Features Resolver
[
https://issues.apache.org/jira/browse/KARAF-6425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953687#comment-16953687
]
Christian Schneider commented on KARAF-6425:
I dont think this is a good idea.
If the feature resolver does not refresh bundles then its behaviour is pretty
unpredictable. Depending on the current state installation of an additional
feature could have different resolutions.
What you can look into is building a static distribution at build time. This
way you can be absolutely sure what will be deployed. Of course you then can
not install some feature afterwards.
> Provide a "Simple" Features Resolver
>
>
> Key: KARAF-6425
> URL: https://issues.apache.org/jira/browse/KARAF-6425
> Project: Karaf
> Issue Type: New Feature
> Components: karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.3.0
>
>
> Currently, the "full" features resolver is super powerful but some users
> complain about some effect:
> 1. as it can cause refresh, it's not "predictable"
> 2. it's not easy to determine the features/bundles installed due to
> "underlying" caps/reqs resolution
> Even if I think it makes sense to keep the "full" resolver by default, it
> could be interesting to enable a "simple" resolver (configured via
> {{etc/org.apache.karaf.features.cfg}}) looking like what we had in Karaf 2.x:
> more straight forward, just using the content of the feature, and it's up to
> the user to provide complete features (even by hand or by a tool provided by
> Karaf).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (KARAF-4367) "Module has been uninstalled" during installing the feature
[ https://issues.apache.org/jira/browse/KARAF-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned KARAF-4367: -- Assignee: (was: Christian Schneider) > "Module has been uninstalled" during installing the feature > --- > > Key: KARAF-4367 > URL: https://issues.apache.org/jira/browse/KARAF-4367 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.0.4 >Reporter: Pavlo Vasylchenko >Priority: Major > Attachments: jconsole2.png > > > Separately feature works fine, but if I try to install it just after > uninstalling another feature, I get exception. > Looks like karaf trying refresh something in this time. > my code: > featuresService.installFeature(feature, > EnumSet.of(Option.NoAutoRefreshBundles)); > ... > Caused by: java.lang.IllegalStateException: Module has been uninstalled. > at > org.eclipse.osgi.container.Module.checkValid(Module.java:526)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] > at > org.eclipse.osgi.container.Module.getStartLevel(Module.java:243)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] > at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:480)[9:org.apache.karaf.features.core:4.0.4] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4] > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (KARAF-5052) Change console color scheme
[ https://issues.apache.org/jira/browse/KARAF-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned KARAF-5052: -- Assignee: (was: Christian Schneider) > Change console color scheme > --- > > Key: KARAF-5052 > URL: https://issues.apache.org/jira/browse/KARAF-5052 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.1.0 >Reporter: Jean-Baptiste Onofré >Priority: Major > > With Karaf 4.1.x and use of JLine 3.x, we now have colors in the shell > console. However, some colors are not very convenient (and not really > read-able), especially on Windows as the default background of terminal > windows is dark (for instance, it's pretty hard to read dark blue font with > dark background). > So, as a quick workaround, it would be great to use light color instead of > dark color. > Generally speaking, it would be good to be able to customize the color scheme. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KARAF-5300) FeaturesService should use more specific classes for model
[ https://issues.apache.org/jira/browse/KARAF-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5300. Resolution: Fixed > FeaturesService should use more specific classes for model > -- > > Key: KARAF-5300 > URL: https://issues.apache.org/jira/browse/KARAF-5300 > Project: Karaf > Issue Type: Bug > Components: karaf >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > > Currently the feature service uses strings for many different purposes: > - feature name > - feature name glob > - feature version > - feature version range > It is difficult to tell what purpose such a string has. > I would like to create a type FeatureReq(name, VersionRange) that describes > better what we do. This should make the code a lot easier to understand. > Ideally we would also reflect this in the service interface but the stay > backwards compatbile I will only use the new types internally. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-5587) Appender should create client in the send method instead of the activate
[ https://issues.apache.org/jira/browse/KARAF-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346632#comment-16346632 ] Christian Schneider commented on KARAF-5587: Sounds good > Appender should create client in the send method instead of the activate > > > Key: KARAF-5587 > URL: https://issues.apache.org/jira/browse/KARAF-5587 > Project: Karaf > Issue Type: Bug > Components: decanter >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Blocker > Fix For: decanter-2.0.0 > > > For instance, the elasticsearch appender creates the client in the activate > method. If the client fails for any reason (connection timeout, etc), it's > not possible to send data anymore. > The appenders should create such client in the send method to be able to > reconnect at next call. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-5587) Appender should create client in the send method instead of the activate
[ https://issues.apache.org/jira/browse/KARAF-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346580#comment-16346580 ] Christian Schneider commented on KARAF-5587: I agree we need to be able to reconnect on failures. On the other hand we should not create a new client for every call. > Appender should create client in the send method instead of the activate > > > Key: KARAF-5587 > URL: https://issues.apache.org/jira/browse/KARAF-5587 > Project: Karaf > Issue Type: Bug > Components: decanter >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Blocker > Fix For: decanter-2.0.0 > > > For instance, the elasticsearch appender creates the client in the activate > method. If the client fails for any reason (connection timeout, etc), it's > not possible to send data anymore. > The appenders should create such client in the send method to be able to > reconnect at next call. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KARAF-5578) Add repo URL for sling
[ https://issues.apache.org/jira/browse/KARAF-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5578. Resolution: Fixed > Add repo URL for sling > -- > > Key: KARAF-5578 > URL: https://issues.apache.org/jira/browse/KARAF-5578 > Project: Karaf > Issue Type: Improvement >Affects Versions: 4.2.0.M2 >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: 4.2.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KARAF-5578) Add repo URL for sling
Christian Schneider created KARAF-5578: -- Summary: Add repo URL for sling Key: KARAF-5578 URL: https://issues.apache.org/jira/browse/KARAF-5578 Project: Karaf Issue Type: Improvement Affects Versions: 4.2.0.M2 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KARAF-4803) Allow to turn off Karaf configuration persistence manager
[ https://issues.apache.org/jira/browse/KARAF-4803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-4803: --- Summary: Allow to turn off Karaf configuration persistence manager (was: Turn off Karaf configuration persistence manager) > Allow to turn off Karaf configuration persistence manager > - > > Key: KARAF-4803 > URL: https://issues.apache.org/jira/browse/KARAF-4803 > Project: Karaf > Issue Type: Improvement > Components: karaf-config >Reporter: Dominik Przybysz >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.3, 4.2.0.M1 > > > I have provided my own PersistenceManager which persists configuration in > files not ending with cfg or config. > If I use karaf commands from config:* then for each update there is created > .cfg file in etc/ > It should be configurable to turn off this feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5310) Upgrade to maven surefire plugin 2.20 to get colored output
[ https://issues.apache.org/jira/browse/KARAF-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138507#comment-16138507 ] Christian Schneider commented on KARAF-5310: I tried the upgrade but got failing tests. > Upgrade to maven surefire plugin 2.20 to get colored output > --- > > Key: KARAF-5310 > URL: https://issues.apache.org/jira/browse/KARAF-5310 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5316) Jaas Encryption should be easier to use
[ https://issues.apache.org/jira/browse/KARAF-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5316. Resolution: Fixed > Jaas Encryption should be easier to use > --- > > Key: KARAF-5316 > URL: https://issues.apache.org/jira/browse/KARAF-5316 > Project: Karaf > Issue Type: Improvement > Components: karaf-core >Affects Versions: 4.2.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > Currently the EncryptionSupport is difficult to use. Each module needs to > check the presence of EncryptionSupport and an Encryption module and also > check the prefixes and suffixes. > I propose to have one method exposed by the EncryptionSupport: > String encrypt(String plain) > This method checks if plain is already encrypted and encrypts with the > selected Encryption. It also handles the !enabled or no suitable > EncryptionSupport case. > Besides that I propose a public static EncryptionSupport > noEncryptionSupport() that can be called instead of setting the > encryptionSupport=null in modules. This allows to leave out null checks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5316) Jaas Encryption should be easier to use
[ https://issues.apache.org/jira/browse/KARAF-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16136861#comment-16136861 ] Christian Schneider commented on KARAF-5316: I will leave the current public methods of EncryptionSupport as deprecated so current modules outside of karaf still work. > Jaas Encryption should be easier to use > --- > > Key: KARAF-5316 > URL: https://issues.apache.org/jira/browse/KARAF-5316 > Project: Karaf > Issue Type: Improvement > Components: karaf-core >Affects Versions: 4.2.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > Currently the EncryptionSupport is difficult to use. Each module needs to > check the presence of EncryptionSupport and an Encryption module and also > check the prefixes and suffixes. > I propose to have one method exposed by the EncryptionSupport: > String encrypt(String plain) > This method checks if plain is already encrypted and encrypts with the > selected Encryption. It also handles the !enabled or no suitable > EncryptionSupport case. > Besides that I propose a public static EncryptionSupport > noEncryptionSupport() that can be called instead of setting the > encryptionSupport=null in modules. This allows to leave out null checks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5316) Jaas Encryption should be easier to use
Christian Schneider created KARAF-5316: -- Summary: Jaas Encryption should be easier to use Key: KARAF-5316 URL: https://issues.apache.org/jira/browse/KARAF-5316 Project: Karaf Issue Type: Improvement Components: karaf-core Affects Versions: 4.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 Currently the EncryptionSupport is difficult to use. Each module needs to check the presence of EncryptionSupport and an Encryption module and also check the prefixes and suffixes. I propose to have one method exposed by the EncryptionSupport: String encrypt(String plain) This method checks if plain is already encrypted and encrypts with the selected Encryption. It also handles the !enabled or no suitable EncryptionSupport case. Besides that I propose a public static EncryptionSupport noEncryptionSupport() that can be called instead of setting the encryptionSupport=null in modules. This allows to leave out null checks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned KARAF-5314: -- Assignee: Christian Schneider > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135366#comment-16135366 ] Christian Schneider commented on KARAF-5314: Tthe backport to 4.1.x is done now. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5314: --- Fix Version/s: 4.1.3 > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.2.0, 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135226#comment-16135226 ] Christian Schneider commented on KARAF-5314: Currently the fix will go into karaf 4.2.0. I hope we are doing this release soon. If there is need I can backport for 4.1.x. which is normally released about once a month. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.2.0 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134877#comment-16134877 ] Christian Schneider commented on KARAF-5314: I have now merged the commit of Vinay and my branch. The build looks good. [~vinayshankar] I would be very interested how it performs compared to the original code and to your PR. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134430#comment-16134430 ] Christian Schneider commented on KARAF-5314: I just found a possible change that should speed up the code quite a lot. Currently we always recurse into every feature dependency. I think we we can make this a lot faster by only recursing into the dependencies of a feature once. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134429#comment-16134429 ] Christian Schneider commented on KARAF-5314: In this part of the code we are only going through the features and their feature dependencies. So we are traversing at max 900 features and recurse through their dependencies. With the caching on feature name we only need to traverse the different versions of a feature. So I think this should be way below the level where parallel execution would help. After my extraction of the FeatureSelector class it should be quite easy to do unit tests on the performance. So I will setup some test cases. Then we can easily try the performance impact of changes. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134368#comment-16134368 ] Christian Schneider commented on KARAF-5314: I now extracted the caching logic into its own class. Please see the branch KARAF-5314-2. Compared to your code I removed the caching of the version -> feature for now. We also need to support ranges like spring/[3.2,4) and It think this is not covered by the caching you implemented. I also reintroduced the stream for selecting the matching versions. I am not sure if this is slower than a for loop. Can you test this with a loop and with a stream. If the for loop is performing noticeably better then we will use a for loop. I think the main performance gain you saw came from the caching. In my branch this will be a little slower as I only cache by name. The question is how big the difference really is. We can create a caching using name, range if needed but I am not sure if it makes a big difference. I expect this to only matter when there is a high number of versions for a feature name. So if you think this should make a difference in your case we can do this. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134003#comment-16134003 ] Christian Schneider edited comment on KARAF-5314 at 8/19/17 7:41 AM: - I am not sure if the streams API is the root of the problem. Instead I think the problem is that we repeatedly go through the features to find a match for a given feature/version. So a cache is a good idea to speed this up. Currently there are two cases for a version. The version can be open if only the name is given or the version is 0.0.0. In this case all versions would match. The other case is that a version is given. Then only this version would match. The current code filters using a range which adds all matching features. The code in the PR uses a cache that holds only one feature. So I am not sure this will always do the same thing. was (Author: ch...@die-schneider.net): I am not sure if the streams API is the root of the problem. Instead I think the problem is that we repeatedly go through the features to find a match for a given feature/version. So a cache is a good idea to speed this up. Currently there are two cases for a version. The version can be open if only the name is given or the version is 0.0.0. In this case all versions would match. The other case is that a version is given. Then only this version would match. The current code filters using a range which would return add all matching features. The code in the PR uses a cache that holds only one feature. So I am not sure this will always do the same thing. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5314) The performance of profile builder used by karaf maven plugin has reduced significantly in 4.1 compared to 4.0
[ https://issues.apache.org/jira/browse/KARAF-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134003#comment-16134003 ] Christian Schneider commented on KARAF-5314: I am not sure if the streams API is the root of the problem. Instead I think the problem is that we repeatedly go through the features to find a match for a given feature/version. So a cache is a good idea to speed this up. Currently there are two cases for a version. The version can be open if only the name is given or the version is 0.0.0. In this case all versions would match. The other case is that a version is given. Then only this version would match. The current code filters using a range which would return add all matching features. The code in the PR uses a cache that holds only one feature. So I am not sure this will always do the same thing. > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0 > -- > > Key: KARAF-5314 > URL: https://issues.apache.org/jira/browse/KARAF-5314 > Project: Karaf > Issue Type: Bug >Reporter: Vinay Shankar > Fix For: 4.1.3 > > > The performance of profile builder used by karaf maven plugin has reduced > significantly in 4.1 compared to 4.0. > The java streams API is being used in 4.1 to filter our the required features > from the set of all features present in the repositories that are part of the > profile. This is done in the "addFeatures" method in the "Builder.java" class > in the "org.apache.karaf.profile.core" bundle. This change (from 4.0) has > drastically reduced the performance. For a profile with ~900 features in all > the repositories in the profile and ~300 required features from a highly > complex feature dependency tree, this function is taking around 13min to > complete. The same execution took around 3-5min in 4.0 (where simple for > loops were being used). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5310) Upgrade to maven surefire plugin 2.20 to get colored output
Christian Schneider created KARAF-5310: -- Summary: Upgrade to maven surefire plugin 2.20 to get colored output Key: KARAF-5310 URL: https://issues.apache.org/jira/browse/KARAF-5310 Project: Karaf Issue Type: Dependency upgrade Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5309) Upgrade to directory server 2.0.0-M24
[ https://issues.apache.org/jira/browse/KARAF-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5309. Resolution: Fixed > Upgrade to directory server 2.0.0-M24 > - > > Key: KARAF-5309 > URL: https://issues.apache.org/jira/browse/KARAF-5309 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5309) Upgrade to directory server 2.0.0-M24
Christian Schneider created KARAF-5309: -- Summary: Upgrade to directory server 2.0.0-M24 Key: KARAF-5309 URL: https://issues.apache.org/jira/browse/KARAF-5309 Project: Karaf Issue Type: Dependency upgrade Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5308) Remove RepositoryImpl lazy loading as we always load it upfront anyway
[ https://issues.apache.org/jira/browse/KARAF-5308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5308. Resolution: Fixed > Remove RepositoryImpl lazy loading as we always load it upfront anyway > -- > > Key: KARAF-5308 > URL: https://issues.apache.org/jira/browse/KARAF-5308 > Project: Karaf > Issue Type: Improvement >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > Currently RepositoryImpl has the ability to load on demand if it is not > already loaded. > This is not necessary as all usages load the Repository content right away. > So I propose to remove the lazy loading . > Another change is to prefer creating/loading features through the > RepositoryCache. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5308) Remove RepositoryImpl lazy loading as we always load it upfront anyway
Christian Schneider created KARAF-5308: -- Summary: Remove RepositoryImpl lazy loading as we always load it upfront anyway Key: KARAF-5308 URL: https://issues.apache.org/jira/browse/KARAF-5308 Project: Karaf Issue Type: Improvement Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 Currently RepositoryImpl has the ability to load on demand if it is not already loaded. This is not necessary as all usages load the Repository content right away. So I propose to remove the lazy loading . Another change is to prefer creating/loading features through the RepositoryCache. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5305) FeatureConfigInstaller writes incorrect config if append=true and file already exists
[ https://issues.apache.org/jira/browse/KARAF-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5305. Resolution: Fixed > FeatureConfigInstaller writes incorrect config if append=true and file > already exists > - > > Key: KARAF-5305 > URL: https://issues.apache.org/jira/browse/KARAF-5305 > Project: Karaf > Issue Type: Bug > Components: karaf-config >Affects Versions: 4.2.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > While improving the org.apache.karaf.features.AppendTest I found that there > is a case where the FeatureConfigInstaller behaves incorrectly. > If you add cfgFile.createNewFile() to testAppend then the code does not use > the java Property class to write the config but the felix TypedProperties. > The resulting file looks like this: > javax.servlet.context.tempdir = ( \ > \ > "data/pax-web-jsp", \ > \ > ) > This is incorrect as the property javax.servlet.context.tempdir contains a > simple String not an array. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5305) FeatureConfigInstaller writes incorrect config if append=true and file already exists
Christian Schneider created KARAF-5305: -- Summary: FeatureConfigInstaller writes incorrect config if append=true and file already exists Key: KARAF-5305 URL: https://issues.apache.org/jira/browse/KARAF-5305 Project: Karaf Issue Type: Bug Components: karaf-config Affects Versions: 4.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 While improving the org.apache.karaf.features.AppendTest I found that there is a case where the FeatureConfigInstaller behaves incorrectly. If you add cfgFile.createNewFile() to testAppend then the code does not use the java Property class to write the config but the felix TypedProperties. The resulting file looks like this: javax.servlet.context.tempdir = ( \ \ "data/pax-web-jsp", \ \ ) This is incorrect as the property javax.servlet.context.tempdir contains a simple String not an array. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5300) FeaturesService should use more specific classes for model
Christian Schneider created KARAF-5300: -- Summary: FeaturesService should use more specific classes for model Key: KARAF-5300 URL: https://issues.apache.org/jira/browse/KARAF-5300 Project: Karaf Issue Type: Bug Components: karaf-feature Reporter: Christian Schneider Assignee: Christian Schneider Currently the feature service uses strings for many different purposes: - feature name - feature name glob - feature version - feature version range It is difficult to tell what purpose such a string has. I would like to create a type FeatureReq(name, VersionRange) that describes better what we do. This should make the code a lot easier to understand. Ideally we would also reflect this in the service interface but the stay backwards compatbile I will only use the new types internally. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-4367) "Module has been uninstalled" during installing the feature
[ https://issues.apache.org/jira/browse/KARAF-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119547#comment-16119547 ] Christian Schneider commented on KARAF-4367: I think a I found a possible cause for this. In org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures we first copy the current state and then do the provisioning in a SingleThreadExecutor. So while the provisioning is protected to be entered by one thread at a time this is not the case while we copy the state and do the computation of what to change. > "Module has been uninstalled" during installing the feature > --- > > Key: KARAF-4367 > URL: https://issues.apache.org/jira/browse/KARAF-4367 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.4 >Reporter: Pavlo Vasylchenko >Assignee: Christian Schneider > Attachments: jconsole2.png > > > Separately feature works fine, but if I try to install it just after > uninstalling another feature, I get exception. > Looks like karaf trying refresh something in this time. > my code: > featuresService.installFeature(feature, > EnumSet.of(Option.NoAutoRefreshBundles)); > ... > Caused by: java.lang.IllegalStateException: Module has been uninstalled. > at > org.eclipse.osgi.container.Module.checkValid(Module.java:526)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] > at > org.eclipse.osgi.container.Module.getStartLevel(Module.java:243)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] > at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:480)[9:org.apache.karaf.features.core:4.0.4] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4] > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (KARAF-4367) "Module has been uninstalled" during installing the feature
[ https://issues.apache.org/jira/browse/KARAF-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned KARAF-4367: -- Assignee: Christian Schneider > "Module has been uninstalled" during installing the feature > --- > > Key: KARAF-4367 > URL: https://issues.apache.org/jira/browse/KARAF-4367 > Project: Karaf > Issue Type: Bug > Components: karaf-core, karaf-feature >Affects Versions: 4.0.4 >Reporter: Pavlo Vasylchenko >Assignee: Christian Schneider > Attachments: jconsole2.png > > > Separately feature works fine, but if I try to install it just after > uninstalling another feature, I get exception. > Looks like karaf trying refresh something in this time. > my code: > featuresService.installFeature(feature, > EnumSet.of(Option.NoAutoRefreshBundles)); > ... > Caused by: java.lang.IllegalStateException: Module has been uninstalled. > at > org.eclipse.osgi.container.Module.checkValid(Module.java:526)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] > at > org.eclipse.osgi.container.Module.getStartLevel(Module.java:243)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] > at > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:480)[9:org.apache.karaf.features.core:4.0.4] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[9:org.apache.karaf.features.core:4.0.4] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[9:org.apache.karaf.features.core:4.0.4] > at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-4655.
Resolution: Fixed
I found and fixed the issue. Can you retest with master or karaf-4.1.x?
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.3
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116605#comment-16116605
]
Christian Schneider commented on KARAF-4655:
Removing restlet did the trick. Now I can finally reproduce the error:
I see this line:
Downloading:
http://id=restlet/org/restlet/osgi/org.restlet/2.3.6/org.restlet-2.3.6.jar
So this clearly is wrong. I will debug into it.
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.3
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated KARAF-4655:
---
Fix Version/s: (was: 4.1.2)
4.1.3
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.3
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-4529) deployment of feature containing bundles with camel blueprint routes fail
[
https://issues.apache.org/jira/browse/KARAF-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-4529.
Resolution: Won't Fix
Both issues are about an unfullfilled requirement for an OSGi service. This is
not an issue in karaf.
If one of the bundles requires a service then there needs to be another bundle
that provides the service as a capability in it Manifest.
There are several solutions:
- Make sure one of the bundles provides the service. Maybe camel can provide
the respective capability.
- Add a capability to your feature like here:
https://github.com/apache/karaf/blob/e90bf7e82a3e71e5ac53aea6a836dd7a83fdf477/features/core/src/test/resources/org/apache/karaf/features/internal/service/f07.xml#L31-L33
> deployment of feature containing bundles with camel blueprint routes fail
> -
>
> Key: KARAF-4529
> URL: https://issues.apache.org/jira/browse/KARAF-4529
> Project: Karaf
> Issue Type: Bug
> Components: karaf-feature
>Affects Versions: 4.0.5
> Environment: Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17,
> mixed mode)
> Linux dbserver-p2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u6
> (2015-11-09) x86_64 GNU/Linux
>Reporter: Alexander Sahler
>Assignee: Christian Schneider
>Priority: Blocker
>
> When using the feature mechanism to deploy bundles containing blueprint files
> with camel routes, the deployment fails with exception
> {code}
> 2016-05-13 13:21:05,172 | ERROR | nsole user karaf | ShellUtil
> | 107 - org.apache.karaf.shell.core
> - 4.0.5 | Exception caught while executing command
> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.iden
> tity=pmc-impl; type=karaf.feature; version="[1.4.0.SNAPSHOT,1.4.0.SNAPSHOT]";
> filter:="(&(osgi.identity=pmc-impl)(type=kar
> af.feature)(version>=1.4.0.SNAPSHOT)(version<=1.4.0.SNAPSHOT))" [caused by:
> Unable to resolve pmc-impl/1.4.0.SNAPSHOT: mis
> sing requirement [pmc-impl/1.4.0.SNAPSHOT] osgi.identity;
> osgi.identity=pmc-impl; type=osgi.bundle; version="[1.4.0.SNAPSH
> OT,1.4.0.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve
> pmc-impl/1.4.0.SNAPSHOT: missing requirement [pmc
> -impl/1.4.0.SNAPSHOT] osgi.service; effective:=active;
> filter:="(&(objectClass=org.apache.aries.blueprint.NamespaceHandler
> )(osgi.service.blueprint.namespace=http://camel.apache.org/schema/blueprint))"]]
> at
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[org.apache.felix.framework-5.4.0
> .jar:]
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[org.apache.felix.framework-5.4.0.jar:]
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[9:org.apache.ka
> raf.features.core:4.0.5]
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[9:org.apache.karaf.features.core:
> 4.0.5]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1152)[9:org
> .apache.karaf.features.core:4.0.5]
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1048)[9:org.apac
> he.karaf.features.core:4.0.5]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_66]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_66]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_66]
> {code}
> However, when I install all the dependencies in the feature manually in the
> console (via install -s) and the bundle itself the same way, the deployment
> works perfectly!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider closed KARAF-4655.
--
Resolution: Cannot Reproduce
[~ilazebny] please reopen if you can still reproduce.
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5210) Seemingly random NPEs from Aether resolver
[
https://issues.apache.org/jira/browse/KARAF-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114238#comment-16114238
]
Christian Schneider commented on KARAF-5210:
Can you provide a small example project that reproduces the error?
We at least need the exact steps to reproduce.
> 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.2
>
> 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
>
[jira] [Commented] (KARAF-5144) java.lang.RuntimeException: Command name evaluates to null: $.jline.terminal
[
https://issues.apache.org/jira/browse/KARAF-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114183#comment-16114183
]
Christian Schneider commented on KARAF-5144:
I just checked the current shell init script:
jlineReader = $.reader
if { %(jlineReader != null) } {
# On 256 colors terminal, add a right prompt
max_colors = ($.jline.terminal getNumericCapability max_colors)
This should protect from $.jline.terminal being null too as it is a property of
the jline reader.
> java.lang.RuntimeException: Command name evaluates to null: $.jline.terminal
>
>
> Key: KARAF-5144
> URL: https://issues.apache.org/jira/browse/KARAF-5144
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
>Reporter: Roland Hauser
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.2.0, 4.1.2
>
>
> Method executeScript on class org.apache.karaf.shell.ssh.ShellCommand throws
> (and catches) this exception, when property karaf.shell.init.script in
> system.properties is set to "karaf.shell.init.script = etc/shell.init.script"
> to avoid KARAF-5143. This means that currently no command can be executed
> which is specified in the shell init-script, which makes it impossible for us
> to deploy our application on Karaf 4.1.1.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5144) java.lang.RuntimeException: Command name evaluates to null: $.jline.terminal
[ https://issues.apache.org/jira/browse/KARAF-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114155#comment-16114155 ] Christian Schneider commented on KARAF-5144: Can you provide exact steps to reproduce this? Also your system might be important. Normally $.jline.terminal does not resolve to null. I think this is where the exception is caused: max_colors = ($.jline.terminal getNumericCapability max_colors) I think we can solve this in two ways. Either we make sure .jline.terminal is never null or we check for null in the script. > java.lang.RuntimeException: Command name evaluates to null: $.jline.terminal > > > Key: KARAF-5144 > URL: https://issues.apache.org/jira/browse/KARAF-5144 > Project: Karaf > Issue Type: Bug > Components: karaf-shell >Affects Versions: 4.1.1 >Reporter: Roland Hauser >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.2 > > > Method executeScript on class org.apache.karaf.shell.ssh.ShellCommand throws > (and catches) this exception, when property karaf.shell.init.script in > system.properties is set to "karaf.shell.init.script = etc/shell.init.script" > to avoid KARAF-5143. This means that currently no command can be executed > which is specified in the shell init-script, which makes it impossible for us > to deploy our application on Karaf 4.1.1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114053#comment-16114053
]
Christian Schneider commented on KARAF-4655:
The karaf version 4.0.6-SNAPSHOT referenced in the pom is not available.
I built the pom using several karaf versions (4.0.5, 4.0.6, 4.0.9, 4.1.1). All
builds worked fine. Can you check if upgrading the karaf version fixes the
issue for you?
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-5286) Separate server key generation from key reading
[ https://issues.apache.org/jira/browse/KARAF-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5286: --- Description: Currently we use AbstractGeneratorHostKeyProvider to read server keys and also generate them on the fly. According to the mina sshd team this class is not meant for production use. So I propose we create a separate classes for reading and writing keys. I also propose we remove the hostKeyFormat config and only support OpenSSH pem based keys. For now we need a custom OpenSSHKeyPairProvider to read out keys as mina sshd has a bug (SSHD-760). After the release of sshd 1.7.0 we can switch to the standard FileKeyProvider from mina. was: Currently we use AbstractGeneratorHostKeyProvider to read server keys and also generate them on the fly. According to the mina sshd team this class is not meant for production use. So I propose we create a separate classes for reading and writing keys. I also propose we remove the hostKeyFormat config and only support OpenSSH pem based keys. For now we need a custom OpenSSHKeyPairProvider to read out keys as mina sshd has a bug (SSHD-720). After the release of sshd 1.7.0 we can switch to the standard FileKeyProvider from mina. > Separate server key generation from key reading > --- > > Key: KARAF-5286 > URL: https://issues.apache.org/jira/browse/KARAF-5286 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 4.2.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > Currently we use AbstractGeneratorHostKeyProvider to read server keys and > also generate them on the fly. According to the mina sshd team this class is > not meant for production use. > So I propose we create a separate classes for reading and writing keys. > I also propose we remove the hostKeyFormat config and only support OpenSSH > pem based keys. > For now we need a custom OpenSSHKeyPairProvider to read out keys as mina sshd > has a bug (SSHD-760). After the release of sshd 1.7.0 we can switch to the > standard FileKeyProvider from mina. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5286) Separate server key generation from key reading
Christian Schneider created KARAF-5286: -- Summary: Separate server key generation from key reading Key: KARAF-5286 URL: https://issues.apache.org/jira/browse/KARAF-5286 Project: Karaf Issue Type: Improvement Components: karaf-shell Affects Versions: 4.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 Currently we use AbstractGeneratorHostKeyProvider to read server keys and also generate them on the fly. According to the mina sshd team this class is not meant for production use. So I propose we create a separate classes for reading and writing keys. I also propose we remove the hostKeyFormat config and only support OpenSSH pem based keys. For now we need a custom OpenSSHKeyPairProvider to read out keys as mina sshd has a bug (SSHD-720). After the release of sshd 1.7.0 we can switch to the standard FileKeyProvider from mina. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (KARAF-5072) Add setting to ssh server for forcing a provided key
[ https://issues.apache.org/jira/browse/KARAF-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider closed KARAF-5072. -- Resolution: Won't Fix I will propose a different solution in a separate ticket. > Add setting to ssh server for forcing a provided key > > > Key: KARAF-5072 > URL: https://issues.apache.org/jira/browse/KARAF-5072 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 4.1.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > If karaf does not find a server key in etc/hosts.key it will create one and > save it. > If the key is present but invalid it will be overwritten by default. > If overwrite=false in the settings and the provided key is invalid then karaf > will create a key on every first ssh connect after a restart. > I think it would be better to have a setting to force the provided key to be > used and throw an exception if it is invalid. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5072) Add setting to ssh server for forcing a provided key
[ https://issues.apache.org/jira/browse/KARAF-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5072: --- Fix Version/s: (was: 4.1.2) > Add setting to ssh server for forcing a provided key > > > Key: KARAF-5072 > URL: https://issues.apache.org/jira/browse/KARAF-5072 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 4.1.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > If karaf does not find a server key in etc/hosts.key it will create one and > save it. > If the key is present but invalid it will be overwritten by default. > If overwrite=false in the settings and the provided key is invalid then karaf > will create a key on every first ssh connect after a restart. > I think it would be better to have a setting to force the provided key to be > used and throw an exception if it is invalid. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5073) OpenSSHGeneratorFileKeyProvider is unable to write SSH keys
[ https://issues.apache.org/jira/browse/KARAF-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5073: --- Fix Version/s: 4.1.2 > OpenSSHGeneratorFileKeyProvider is unable to write SSH keys > --- > > Key: KARAF-5073 > URL: https://issues.apache.org/jira/browse/KARAF-5073 > Project: Karaf > Issue Type: Bug > Components: karaf-shell >Affects Versions: 4.1.0, 4.1.2 > Environment: all >Reporter: Lukasz Lech >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > Attachments: karaf-shell-ssh-OpenSSHGeneratorFileKeyProvider.patch > > > Project: org.apache.karaf.shell.ssh > Class org.apache.karaf.shell.ssh.OpenSSHGeneratorFileKeyProvider has method > doWriteKeyPair to write generated SSH keys to the disk. > When I run karaf and log in with SSH, the keys are generated, but not > written. In console stays: > > sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to > > org.apache.commons.ssl.PEMItem > After inspicing the implementation and comparing it with the > not-yes-ssl-commons code I can't see how this method could function for > anyone in current form. PEMUtil.encode expected the collection of > org.apache.commons.ssl.PEMItem items, which have no inheriting classes nor > implement/extend anything. > *Probably* the correct way would be either using toPEM and > formatRSAPrivateKey methods from PEMUtil, but it doesn't seem obvious to me > what method is symethrical to the constructor of > org.apache.commons.ssl.PKCS8Key. > One is sure, doWriteKeyPair with current codebase can no way work. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5073) OpenSSHGeneratorFileKeyProvider is unable to write SSH keys
[ https://issues.apache.org/jira/browse/KARAF-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5073. Resolution: Fixed Assignee: Christian Schneider (was: Jean-Baptiste Onofré) Fix Version/s: 4.2.0 This patch was already applied by gnodet. > OpenSSHGeneratorFileKeyProvider is unable to write SSH keys > --- > > Key: KARAF-5073 > URL: https://issues.apache.org/jira/browse/KARAF-5073 > Project: Karaf > Issue Type: Bug > Components: karaf-shell >Affects Versions: 4.1.0, 4.1.2 > Environment: all >Reporter: Lukasz Lech >Assignee: Christian Schneider > Fix For: 4.2.0 > > Attachments: karaf-shell-ssh-OpenSSHGeneratorFileKeyProvider.patch > > > Project: org.apache.karaf.shell.ssh > Class org.apache.karaf.shell.ssh.OpenSSHGeneratorFileKeyProvider has method > doWriteKeyPair to write generated SSH keys to the disk. > When I run karaf and log in with SSH, the keys are generated, but not > written. In console stays: > > sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to > > org.apache.commons.ssl.PEMItem > After inspicing the implementation and comparing it with the > not-yes-ssl-commons code I can't see how this method could function for > anyone in current form. PEMUtil.encode expected the collection of > org.apache.commons.ssl.PEMItem items, which have no inheriting classes nor > implement/extend anything. > *Probably* the correct way would be either using toPEM and > formatRSAPrivateKey methods from PEMUtil, but it doesn't seem obvious to me > what method is symethrical to the constructor of > org.apache.commons.ssl.PKCS8Key. > One is sure, doWriteKeyPair with current codebase can no way work. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (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:comment-tabpanel=16108619#comment-16108619
]
Christian Schneider commented on KARAF-4261:
Start levels are not a good way to control the order in OSGi. Have you tried to
create a service depdendency? That ususally works better.
Your data access bundle should provide an OSGi service that higher level
bundles use.
> 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.1.2, 4.0.10
>
>
> 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] [Commented] (KARAF-5119) log:tail on OSX does not display updates without user input and exits shell on ctrl + c
[
https://issues.apache.org/jira/browse/KARAF-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108618#comment-16108618
]
Christian Schneider commented on KARAF-5119:
Can you also check on karaf-4.1.x as this will be the base for karaf 4.1.2.
> log:tail on OSX does not display updates without user input and exits shell
> on ctrl + c
> ---
>
> Key: KARAF-5119
> URL: https://issues.apache.org/jira/browse/KARAF-5119
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
> Environment: Mac OS X
>Reporter: Cetra Free
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> When trying to use 4.1.1 on Mac OS X and the {{log:tail}} function within the
> karaf cli, no logs are displayed unless you press enter or any other input.
> Further to this: pressing {{ctrl + c}} will drop out of the shell completely
> rather than go back to the main prompt.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-5119) log:tail on OSX does not display updates without user input and exits shell on ctrl + c
[
https://issues.apache.org/jira/browse/KARAF-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-5119.
Resolution: Fixed
> log:tail on OSX does not display updates without user input and exits shell
> on ctrl + c
> ---
>
> Key: KARAF-5119
> URL: https://issues.apache.org/jira/browse/KARAF-5119
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
> Environment: Mac OS X
>Reporter: Cetra Free
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> When trying to use 4.1.1 on Mac OS X and the {{log:tail}} function within the
> karaf cli, no logs are displayed unless you press enter or any other input.
> Further to this: pressing {{ctrl + c}} will drop out of the shell completely
> rather than go back to the main prompt.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (KARAF-5119) log:tail on OSX does not display updates without user input and exits shell on ctrl + c
[
https://issues.apache.org/jira/browse/KARAF-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned KARAF-5119:
--
Assignee: Christian Schneider (was: Jean-Baptiste Onofré)
> log:tail on OSX does not display updates without user input and exits shell
> on ctrl + c
> ---
>
> Key: KARAF-5119
> URL: https://issues.apache.org/jira/browse/KARAF-5119
> Project: Karaf
> Issue Type: Bug
> Components: karaf-shell
>Affects Versions: 4.1.1
> Environment: Mac OS X
>Reporter: Cetra Free
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> When trying to use 4.1.1 on Mac OS X and the {{log:tail}} function within the
> karaf cli, no logs are displayed unless you press enter or any other input.
> Further to this: pressing {{ctrl + c}} will drop out of the shell completely
> rather than go back to the main prompt.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5259) Duplicate log entries displayed when using log:tail
[ https://issues.apache.org/jira/browse/KARAF-5259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108613#comment-16108613 ] Christian Schneider commented on KARAF-5259: Can you check this again with the current code? > Duplicate log entries displayed when using log:tail > --- > > Key: KARAF-5259 > URL: https://issues.apache.org/jira/browse/KARAF-5259 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Windows 7 SP1 Java 8 U131 >Reporter: Scott Leschke >Assignee: Jean-Baptiste Onofré > Fix For: 4.2.0, 4.1.2 > > > I've mentioned this on the email list before but neglected to create a ticket > for it. > log:tail prints a large number of duplicate messages to the console. 4-6 is > common. The duplicates are not in the actual log file, they're just displayed > in the console window. > When I originally mentioned this, I believe it was said that this appeared to > be a Windows specific issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reopened KARAF-4655:
Damn .. missunderstood .. I only tested in karaf. Will look into it.
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108592#comment-16108592
]
Christian Schneider commented on KARAF-4655:
I just also tested in karaf 4.0.8 and it worked too.
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-4655.
Resolution: Cannot Reproduce
I can not reproduce this issue with current master or karaf-4.1.x branch. Can
you check if this is also fixed for you?
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.1.2, 4.0.10
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (KARAF-4655) karaf-maven-plugin add-features-to-repo goal can't add Camel feature
[
https://issues.apache.org/jira/browse/KARAF-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated KARAF-4655:
---
Fix Version/s: (was: 4.0.10)
4.2.0
> karaf-maven-plugin add-features-to-repo goal can't add Camel feature
>
>
> Key: KARAF-4655
> URL: https://issues.apache.org/jira/browse/KARAF-4655
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Igor Lazebny
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
> Attachments: pom.xml
>
>
> camel-restlet 2.17.3 feature contains bundle reference like this:
> {{ dependency="true">mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6}}
> add-features-to-repo can't interpret it correctly trying to connect to
> "id=restlet" host:
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.0.6-SNAPSHOT:features-add-to-repository
> (add-features-to-repo) on project karaf-maven-plugin-test: Error populating
> repository: Error resolving feature camel-restlet/2.17.3: Error resolving
> artifact
> mvn:http://maven.restlet.org@id=restlet!org.restlet.osgi/org.restlet/2.3.6:
> Can't resolve artifact org.restlet.osgi:org.restlet:jar:2.3.6: Could not
> transfer artifact org.restlet.osgi:org.restlet:jar:2.3.6 from/to
> http://maven.restlet.org@id=restlet (http://id=restlet): id=restlet: unknown
> error
> [ERROR] org.restlet.osgi:org.restlet:jar:2.3.6
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] http://maven.restlet.org@id=restlet (http://id=restlet,
> releases=true, snapshots=true): Unknown host id=restlet: unknown error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-5115) Error while installing cxf
[
https://issues.apache.org/jira/browse/KARAF-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-5115.
Resolution: Fixed
This should be fixed with the update to felix 5.6.6. and the shell issues I
fixed.
> Error while installing cxf
> --
>
> Key: KARAF-5115
> URL: https://issues.apache.org/jira/browse/KARAF-5115
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.1
> Environment: Windows 10 64bit
> Java JDK 1.8.0_131
>Reporter: Massimo Bono
>Assignee: Christian Schneider
> Labels: features
> Fix For: 4.2.0, 4.1.2
>
> Attachments: karaf.log, karaf_log_install_ukelonn.zip
>
>
> Hello,
> I was trying to create a REST application with karaf.
> I know there are examples over the internet showing how this can be achieved
> (like [this
> one|http://liquid-reality.de:8090/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi]),
> but usually they use blueprints as DI. My goal is to use Declarative Service
> instead.
> I followed this
> [guide|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=55153391]:
> it uses Karaf 3.0.3 and CXF 3.1.0, but I **think** it should work with 4.1.1
> as well.
> By doing the following:
> {code}
> karaf@root()> feature:install scr http pax-cdi-web-weld
> karaf@root()> feature:repo-add cxf 3.1.11
> Adding feature url mvn:org.apache.cxf.karaf/apache-cxf/3.1.11/xml/features
> karaf@root()> feature:install cxf/3.1.11 cxf-jaxrs-cdi/3.1.11
> {code}
> Karaf gives the following error:
> {code}
> java.lang.IllegalStateException: No inital startlevel yet
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.setStartLevel(FrameworkStartLevelImpl.java:131)
> at org.apache.karaf.main.Main.setStartLevel(Main.java:605)
> at
> org.apache.karaf.main.Main$KarafLockCallback.lockAquired(Main.java:711)
> at org.apache.karaf.main.Main.doMonitor(Main.java:382)
> at org.apache.karaf.main.Main.access$100(Main.java:75)
> at org.apache.karaf.main.Main$3.run(Main.java:369)
> {code}
> Furthermore, karaf *won't* return the console control to me, but remains
> stuck waiting nothing.
> It's highly possible that my procedure to install pax-cdi and cxf is flawed,
> but I still think that showing that error on the console and letting the
> shell going unresponsive are a bug of karaf (or a bug of the underlying OSGi
> framework, aka felix itself).
> Sorry if this behaviour is not a bug at all, but is just caused by my
> ignorance of the tool.
> Regards,
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-5280) Shell should not display the welcome message again when it is restarted
[
https://issues.apache.org/jira/browse/KARAF-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-5280.
Resolution: Fixed
> Shell should not display the welcome message again when it is restarted
> ---
>
> Key: KARAF-5280
> URL: https://issues.apache.org/jira/browse/KARAF-5280
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-shell
>Affects Versions: 4.2.0, 4.1.1
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> When updating the shell explicitly or during a feature install or uninstall
> we see this welcome message:
> {{__ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.2.0-SNAPSHOT)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> }}
> To reproduce do:
> update org.apache.karaf.shell.core
> While the welcome message makes sense when karaf starts it is confusing when
> installing or uninstalling a feature. So I propose we store that we already
> displayed the welcome message and then do not display it again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (KARAF-5280) Shell should not display the welcome message again when it is restarted
[
https://issues.apache.org/jira/browse/KARAF-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reopened KARAF-5280:
The current solution also suppresses the welcome on ssh which is not desired.
Need to fix that.
> Shell should not display the welcome message again when it is restarted
> ---
>
> Key: KARAF-5280
> URL: https://issues.apache.org/jira/browse/KARAF-5280
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-shell
>Affects Versions: 4.2.0, 4.1.1
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> When updating the shell explicitly or during a feature install or uninstall
> we see this welcome message:
> {{__ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.2.0-SNAPSHOT)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> }}
> To reproduce do:
> update org.apache.karaf.shell.core
> While the welcome message makes sense when karaf starts it is confusing when
> installing or uninstalling a feature. So I propose we store that we already
> displayed the welcome message and then do not display it again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (KARAF-5103) Quick start fails at the step "feature:install camel-spring"
[
https://issues.apache.org/jira/browse/KARAF-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107525#comment-16107525
]
Christian Schneider edited comment on KARAF-5103 at 7/31/17 4:21 PM:
-
This issue is fixed in later camel versions.
Try:
feature:repo-add camel 2.18.4
feature:install camel-spring
was (Author: ch...@die-schneider.net):
This issue is fixed in later camel versions.
Try:
{{feature:repo-add camel 2.18.4
feature:install camel-spring}}
> Quick start fails at the step "feature:install camel-spring"
>
>
> Key: KARAF-5103
> URL: https://issues.apache.org/jira/browse/KARAF-5103
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.1
> Environment: Ubuntu 14.04
>Reporter: Mike Fogg
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> The quick start results in an error when entering the command to install
> camel-spring.
> karaf@root()> feature:install camel-spring
> Error executing command: Unable to resolve root: missing requirement [root]
> osgi.identity; osgi.identity=camel-spring; type=karaf.feature;
> version="[2.15.2,2.15.2]";
> filter:="(&(osgi.identity=camel-spring)(type=karaf.feature)(version>=2.15.2)(version<=2.15.2))"
> [caused by: Unable to resolve camel-spring/2.15.2: missing requirement
> [camel-spring/2.15.2] osgi.identity; osgi.identity=spring;
> type=karaf.feature; version="[3.2.0,4.0.0)"]
> It sounds like this is related to KARAF-4730, however since this is the first
> thing I have tried after installing and is my introduction to Karaf (as it
> would be presumably for anyone going through the Quick Start), I don't know
> how I would go about removing the filter from the camel-spring dependency in
> order to install it. Considering this is a quick start, I probably shouldn't
> have to do anything that isn't spelled out in the instructions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-5103) Quick start fails at the step "feature:install camel-spring"
[
https://issues.apache.org/jira/browse/KARAF-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-5103.
Resolution: Fixed
This issue is fixed in later camel versions.
Try:
{{feature:repo-add camel 2.18.4
feature:install camel-spring}}
> Quick start fails at the step "feature:install camel-spring"
>
>
> Key: KARAF-5103
> URL: https://issues.apache.org/jira/browse/KARAF-5103
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.1
> Environment: Ubuntu 14.04
>Reporter: Mike Fogg
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> The quick start results in an error when entering the command to install
> camel-spring.
> karaf@root()> feature:install camel-spring
> Error executing command: Unable to resolve root: missing requirement [root]
> osgi.identity; osgi.identity=camel-spring; type=karaf.feature;
> version="[2.15.2,2.15.2]";
> filter:="(&(osgi.identity=camel-spring)(type=karaf.feature)(version>=2.15.2)(version<=2.15.2))"
> [caused by: Unable to resolve camel-spring/2.15.2: missing requirement
> [camel-spring/2.15.2] osgi.identity; osgi.identity=spring;
> type=karaf.feature; version="[3.2.0,4.0.0)"]
> It sounds like this is related to KARAF-4730, however since this is the first
> thing I have tried after installing and is my introduction to Karaf (as it
> would be presumably for anyone going through the Quick Start), I don't know
> how I would go about removing the filter from the camel-spring dependency in
> order to install it. Considering this is a quick start, I probably shouldn't
> have to do anything that isn't spelled out in the instructions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-5280) Shell should not display the welcome message again when it is restarted
[
https://issues.apache.org/jira/browse/KARAF-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-5280.
Resolution: Fixed
> Shell should not display the welcome message again when it is restarted
> ---
>
> Key: KARAF-5280
> URL: https://issues.apache.org/jira/browse/KARAF-5280
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-shell
>Affects Versions: 4.2.0, 4.1.1
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
>
> When updating the shell explicitly or during a feature install or uninstall
> we see this welcome message:
> {{__ __
>/ //_/ __ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (4.2.0-SNAPSHOT)
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> }}
> To reproduce do:
> update org.apache.karaf.shell.core
> While the welcome message makes sense when karaf starts it is confusing when
> installing or uninstalling a feature. So I propose we store that we already
> displayed the welcome message and then do not display it again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (KARAF-5280) Shell should not display the welcome message again when it is restarted
Christian Schneider created KARAF-5280:
--
Summary: Shell should not display the welcome message again when
it is restarted
Key: KARAF-5280
URL: https://issues.apache.org/jira/browse/KARAF-5280
Project: Karaf
Issue Type: Improvement
Components: karaf-shell
Affects Versions: 4.1.1, 4.2.0
Reporter: Christian Schneider
Assignee: Christian Schneider
Fix For: 4.2.0, 4.1.2
When updating the shell explicitly or during a feature install or uninstall we
see this welcome message:
{{__ __
/ //_/ __ _/ __/
/ ,< / __ `/ ___/ __ `/ /_
/ /| |/ /_/ / / / /_/ / __/
/_/ |_|\__,_/_/ \__,_/_/
Apache Karaf (4.2.0-SNAPSHOT)
Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
}}
To reproduce do:
update org.apache.karaf.shell.core
While the welcome message makes sense when karaf starts it is confusing when
installing or uninstalling a feature. So I propose we store that we already
displayed the welcome message and then do not display it again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (KARAF-5103) Quick start fails at the step "feature:install camel-spring"
[ https://issues.apache.org/jira/browse/KARAF-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107446#comment-16107446 ] Christian Schneider commented on KARAF-5103: What quick start are you talking about? Can you point to a URL? > Quick start fails at the step "feature:install camel-spring" > > > Key: KARAF-5103 > URL: https://issues.apache.org/jira/browse/KARAF-5103 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Ubuntu 14.04 >Reporter: Mike Fogg >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > The quick start results in an error when entering the command to install > camel-spring. > karaf@root()> feature:install camel-spring > Error executing command: Unable to resolve root: missing requirement [root] > osgi.identity; osgi.identity=camel-spring; type=karaf.feature; > version="[2.15.2,2.15.2]"; > filter:="(&(osgi.identity=camel-spring)(type=karaf.feature)(version>=2.15.2)(version<=2.15.2))" > [caused by: Unable to resolve camel-spring/2.15.2: missing requirement > [camel-spring/2.15.2] osgi.identity; osgi.identity=spring; > type=karaf.feature; version="[3.2.0,4.0.0)"] > It sounds like this is related to KARAF-4730, however since this is the first > thing I have tried after installing and is my introduction to Karaf (as it > would be presumably for anyone going through the Quick Start), I don't know > how I would go about removing the filter from the camel-spring dependency in > order to install it. Considering this is a quick start, I probably shouldn't > have to do anything that isn't spelled out in the instructions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5279) InterruptedException when updating the shell.core bundle
[ https://issues.apache.org/jira/browse/KARAF-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107331#comment-16107331 ] Christian Schneider commented on KARAF-5279: I did the commit with the wrong jra id 5072 > InterruptedException when updating the shell.core bundle > > > Key: KARAF-5279 > URL: https://issues.apache.org/jira/browse/KARAF-5279 > Project: Karaf > Issue Type: Bug > Components: karaf-shell >Affects Versions: 4.1.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > update org.apache.karaf.shell.core > There are two InterruptedExceptions. This issue is mainly about the second > one. > It seems to hint that the start of a bundles extensions did not finish which > is not true. > I found that started.await() always throws InterruptedException if the thread > was interrupted even if the countdown latch for started already finished. > 2017-07-31T15:33:53,571 | ERROR | Karaf local console user karaf | ShellUtil > | 42 - org.apache.karaf.shell.core - 4.2.0.SNAPSHOT | > Exception caught while executing command > java.lang.InterruptedException: null > at java.lang.Object.wait(Native Method) ~[?:?] > at java.lang.Object.wait(Object.java:502) [?:?] > at > org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.start(CommandSessionImpl.java:772) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:295) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:168) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:148) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:168) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:363) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at java.lang.Thread.run(Thread.java:748) [?:?] > 2017-07-31T15:34:20,192 | WARN | pipe-update 42 | CommandExtension > | 42 - org.apache.karaf.shell.core - 4.2.0.SNAPSHOT | The wait for > bundle org.apache.karaf.service.core being started before destruction has > been interrupted. > java.lang.InterruptedException: null > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326) > [?:?] > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > [?:?] > at > org.apache.karaf.shell.impl.action.osgi.CommandExtension.destroy(CommandExtension.java:125) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:285) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] > at > org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:307) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.utils.extender.AbstractExtender.stop(AbstractExtender.java:125) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.osgi.Activator.stop(Activator.java:128) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719) > [?:?] > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2632) [?:?] > at org.apache.felix.framework.Felix.updateBundle(Felix.java:2366) [?:?] > at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1018) > [?:?] > at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1004) > [?:?] > at org.apache.karaf.bundle.command.Update.doExecute(Update.java:57) > [21:org.apache.karaf.bundle.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.bundle.command.BundleCommand.execute(BundleCommand.java:46) > [21:org.apache.karaf.bundle.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) >
[jira] [Resolved] (KARAF-5279) InterruptedException when updating the shell.core bundle
[ https://issues.apache.org/jira/browse/KARAF-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5279. Resolution: Fixed Fix Version/s: 4.1.2 > InterruptedException when updating the shell.core bundle > > > Key: KARAF-5279 > URL: https://issues.apache.org/jira/browse/KARAF-5279 > Project: Karaf > Issue Type: Bug > Components: karaf-shell >Affects Versions: 4.1.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > update org.apache.karaf.shell.core > There are two InterruptedExceptions. This issue is mainly about the second > one. > It seems to hint that the start of a bundles extensions did not finish which > is not true. > I found that started.await() always throws InterruptedException if the thread > was interrupted even if the countdown latch for started already finished. > 2017-07-31T15:33:53,571 | ERROR | Karaf local console user karaf | ShellUtil > | 42 - org.apache.karaf.shell.core - 4.2.0.SNAPSHOT | > Exception caught while executing command > java.lang.InterruptedException: null > at java.lang.Object.wait(Native Method) ~[?:?] > at java.lang.Object.wait(Object.java:502) [?:?] > at > org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.start(CommandSessionImpl.java:772) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:295) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:168) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:148) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:168) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:363) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at java.lang.Thread.run(Thread.java:748) [?:?] > 2017-07-31T15:34:20,192 | WARN | pipe-update 42 | CommandExtension > | 42 - org.apache.karaf.shell.core - 4.2.0.SNAPSHOT | The wait for > bundle org.apache.karaf.service.core being started before destruction has > been interrupted. > java.lang.InterruptedException: null > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326) > [?:?] > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > [?:?] > at > org.apache.karaf.shell.impl.action.osgi.CommandExtension.destroy(CommandExtension.java:125) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:285) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] > at > org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:307) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.utils.extender.AbstractExtender.stop(AbstractExtender.java:125) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.osgi.Activator.stop(Activator.java:128) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719) > [?:?] > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2632) [?:?] > at org.apache.felix.framework.Felix.updateBundle(Felix.java:2366) [?:?] > at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1018) > [?:?] > at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1004) > [?:?] > at org.apache.karaf.bundle.command.Update.doExecute(Update.java:57) > [21:org.apache.karaf.bundle.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.bundle.command.BundleCommand.execute(BundleCommand.java:46) > [21:org.apache.karaf.bundle.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) > [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] > at
[jira] [Updated] (KARAF-5072) Add setting to ssh server for forcing a provided key
[ https://issues.apache.org/jira/browse/KARAF-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5072: --- Fix Version/s: 4.2.0 > Add setting to ssh server for forcing a provided key > > > Key: KARAF-5072 > URL: https://issues.apache.org/jira/browse/KARAF-5072 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Affects Versions: 4.1.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > If karaf does not find a server key in etc/hosts.key it will create one and > save it. > If the key is present but invalid it will be overwritten by default. > If overwrite=false in the settings and the provided key is invalid then karaf > will create a key on every first ssh connect after a restart. > I think it would be better to have a setting to force the provided key to be > used and throw an exception if it is invalid. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5279) InterruptedException when updating the shell.core bundle
Christian Schneider created KARAF-5279: -- Summary: InterruptedException when updating the shell.core bundle Key: KARAF-5279 URL: https://issues.apache.org/jira/browse/KARAF-5279 Project: Karaf Issue Type: Bug Components: karaf-shell Affects Versions: 4.1.1 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 update org.apache.karaf.shell.core There are two InterruptedExceptions. This issue is mainly about the second one. It seems to hint that the start of a bundles extensions did not finish which is not true. I found that started.await() always throws InterruptedException if the thread was interrupted even if the countdown latch for started already finished. 2017-07-31T15:33:53,571 | ERROR | Karaf local console user karaf | ShellUtil | 42 - org.apache.karaf.shell.core - 4.2.0.SNAPSHOT | Exception caught while executing command java.lang.InterruptedException: null at java.lang.Object.wait(Native Method) ~[?:?] at java.lang.Object.wait(Object.java:502) [?:?] at org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.start(CommandSessionImpl.java:772) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:295) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:168) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:148) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:168) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:363) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at java.lang.Thread.run(Thread.java:748) [?:?] 2017-07-31T15:34:20,192 | WARN | pipe-update 42 | CommandExtension | 42 - org.apache.karaf.shell.core - 4.2.0.SNAPSHOT | The wait for bundle org.apache.karaf.service.core being started before destruction has been interrupted. java.lang.InterruptedException: null at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326) [?:?] at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) [?:?] at org.apache.karaf.shell.impl.action.osgi.CommandExtension.destroy(CommandExtension.java:125) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:285) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?] at org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:307) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.utils.extender.AbstractExtender.stop(AbstractExtender.java:125) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.karaf.shell.impl.console.osgi.Activator.stop(Activator.java:128) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719) [?:?] at org.apache.felix.framework.Felix.stopBundle(Felix.java:2632) [?:?] at org.apache.felix.framework.Felix.updateBundle(Felix.java:2366) [?:?] at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1018) [?:?] at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1004) [?:?] at org.apache.karaf.bundle.command.Update.doExecute(Update.java:57) [21:org.apache.karaf.bundle.core:4.2.0.SNAPSHOT] at org.apache.karaf.bundle.command.BundleCommand.execute(BundleCommand.java:46) [21:org.apache.karaf.bundle.core:4.2.0.SNAPSHOT] at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:571) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:497) [42:org.apache.karaf.shell.core:4.2.0.SNAPSHOT] at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:386)
[jira] [Resolved] (KARAF-5174) Uninstalling feature using liquibase-slf4j crashes karaf
[
https://issues.apache.org/jira/browse/KARAF-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved KARAF-5174.
Resolution: Fixed
This is resolved after updating to felix 5.6.6.
> Uninstalling feature using liquibase-slf4j crashes karaf
>
>
> Key: KARAF-5174
> URL: https://issues.apache.org/jira/browse/KARAF-5174
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.1
> Environment: Java 1.8 64 bit, windows 7 64bit, debian "jessie"
> GNU/linux 64bit
>Reporter: Steinar Bang
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
> Attachments: karaf.log.gz, karaf.zip
>
>
> To reproduce:
> # clone this project and build it with maven:
> {noformat}
> mkdir -p ~/git
> cd ~/git
> git clone https://github.com/steinarb/liquibase-karaf-feature/
> cd liquibase-karaf-feature
> mvn clean install
> {noformat}
> # start karaf and give the following commands to the karaf console:
> {noformat}
> feature:repo-add
> mvn:no.priv.bang.karaf/liquibase-core-karaf/LATEST/xml/features
> feature:install liquibase-core
> {noformat}
> # uninstall the feature
> {noformat}
> feature:uninstall liquibase-core
> {noformat}
> Karaf will now output the following and hang:
> {noformat}
> karaf@root()> feature:install liquibase-core
> karaf@root()> feature:uninstall liquibase-core
> karaf@root()>
> java.lang.IllegalStateException: No inital startlevel yet
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.setStartLevel(FrameworkStartLevelImpl.java:131)
> at org.apache.karaf.main.Main.setStartLevel(Main.java:605)
> at
> org.apache.karaf.main.Main$KarafLockCallback.lockAquired(Main.java:711)
> at org.apache.karaf.main.Main.doMonitor(Main.java:382)
> at org.apache.karaf.main.Main.access$100(Main.java:75)
> at org.apache.karaf.main.Main$3.run(Main.java:369)
> {noformat}
> On karaf 4.0.7 the crash on uninstall doesn't happen.
> If the liquibase-slf4j fragment bundle is removed from the liquibase-core
> feature, the crash on uninstall doesn't happen.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-5278) Update to felix framework 5.6.6
[ https://issues.apache.org/jira/browse/KARAF-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5278. Resolution: Fixed > Update to felix framework 5.6.6 > --- > > Key: KARAF-5278 > URL: https://issues.apache.org/jira/browse/KARAF-5278 > Project: Karaf > Issue Type: Dependency upgrade > Components: karaf-core >Affects Versions: 4.2.0, 4.1.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > There is an issue about update of fragments in felix 5.6.4. This is fixed in > 5.6.6 so we should update to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5278) Update to felix framework 5.6.6
Christian Schneider created KARAF-5278: -- Summary: Update to felix framework 5.6.6 Key: KARAF-5278 URL: https://issues.apache.org/jira/browse/KARAF-5278 Project: Karaf Issue Type: Dependency upgrade Components: karaf-core Affects Versions: 4.1.1, 4.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0, 4.1.2 There is an issue about update of fragments in felix 5.6.4. This is fixed in 5.6.6 so we should update to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (KARAF-5174) Uninstalling feature using liquibase-slf4j crashes karaf
[
https://issues.apache.org/jira/browse/KARAF-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned KARAF-5174:
--
Assignee: Christian Schneider
> Uninstalling feature using liquibase-slf4j crashes karaf
>
>
> Key: KARAF-5174
> URL: https://issues.apache.org/jira/browse/KARAF-5174
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.1.1
> Environment: Java 1.8 64 bit, windows 7 64bit, debian "jessie"
> GNU/linux 64bit
>Reporter: Steinar Bang
>Assignee: Christian Schneider
> Fix For: 4.2.0, 4.1.2
>
> Attachments: karaf.log.gz, karaf.zip
>
>
> To reproduce:
> # clone this project and build it with maven:
> {noformat}
> mkdir -p ~/git
> cd ~/git
> git clone https://github.com/steinarb/liquibase-karaf-feature/
> cd liquibase-karaf-feature
> mvn clean install
> {noformat}
> # start karaf and give the following commands to the karaf console:
> {noformat}
> feature:repo-add
> mvn:no.priv.bang.karaf/liquibase-core-karaf/LATEST/xml/features
> feature:install liquibase-core
> {noformat}
> # uninstall the feature
> {noformat}
> feature:uninstall liquibase-core
> {noformat}
> Karaf will now output the following and hang:
> {noformat}
> karaf@root()> feature:install liquibase-core
> karaf@root()> feature:uninstall liquibase-core
> karaf@root()>
> java.lang.IllegalStateException: No inital startlevel yet
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.setStartLevel(FrameworkStartLevelImpl.java:131)
> at org.apache.karaf.main.Main.setStartLevel(Main.java:605)
> at
> org.apache.karaf.main.Main$KarafLockCallback.lockAquired(Main.java:711)
> at org.apache.karaf.main.Main.doMonitor(Main.java:382)
> at org.apache.karaf.main.Main.access$100(Main.java:75)
> at org.apache.karaf.main.Main$3.run(Main.java:369)
> {noformat}
> On karaf 4.0.7 the crash on uninstall doesn't happen.
> If the liquibase-slf4j fragment bundle is removed from the liquibase-core
> feature, the crash on uninstall doesn't happen.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (KARAF-5266) log commands should limit number of lines printed instead of number of log entries
[ https://issues.apache.org/jira/browse/KARAF-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5266. Resolution: Fixed > log commands should limit number of lines printed instead of number of log > entries > -- > > Key: KARAF-5266 > URL: https://issues.apache.org/jira/browse/KARAF-5266 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > log:tail only shows the n last log entries. Still sometimes it looks like it > shows masses of log data. This is when you have stack traces in the log. A > full stack trace only counts as one line currently. I think a good > enhancement would be to change the logic to really only show n lines instead > of n log records. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5276) Do not use right prompt by default
[ https://issues.apache.org/jira/browse/KARAF-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5276. Resolution: Fixed > Do not use right prompt by default > -- > > Key: KARAF-5276 > URL: https://issues.apache.org/jira/browse/KARAF-5276 > Project: Karaf > Issue Type: Bug > Components: karaf-shell >Affects Versions: 4.1.1 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > Currently karaf displays the data on the right side of the prompt. This often > causes problems when changing the window size for me. > Besides I do not see any added value by seeing the time there. > So I propose to switch off setting the right prompt by default. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5276) Do not use right prompt by default
Christian Schneider created KARAF-5276: -- Summary: Do not use right prompt by default Key: KARAF-5276 URL: https://issues.apache.org/jira/browse/KARAF-5276 Project: Karaf Issue Type: Bug Components: karaf-shell Affects Versions: 4.1.1 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0, 4.1.2 Currently karaf displays the data on the right side of the prompt. This often causes problems when changing the window size for me. Besides I do not see any added value by seeing the time there. So I propose to switch off setting the right prompt by default. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5266) log commands should limit number of lines printed instead of number of log entries
[ https://issues.apache.org/jira/browse/KARAF-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5266: --- Fix Version/s: 4.1.2 > log commands should limit number of lines printed instead of number of log > entries > -- > > Key: KARAF-5266 > URL: https://issues.apache.org/jira/browse/KARAF-5266 > Project: Karaf > Issue Type: Improvement > Components: karaf-shell >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > log:tail only shows the n last log entries. Still sometimes it looks like it > shows masses of log data. This is when you have stack traces in the log. A > full stack trace only counts as one line currently. I think a good > enhancement would be to change the logic to really only show n lines instead > of n log records. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5267) Karaf does not work correctly after log:tail
[ https://issues.apache.org/jira/browse/KARAF-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5267: --- Fix Version/s: 4.1.2 > Karaf does not work correctly after log:tail > > > Key: KARAF-5267 > URL: https://issues.apache.org/jira/browse/KARAF-5267 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.2.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > > To reproduce: > Start karaf > log:tail > Ctrl-C > Hit the up key > The shell will display OC and not go up the history. > I think this is because the threads are not stopped correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5267) Karaf does not work correctly after log:tail
[ https://issues.apache.org/jira/browse/KARAF-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5267. Resolution: Fixed > Karaf does not work correctly after log:tail > > > Key: KARAF-5267 > URL: https://issues.apache.org/jira/browse/KARAF-5267 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.2.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > To reproduce: > Start karaf > log:tail > Ctrl-C > Hit the up key > The shell will display OC and not go up the history. > I think this is because the threads are not stopped correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5078) Shell crash
[ https://issues.apache.org/jira/browse/KARAF-5078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096205#comment-16096205 ] Christian Schneider commented on KARAF-5078: I just tried karaf 4.2.0-SNAPSHOT on windows 7 Pro and java 8. I can not reproduce any crash with help or some other commands I tried. The colors look also much better now. [~scott.y] Can you also try with karaf 4.2.0-SNAPSHOT. If this works we just have to see how to get it backported to 4.1.2. > Shell crash > --- > > Key: KARAF-5078 > URL: https://issues.apache.org/jira/browse/KARAF-5078 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Windows 7 >Reporter: Scott Leschke >Assignee: Christian Schneider >Priority: Critical > Fix For: 4.1.2 > > > Karaf shell behaves badly in Windows console. It appears better than 4.1.0 > but still a problem. Command string start out red and turns dark blue while > typing become virtually unreadable. > Most problematic though is that the shell crashed and brought down Karaf as a > result of entering the word "bundle" at the console prompt. After the > following tracebacks, the Felix shutdown sequence is displayed in the log. > 2017-03-31T09:56:38,363 | ERROR | Karaf local console user karaf | ShellUtil > | 42 - org.apache.karaf.shell.core - 4.1.1 | Exception > caught while executing command > java.lang.NumberFormatException: For input string: "1B" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > ~[?:?] > at java.lang.Integer.parseInt(Integer.java:580) ~[?:?] > at java.lang.Integer.parseInt(Integer.java:615) ~[?:?] > at > org.jline.terminal.impl.jna.win.WindowsAnsiOutputStream.write(WindowsAnsiOutputStream.java:189) > ~[?:?] > at java.io.FilterOutputStream.write(FilterOutputStream.java:125) ~[?:?] > at > java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458) > ~[?:?] > at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:644) > ~[42:org.apache.karaf.shell.core:4.1.1] > at java.nio.channels.Channels.writeFullyImpl(Channels.java:78) ~[?:?] > at java.nio.channels.Channels.writeFully(Channels.java:101) ~[?:?] > at java.nio.channels.Channels.access$000(Channels.java:61) ~[?:?] > at java.nio.channels.Channels$1.write(Channels.java:174) ~[?:?] > at java.io.PrintStream.write(PrintStream.java:480) ~[?:?] > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) ~[?:?] > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > ~[?:?] > at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) ~[?:?] > at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) > ~[?:?] > at java.io.PrintStream.write(PrintStream.java:527) ~[?:?] > at java.io.PrintStream.print(PrintStream.java:669) ~[?:?] > at java.io.PrintStream.println(PrintStream.java:806) ~[?:?] > at org.apache.felix.gogo.jline.Posix._main(Posix.java:134) > ~[42:org.apache.karaf.shell.core:4.1.1] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[?:?] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[?:?] > at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?] > at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:136) > ~[42:org.apache.karaf.shell.core:4.1.1] > at > org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.lambda$wrap$0(SessionFactoryImpl.java:195) > ~[42:org.apache.karaf.shell.core:4.1.1] > at > org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.execute(SessionFactoryImpl.java:241) > [42:org.apache.karaf.shell.core:4.1.1] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) > [42:org.apache.karaf.shell.core:4.1.1] > at > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) > [42:org.apache.karaf.shell.core:4.1.1] > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:560) > [42:org.apache.karaf.shell.core:4.1.1] > at > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:486) > [42:org.apache.karaf.shell.core:4.1.1] > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:375) > [42:org.apache.karaf.shell.core:4.1.1] > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417) > [42:org.apache.karaf.shell.core:4.1.1] > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) > [42:org.apache.karaf.shell.core:4.1.1] > at
[jira] [Created] (KARAF-5267) Karaf does not work correctly after log:tail
Christian Schneider created KARAF-5267: -- Summary: Karaf does not work correctly after log:tail Key: KARAF-5267 URL: https://issues.apache.org/jira/browse/KARAF-5267 Project: Karaf Issue Type: Bug Affects Versions: 4.2.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 To reproduce: Start karaf log:tail Ctrl-C Hit the up key The shell will display OC and not go up the history. I think this is because the threads are not stopped correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5260) log:tail default should start at the end of the file
[ https://issues.apache.org/jira/browse/KARAF-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5260. Resolution: Not A Bug Closing this issue as the current behaviour is working as designed. I will try to improve the behaviour in the linked issue. > log:tail default should start at the end of the file > > > Key: KARAF-5260 > URL: https://issues.apache.org/jira/browse/KARAF-5260 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Windows 7 >Reporter: Scott Leschke >Assignee: Christian Schneider >Priority: Minor > Fix For: 4.2.0, 4.1.2 > > > I would suggest that the default for the log:tail command refrain from > dumping the entire contents of the log file to the console prior to tailing > and rather just start tailing at the end of the file. Given the general use > of the command, having all the prior log statements written to the console > every time the command is used is not helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5260) log:tail default should start at the end of the file
[ https://issues.apache.org/jira/browse/KARAF-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094710#comment-16094710 ] Christian Schneider commented on KARAF-5260: I am opening a new issue for the change in the logging commands. As this title and description would be misleading. > log:tail default should start at the end of the file > > > Key: KARAF-5260 > URL: https://issues.apache.org/jira/browse/KARAF-5260 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Windows 7 >Reporter: Scott Leschke >Assignee: Christian Schneider >Priority: Minor > Fix For: 4.2.0, 4.1.2 > > > I would suggest that the default for the log:tail command refrain from > dumping the entire contents of the log file to the console prior to tailing > and rather just start tailing at the end of the file. Given the general use > of the command, having all the prior log statements written to the console > every time the command is used is not helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5266) log commands should limit number of lines printed instead of number of log entries
[ https://issues.apache.org/jira/browse/KARAF-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5266: --- Description: log:tail only shows the n last log entries. Still sometimes it looks like it shows masses of log data. This is when you have stack traces in the log. A full stack trace only counts as one line currently. I think a good enhancement would be to change the logic to really only show n lines instead of n log records. > log commands should limit number of lines printed instead of number of log > entries > -- > > Key: KARAF-5266 > URL: https://issues.apache.org/jira/browse/KARAF-5266 > Project: Karaf > Issue Type: Improvement >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > > log:tail only shows the n last log entries. Still sometimes it looks like it > shows masses of log data. This is when you have stack traces in the log. A > full stack trace only counts as one line currently. I think a good > enhancement would be to change the logic to really only show n lines instead > of n log records. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5266) log commands should limit number of lines printed instead of number of log entries
[ https://issues.apache.org/jira/browse/KARAF-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094709#comment-16094709 ] Christian Schneider commented on KARAF-5266: log:tail only shows the n last log entries. Still sometimes it looks like it shows masses of log data. This is when you have stack traces in the log. A full stack trace only counts as one line currently. I think a good enhancement would be to change the logic to really only show n lines instead of n log records. I can look into that. > log commands should limit number of lines printed instead of number of log > entries > -- > > Key: KARAF-5266 > URL: https://issues.apache.org/jira/browse/KARAF-5266 > Project: Karaf > Issue Type: Improvement >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (KARAF-5266) log commands should limit number of lines printed instead of number of log entries
[ https://issues.apache.org/jira/browse/KARAF-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5266: --- Comment: was deleted (was: log:tail only shows the n last log entries. Still sometimes it looks like it shows masses of log data. This is when you have stack traces in the log. A full stack trace only counts as one line currently. I think a good enhancement would be to change the logic to really only show n lines instead of n log records. I can look into that.) > log commands should limit number of lines printed instead of number of log > entries > -- > > Key: KARAF-5266 > URL: https://issues.apache.org/jira/browse/KARAF-5266 > Project: Karaf > Issue Type: Improvement >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5266) log commands should limit number of lines printed instead of number of log entries
Christian Schneider created KARAF-5266: -- Summary: log commands should limit number of lines printed instead of number of log entries Key: KARAF-5266 URL: https://issues.apache.org/jira/browse/KARAF-5266 Project: Karaf Issue Type: Improvement Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (KARAF-5260) log:tail default should start at the end of the file
[ https://issues.apache.org/jira/browse/KARAF-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned KARAF-5260: -- Assignee: Christian Schneider (was: Jean-Baptiste Onofré) > log:tail default should start at the end of the file > > > Key: KARAF-5260 > URL: https://issues.apache.org/jira/browse/KARAF-5260 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Windows 7 >Reporter: Scott Leschke >Assignee: Christian Schneider >Priority: Minor > Fix For: 4.2.0, 4.1.2 > > > I would suggest that the default for the log:tail command refrain from > dumping the entire contents of the log file to the console prior to tailing > and rather just start tailing at the end of the file. Given the general use > of the command, having all the prior log statements written to the console > every time the command is used is not helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5260) log:tail default should start at the end of the file
[ https://issues.apache.org/jira/browse/KARAF-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094645#comment-16094645 ] Christian Schneider commented on KARAF-5260: log:tail only shows the n last log entries. Still sometimes it looks like it shows masses of log data. This is when you have stack traces in the log. A full stack trace only counts as one line currently. I think a good enhancement would be to change the logic to really only show n lines instead of n log records. I can look into that. > log:tail default should start at the end of the file > > > Key: KARAF-5260 > URL: https://issues.apache.org/jira/browse/KARAF-5260 > Project: Karaf > Issue Type: Bug >Affects Versions: 4.1.1 > Environment: Windows 7 >Reporter: Scott Leschke >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 4.2.0, 4.1.2 > > > I would suggest that the default for the log:tail command refrain from > dumping the entire contents of the log file to the console prior to tailing > and rather just start tailing at the end of the file. Given the general use > of the command, having all the prior log statements written to the console > every time the command is used is not helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (KARAF-5237) Document how to use CXF LoggingFeature with decanter
[ https://issues.apache.org/jira/browse/KARAF-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated KARAF-5237: --- Fix Version/s: decanter-1.4.0 > Document how to use CXF LoggingFeature with decanter > > > Key: KARAF-5237 > URL: https://issues.apache.org/jira/browse/KARAF-5237 > Project: Karaf > Issue Type: Bug > Components: decanter >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: decanter-1.4.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5253) Update pax-jdbc to 1.1.0
[ https://issues.apache.org/jira/browse/KARAF-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5253. Resolution: Fixed > Update pax-jdbc to 1.1.0 > > > Key: KARAF-5253 > URL: https://issues.apache.org/jira/browse/KARAF-5253 > Project: Karaf > Issue Type: Dependency upgrade >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 4.2.0, 4.1.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KARAF-5253) Update pax-jdbc to 1.1.0
Christian Schneider created KARAF-5253: -- Summary: Update pax-jdbc to 1.1.0 Key: KARAF-5253 URL: https://issues.apache.org/jira/browse/KARAF-5253 Project: Karaf Issue Type: Dependency upgrade Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 4.2.0, 4.1.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5250) SNAPSHOT metadata doesn't match SNAPSHOT artifacts after mvn deploy
[
https://issues.apache.org/jira/browse/KARAF-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16086985#comment-16086985
]
Christian Schneider commented on KARAF-5250:
Nice. What did you change?
> SNAPSHOT metadata doesn't match SNAPSHOT artifacts after mvn deploy
> ---
>
> Key: KARAF-5250
> URL: https://issues.apache.org/jira/browse/KARAF-5250
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.2.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Critical
> Fix For: 4.2.0
>
>
> Original [message
> here|http://mail-archives.apache.org/mod_mbox/karaf-dev/201707.mbox/%3CCAAdXmhpQKJkvBkpp0v_AVKJCdEmkpOcgxn0meZ6gW1pKsvj4cQ%40mail.gmail.com%3E].
> First, an observation. If you check
> https://repository.apache.org/content/groups/snapshots-group/org/apache/karaf/webconsole/org.apache.karaf.webconsole.http/4.2.0-SNAPSHOT/maven-metadata.xml,
> you'll see this metadata declares latest SNAPSHOT version to be
> {{4.2.0-20170713.142530-162}}.
> But if you try to actually fetch this version (that's what Aether is doing),
> you'll get HTTP 404, because there's *no such version* - there's
> {{4.2.0-20170713.142529-162}} - 1 *second* difference, but very important -
> this SNAPSHOT is *not resolvable*.
> I started wondering about Nexus problems, about maven-deploy-plugin bugs, but
> then I run this under debugger. I didn't notice this problem when using Maven
> 3.5.0, but it failed under 3.3.9 (that's the version used by Jenkins).
> Another worrying sign was this log:
> {noformat}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> org.apache.karaf.features.core ---
> ...
> [INFO] Downloading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> [INFO] Downloaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> (315 B at 4.6 KB/sec)
> [INFO] Downloading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> [INFO] Downloaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> (315 B at 10.6 KB/sec)
> [INFO] Uploading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> (805 B at 31.4 KB/sec)
> [INFO] Uploading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> (805 B at 30.2 KB/sec)
> ...
> {noformat}
> It looked as duplicate metadata upload. I was fooled by reading
> maven-deploy-plugin source code, because it actually may upload metadata
> multiple times (in case of attached artifacts).
> But then, under debugger I saw this:
> {noformat}
> generators = {java.util.ArrayList@9874} size = 4
> 0 =
> {org.apache.maven.repository.internal.RemoteSnapshotMetadataGenerator@9881}
> snapshots: java.util.Map = {java.util.LinkedHashMap@9890} size = 0
> legacyFormat: boolean = false
> 1 =
> {org.apache.maven.repository.internal.RemoteSnapshotMetadataGenerator@9882}
> snapshots: java.util.Map = {java.util.LinkedHashMap@9889} size = 0
> legacyFormat: boolean = false
> 2 = {org.apache.maven.repository.internal.VersionsMetadataGenerator@9883}
> versions: java.util.Map = {java.util.LinkedHashMap@9887} size = 0
> processedVersions: java.util.Map = {java.util.LinkedHashMap@9888} size = 0
> 3 = {org.apache.maven.repository.internal.VersionsMetadataGenerator@9884}
> versions: java.util.Map = {java.util.LinkedHashMap@9885} size = 0
> processedVersions: java.util.Map = {java.util.LinkedHashMap@9886} size = 0
> {noformat}
> which means that
> {{org.eclipse.aether.internal.impl.DefaultDeployer#getMetadataGenerators()}}
> returned/used too many generators. And I found that *this is the root
> problem* - we have two instances of {{RemoteSnapshotMetadataGenerator}} and
> both may transform "SNAPSHOT" version to two different timestamped versions -
> then artifact is uploaded *once* (with first timestamped version) and then
> metadata is uploaded twice - first time with correct
[jira] [Commented] (KARAF-5250) SNAPSHOT metadata doesn't match SNAPSHOT artifacts in after mvn deploy
[
https://issues.apache.org/jira/browse/KARAF-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16086969#comment-16086969
]
Christian Schneider commented on KARAF-5250:
So does this mean we have to make sure to exclude a dependency in our pom?
Do you think it makes sense to try another maven version in jenkins?
Unfortunately 3.5.0 did not work the last time I tried it.
> SNAPSHOT metadata doesn't match SNAPSHOT artifacts in after mvn deploy
> --
>
> Key: KARAF-5250
> URL: https://issues.apache.org/jira/browse/KARAF-5250
> Project: Karaf
> Issue Type: Bug
> Components: karaf-tooling
>Affects Versions: 4.2.0
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Critical
> Fix For: 4.2.0
>
>
> Original [message
> here|http://mail-archives.apache.org/mod_mbox/karaf-dev/201707.mbox/%3CCAAdXmhpQKJkvBkpp0v_AVKJCdEmkpOcgxn0meZ6gW1pKsvj4cQ%40mail.gmail.com%3E].
> First, an observation. If you check
> https://repository.apache.org/content/groups/snapshots-group/org/apache/karaf/webconsole/org.apache.karaf.webconsole.http/4.2.0-SNAPSHOT/maven-metadata.xml,
> you'll see this metadata declares latest SNAPSHOT version to be
> {{4.2.0-20170713.142530-162}}.
> But if you try to actually fetch this version (that's what Aether is doing),
> you'll get HTTP 404, because there's *no such version* - there's
> {{4.2.0-20170713.142529-162}} - 1 *second* difference, but very important -
> this SNAPSHOT is *not resolvable*.
> I started wondering about Nexus problems, about maven-deploy-plugin bugs, but
> then I run this under debugger. I didn't notice this problem when using Maven
> 3.5.0, but it failed under 3.3.9 (that's the version used by Jenkins).
> Another worrying sign was this log:
> {noformat}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> org.apache.karaf.features.core ---
> ...
> [INFO] Downloading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> [INFO] Downloaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> (315 B at 4.6 KB/sec)
> [INFO] Downloading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> [INFO] Downloaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/maven-metadata.xml
> (315 B at 10.6 KB/sec)
> [INFO] Uploading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> (805 B at 31.4 KB/sec)
> [INFO] Uploading:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://localhost:8081/nexus/content/repositories/snapshots/org/apache/karaf/features/org.apache.karaf.features.core/4.2.0-SNAPSHOT/maven-metadata.xml
> (805 B at 30.2 KB/sec)
> ...
> {noformat}
> It looked as duplicate metadata upload. I was fooled by reading
> maven-deploy-plugin source code, because it actually may upload metadata
> multiple times (in case of attached artifacts).
> But then, under debugger I saw this:
> {noformat}
> generators = {java.util.ArrayList@9874} size = 4
> 0 =
> {org.apache.maven.repository.internal.RemoteSnapshotMetadataGenerator@9881}
> snapshots: java.util.Map = {java.util.LinkedHashMap@9890} size = 0
> legacyFormat: boolean = false
> 1 =
> {org.apache.maven.repository.internal.RemoteSnapshotMetadataGenerator@9882}
> snapshots: java.util.Map = {java.util.LinkedHashMap@9889} size = 0
> legacyFormat: boolean = false
> 2 = {org.apache.maven.repository.internal.VersionsMetadataGenerator@9883}
> versions: java.util.Map = {java.util.LinkedHashMap@9887} size = 0
> processedVersions: java.util.Map = {java.util.LinkedHashMap@9888} size = 0
> 3 = {org.apache.maven.repository.internal.VersionsMetadataGenerator@9884}
> versions: java.util.Map = {java.util.LinkedHashMap@9885} size = 0
> processedVersions: java.util.Map = {java.util.LinkedHashMap@9886} size = 0
> {noformat}
> which means that
> {{org.eclipse.aether.internal.impl.DefaultDeployer#getMetadataGenerators()}}
> returned/used too many generators. And I found that *this is the root
> problem* - we have two instances of {{RemoteSnapshotMetadataGenerator}} and
> both may transform "SNAPSHOT"
[jira] [Created] (KARAF-5244) Refactor kafka config handling
Christian Schneider created KARAF-5244: -- Summary: Refactor kafka config handling Key: KARAF-5244 URL: https://issues.apache.org/jira/browse/KARAF-5244 Project: Karaf Issue Type: Improvement Components: decanter Affects Versions: decanter-1.3.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: decanter-1.4.0 The config handling in kafka appender has a lot of duplication. We should refactor this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (KARAF-5069) Support include/exclude filter for topic for appenders
[ https://issues.apache.org/jira/browse/KARAF-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080533#comment-16080533 ] Christian Schneider commented on KARAF-5069: We already support to configure which topic to send events to for collectors. An appender can use the standard event admin properties event.topics and event.filter to specify which events to listen on. For 1.4.0 I think this should be good enough. We should discuss though how to make decanter more flexible in upcoming versions. > Support include/exclude filter for topic for appenders > -- > > Key: KARAF-5069 > URL: https://issues.apache.org/jira/browse/KARAF-5069 > Project: Karaf > Issue Type: New Feature > Components: decanter >Affects Versions: decanter-1.3.0 >Reporter: Oliver Wulff >Assignee: Jean-Baptiste Onofré > Fix For: decanter-1.4.0 > > > Some collector events should be sent to one appender (ex. kafka) whereas > other events to another appender (ex. camel) for custom enrichement of the > event. > Implementation proposal: > Every appender could provide an exclude and include property to configure to > which appender the events should be sent to. The exclude/include condition > could be based on the topic. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (KARAF-5237) Document how to use CXF LoggingFeature with decanter
[ https://issues.apache.org/jira/browse/KARAF-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved KARAF-5237. Resolution: Fixed > Document how to use CXF LoggingFeature with decanter > > > Key: KARAF-5237 > URL: https://issues.apache.org/jira/browse/KARAF-5237 > Project: Karaf > Issue Type: Bug > Components: decanter >Reporter: Christian Schneider >Assignee: Christian Schneider > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (KARAF-3890) Provide Decanter CXF interceptor collector
[ https://issues.apache.org/jira/browse/KARAF-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider closed KARAF-3890. -- Resolution: Won't Fix Fix Version/s: decanter-1.4.0 Will close this issue as we do not need addtional code. I linked to a new issue to document how to use CXF LoggingFeature with decanter. > Provide Decanter CXF interceptor collector > -- > > Key: KARAF-3890 > URL: https://issues.apache.org/jira/browse/KARAF-3890 > Project: Karaf > Issue Type: New Feature > Components: decanter >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: decanter-1.4.0 > > > In order to monitor and log CXF usage, it would be great to provide a ready > to use CXF interceptor that send an EventAdmin Event with CXF message details > (a bit like the Decanter Camel Tracer Collector). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
