[jira] [Updated] (KARAF-4159) FeatureResolver: Wrong dependencies installed

2015-12-01 Thread JIRA 

 [ 
https://issues.apache.org/jira/browse/KARAF-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

J. Brébec updated KARAF-4159:
-
Summary: FeatureResolver: Wrong dependencies installed  (was: 
FeatureResolver: Wrond dependencies installed)

> FeatureResolver: Wrong dependencies installed
> -
>
> Key: KARAF-4159
> URL: https://issues.apache.org/jira/browse/KARAF-4159
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.3
> Environment: Reproduced in MacOS (JRE1.8) or Windows 7 (JRE 1.7)
>Reporter: J. Brébec
>Priority: Critical
>
> In a fresh Karaf 4.0.3 installation
> 1. install spring/3.2.14.RELEASE_1
> {code}
> feature:install spring/3.2.14.RELEASE_1
> {code}
> 2. test an installation of spring-dm. Randomly, Karaf try to install spring 
> 3.1.4.RELEASE
> {code}
> karaf@root()> feature:install -t -v spring-dm
> Adding features: spring-dm/[1.2.1,1.2.1]
> Changes to perform:
>   Region: root
> Bundles to install:
>   mvn:org.apache.karaf.bundle/org.apache.karaf.bundle.springstate/4.0.3
>   
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.0_1
>   mvn:org.springframework/spring-aop/3.1.4.RELEASE
>   mvn:org.springframework/spring-asm/3.1.4.RELEASE
>   mvn:org.springframework/spring-beans/3.1.4.RELEASE
>   mvn:org.springframework/spring-context/3.1.4.RELEASE
>   mvn:org.springframework/spring-context-support/3.1.4.RELEASE
>   mvn:org.springframework/spring-core/3.1.4.RELEASE
>   mvn:org.springframework/spring-expression/3.1.4.RELEASE
>   mvn:org.springframework.osgi/spring-osgi-core/1.2.1
>   mvn:org.springframework.osgi/spring-osgi-extender/1.2.1
>   mvn:org.springframework.osgi/spring-osgi-annotation/1.2.1
>   mvn:org.springframework.osgi/spring-osgi-io/1.2.1
>   Bundles to refresh:
> org.apache.servicemix.bundles.spring-aop/3.2.14.RELEASE_1 (Wired to 
> org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 which is being 
> refreshed)
> org.apache.servicemix.bundles.spring-beans/3.2.14.RELEASE_1 (Wired to 
> org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 which is being 
> refreshed)
> org.apache.servicemix.bundles.spring-context/3.2.14.RELEASE_1 (Wired to 
> org.apache.servicemix.bundles.spring-aop/3.2.14.RELEASE_1 which is being 
> refreshed)
> org.apache.servicemix.bundles.spring-context-support/3.2.14.RELEASE_1 
> (Wired to org.apache.servicemix.bundles.spring-beans/3.2.14.RELEASE_1 which 
> is being refreshed)
> org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 (Should be 
> wired to: org.apache.servicemix.bundles.cglib/3.0.0.1 (through 
> [org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1] 
> osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=net.sf.cglib.beans)(version>=3.0.0)(!(version>=4.0.0)))";
>  resolution:=optional))
> org.apache.servicemix.bundles.spring-expression/3.2.14.RELEASE_1 (Wired 
> to org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 which is being 
> refreshed)
> {code} 
> Note: This can happen too when installing spring and spring-dm in the same 
> command or in a boot feature (staged or not).
> 3. install any unrelated feature (when spring-dm has installed spring 3.1) : 
> Karaf uninstall spring 3.1 and refresh the world
> {code}
> karaf@root()> feature:install -t -v scheduler 
> Adding features: scheduler/[4.0.3,4.0.3]
> Changes to perform:
>   Region: root
> Bundles to uninstall:
>   org.springframework.expression/3.1.4.RELEASE
>   org.springframework.context.support/3.1.4.RELEASE
>   org.springframework.core/3.1.4.RELEASE
>   org.springframework.beans/3.1.4.RELEASE
>   org.springframework.context/3.1.4.RELEASE
>   org.springframework.aop/3.1.4.RELEASE
>   org.springframework.asm/3.1.4.RELEASE
> Bundles to install:
>   mvn:org.apache.karaf.scheduler/org.apache.karaf.scheduler.core/4.0.3
>   Bundles to refresh:
> org.springframework.aop/3.1.4.RELEASE (Bundle will be uninstalled)
> org.springframework.asm/3.1.4.RELEASE (Bundle will be uninstalled)
> org.springframework.beans/3.1.4.RELEASE (Bundle will be uninstalled)
> org.springframework.context/3.1.4.RELEASE (Bundle will be uninstalled)
> org.springframework.context.support/3.1.4.RELEASE (Bundle will be 
> uninstalled)
> org.springframework.core/3.1.4.RELEASE (Bundle will be uninstalled)
> org.springframework.expression/3.1.4.RELEASE (Bundle will be uninstalled)
> {code}
> this is critical in my environment : a lot of dependencies don't work with 
> two versions of spring in the container. moreover, installing any feature 
> after that uninstall/refresh a lot of bundle (it uninstall unrelated bundle 
> too)



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

[jira] [Created] (KARAF-4159) FeatureResolver: Wrond dependencies installed

2015-12-01 Thread JIRA 
J. Brébec created KARAF-4159:


 Summary: FeatureResolver: Wrond dependencies installed
 Key: KARAF-4159
 URL: https://issues.apache.org/jira/browse/KARAF-4159
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Affects Versions: 4.0.3
 Environment: Reproduced in MacOS (JRE1.8) or Windows 7 (JRE 1.7)
Reporter: J. Brébec
Priority: Critical


In a fresh Karaf 4.0.3 installation

1. install spring/3.2.14.RELEASE_1
{code}
feature:install spring/3.2.14.RELEASE_1
{code}

2. test an installation of spring-dm. Randomly, Karaf try to install spring 
3.1.4.RELEASE
{code}
karaf@root()> feature:install -t -v spring-dm
Adding features: spring-dm/[1.2.1,1.2.1]
Changes to perform:
  Region: root
Bundles to install:
  mvn:org.apache.karaf.bundle/org.apache.karaf.bundle.springstate/4.0.3
  
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.0_1
  mvn:org.springframework/spring-aop/3.1.4.RELEASE
  mvn:org.springframework/spring-asm/3.1.4.RELEASE
  mvn:org.springframework/spring-beans/3.1.4.RELEASE
  mvn:org.springframework/spring-context/3.1.4.RELEASE
  mvn:org.springframework/spring-context-support/3.1.4.RELEASE
  mvn:org.springframework/spring-core/3.1.4.RELEASE
  mvn:org.springframework/spring-expression/3.1.4.RELEASE
  mvn:org.springframework.osgi/spring-osgi-core/1.2.1
  mvn:org.springframework.osgi/spring-osgi-extender/1.2.1
  mvn:org.springframework.osgi/spring-osgi-annotation/1.2.1
  mvn:org.springframework.osgi/spring-osgi-io/1.2.1
  Bundles to refresh:
org.apache.servicemix.bundles.spring-aop/3.2.14.RELEASE_1 (Wired to 
org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 which is being 
refreshed)
org.apache.servicemix.bundles.spring-beans/3.2.14.RELEASE_1 (Wired to 
org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 which is being 
refreshed)
org.apache.servicemix.bundles.spring-context/3.2.14.RELEASE_1 (Wired to 
org.apache.servicemix.bundles.spring-aop/3.2.14.RELEASE_1 which is being 
refreshed)
org.apache.servicemix.bundles.spring-context-support/3.2.14.RELEASE_1 
(Wired to org.apache.servicemix.bundles.spring-beans/3.2.14.RELEASE_1 which is 
being refreshed)
org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 (Should be wired 
to: org.apache.servicemix.bundles.cglib/3.0.0.1 (through 
[org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1] 
osgi.wiring.package; 
filter:="(&(osgi.wiring.package=net.sf.cglib.beans)(version>=3.0.0)(!(version>=4.0.0)))";
 resolution:=optional))
org.apache.servicemix.bundles.spring-expression/3.2.14.RELEASE_1 (Wired to 
org.apache.servicemix.bundles.spring-core/3.2.14.RELEASE_1 which is being 
refreshed)
{code} 

Note: This can happen too when installing spring and spring-dm in the same 
command or in a boot feature (staged or not).

3. install any unrelated feature (when spring-dm has installed spring 3.1) : 
Karaf uninstall spring 3.1 and refresh the world

{code}
karaf@root()> feature:install -t -v scheduler 
Adding features: scheduler/[4.0.3,4.0.3]
Changes to perform:
  Region: root
Bundles to uninstall:
  org.springframework.expression/3.1.4.RELEASE
  org.springframework.context.support/3.1.4.RELEASE
  org.springframework.core/3.1.4.RELEASE
  org.springframework.beans/3.1.4.RELEASE
  org.springframework.context/3.1.4.RELEASE
  org.springframework.aop/3.1.4.RELEASE
  org.springframework.asm/3.1.4.RELEASE
Bundles to install:
  mvn:org.apache.karaf.scheduler/org.apache.karaf.scheduler.core/4.0.3
  Bundles to refresh:
org.springframework.aop/3.1.4.RELEASE (Bundle will be uninstalled)
org.springframework.asm/3.1.4.RELEASE (Bundle will be uninstalled)
org.springframework.beans/3.1.4.RELEASE (Bundle will be uninstalled)
org.springframework.context/3.1.4.RELEASE (Bundle will be uninstalled)
org.springframework.context.support/3.1.4.RELEASE (Bundle will be 
uninstalled)
org.springframework.core/3.1.4.RELEASE (Bundle will be uninstalled)
org.springframework.expression/3.1.4.RELEASE (Bundle will be uninstalled)
{code}

this is critical in my environment : a lot of dependencies don't work with two 
versions of spring in the container. moreover, installing any feature after 
that uninstall/refresh a lot of bundle (it uninstall unrelated bundle too)



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

[jira] [Created] (KARAF-4158) Unexpected behavior on first startup

2015-12-01 Thread Jean-Philippe CLEMENT (JIRA) 
Jean-Philippe CLEMENT created KARAF-4158:


 Summary: Unexpected behavior on first startup
 Key: KARAF-4158
 URL: https://issues.apache.org/jira/browse/KARAF-4158
 Project: Karaf
  Issue Type: Bug
  Components: karaf-core
Affects Versions: 4.0.3
 Environment: RHEL 6.2 x32, Java 1.8.0_72-ea-b05
Reporter: Jean-Philippe CLEMENT


This problem only occurs on the very first startup of a custom assembly. This 
means unpacking the assembly .tar.gz then run karaf. This issue is not 100% 
reproducible. Several untar/run might be necessary to reproduce the issue.

The problem comes with Blueprint property-placeholders. User bundles might be 
started and not get .cfg replaced properties but the "$(PARAM_NAME)" itself 
(String property).

I suspect user bundles to be started before the .cfg files are populated in the 
/etc directory.



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

[jira] [Commented] (KARAF-3918) An installed blueprint.xml has always been updated and restarted when install another unrelated feature

2015-12-01 Thread Guillaume Nodet (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15034053#comment-15034053
 ] 

Guillaume Nodet commented on KARAF-3918:


Fwiw, both spring and blueprint deployers do scan the xml for bean classes and 
automatically generate import packages for those.  For blueprint, this may be 
sufficient.  For spring, one also needs to import the various custom namespace 
packages, and those can't easily be discovered.  Fortunately, this should be 
fixed when we switch to the spring support from Aries.
For blueprint, we may already be able to remove the dynamic imports, it needs 
to be tested a bit more.
And given there's no embedded classes, we don't really need to run BND, we 
simply run the xslt, which is/should be the same as the one used in the maven 
bundle plugin to discover the packages.

> An installed blueprint.xml has always been updated and restarted when install 
> another unrelated feature
> ---
>
> Key: KARAF-3918
> URL: https://issues.apache.org/jira/browse/KARAF-3918
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0
> Environment: Java 7
>Reporter: Xilai Dai
>Assignee: Jean-Baptiste Onofré
>
> There is an installed blueprint.xml. (by install -s 
> blueprint:mvn:org.abc/my-project/1.0-SNAPSHOT/xml, or deploy this 
> blueprint.xml into deploy folder).
> then, if you do feature:install , to install some other feature (no 
> dependencies to the blueprint.xml above), the installed blueprint.xml will 
> always be updated and restarted, that's not expected behavious.
> After checking with org.apache.karaf.features.internal.service.Deployer 
> class, I found that the old checksum will only be calculated in case of url 
> start with "jar:" (Line 1159), so in case of the url start with "blueprint:", 
> the new checksum will never equal with old checksum, then it will be put into 
> deployment.toUpdate Map.
> The Deployer class should be fixed for "blueprint:" deployment.



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

[jira] [Commented] (KARAF-3812) Exception caused by featuresRepositories property being set incorrectly

2015-12-01 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033435#comment-15033435
 ] 

ASF GitHub Bot commented on KARAF-3812:
---

GitHub user akuhtz opened a pull request:

https://github.com/apache/karaf/pull/112

Reverted changes of KARAF-3812.

Reverted changes of KARAF-3812 to let the karaf service start again if the 
path contains spaces under Windows.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/akuhtz/karaf KARAF-4138

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/karaf/pull/112.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #112


commit 78a99ea3fb9529e568bef07eb0e596dca568cf5a
Author: Andreas Kuhtz 
Date:   2015-12-01T09:48:38Z

Reverted changes of KARAF-3812.




> Exception caused by featuresRepositories property being set incorrectly
> ---
>
> Key: KARAF-3812
> URL: https://issues.apache.org/jira/browse/KARAF-3812
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0
>Reporter: Jonathan Byrne
>Assignee: Freeman Fang
> Fix For: 4.0.3
>
> Attachments: KARAF-3812.patch
>
>
> The org.apache.karaf.features.cfg file generated by the Maven plugin included 
> this line:
> featuresRepositories = 
> file:${karaf.home}/etc/f9a8234a-cebf-45b5-9316-2345d36febcd.xml
> When executed in a Windows environment, this creates an invalid URI because 
> karaf.home contains back slashes instead of forward slashes.  This results in 
> the exception below being thrown.
> 2015-06-29 13:21:31,459 | ERROR | pool-1-thread-1  | BootFeaturesInstaller
> | 6 - org.apache.karaf.features.core - 4.0.0 | Error installing boot 
> feature repository 
> file:C:\dev\code\karaf-test\target\assembly/etc/f9a8234a-cebf-45b5-9316-2345d36febcd.xml
> java.lang.IllegalArgumentException: Illegal character in opaque part at index 
> 7: 
> file:C:\dev\code\karaf-test\target\assembly/etc/f9a8234a-cebf-45b5-9316-2345d36febcd.xml
>   at java.net.URI.create(URI.java:852)[:1.8.0_40]
>   at 
> org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures(BootFeaturesInstaller.java:86)[6:org.apache.karaf.features.core:4.0.0]
>   at 
> org.apache.karaf.features.internal.service.BootFeaturesInstaller.start(BootFeaturesInstaller.java:76)[6:org.apache.karaf.features.core:4.0.0]
>   at 
> org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:257)[6:org.apache.karaf.features.core:4.0.0]
>   at 
> org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:233)[6:org.apache.karaf.features.core:4.0.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_40]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_40]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_40]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_40]
>   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
> Caused by: java.net.URISyntaxException: Illegal character in opaque part at 
> index 7: 
> file:C:\dev\code\karaf-test\target\assembly/etc/f9a8234a-cebf-45b5-9316-2345d36febcd.xml
>   at java.net.URI$Parser.fail(URI.java:2848)[:1.8.0_40]
>   at java.net.URI$Parser.checkChars(URI.java:3021)[:1.8.0_40]
>   at java.net.URI$Parser.parse(URI.java:3058)[:1.8.0_40]
>   at java.net.URI.(URI.java:588)[:1.8.0_40]
>   at java.net.URI.create(URI.java:850)[:1.8.0_40]
>   ... 9 more



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

[jira] [Commented] (KARAF-3918) An installed blueprint.xml has always been updated and restarted when install another unrelated feature

2015-12-01 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/KARAF-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033303#comment-15033303
 ] 

Jean-Baptiste Onofré commented on KARAF-3918:
-

It's the same for blueprint and spring deployers: it's related to the 
DynamicImport-Package: * header. Unfortunately, as the classes are not known 
before, we have to use this header, I don't see another way to deal with it at 
deployer level.

> An installed blueprint.xml has always been updated and restarted when install 
> another unrelated feature
> ---
>
> Key: KARAF-3918
> URL: https://issues.apache.org/jira/browse/KARAF-3918
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0
> Environment: Java 7
>Reporter: Xilai Dai
>Assignee: Jean-Baptiste Onofré
>
> There is an installed blueprint.xml. (by install -s 
> blueprint:mvn:org.abc/my-project/1.0-SNAPSHOT/xml, or deploy this 
> blueprint.xml into deploy folder).
> then, if you do feature:install , to install some other feature (no 
> dependencies to the blueprint.xml above), the installed blueprint.xml will 
> always be updated and restarted, that's not expected behavious.
> After checking with org.apache.karaf.features.internal.service.Deployer 
> class, I found that the old checksum will only be calculated in case of url 
> start with "jar:" (Line 1159), so in case of the url start with "blueprint:", 
> the new checksum will never equal with old checksum, then it will be put into 
> deployment.toUpdate Map.
> The Deployer class should be fixed for "blueprint:" deployment.



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

[jira] [Commented] (KARAF-3918) An installed blueprint.xml has always been updated and restarted when install another unrelated feature

2015-12-01 Thread Christian Schneider (JIRA) 

[ 
https://issues.apache.org/jira/browse/KARAF-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033307#comment-15033307
 ] 

Christian Schneider commented on KARAF-3918:


We might be able to run bnd over it.. It discovers some of the classes .. on 
the other hand if any remain missing it will still fail.
So honestly I would rather recommend to not use the deployer if possible.

> An installed blueprint.xml has always been updated and restarted when install 
> another unrelated feature
> ---
>
> Key: KARAF-3918
> URL: https://issues.apache.org/jira/browse/KARAF-3918
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0
> Environment: Java 7
>Reporter: Xilai Dai
>Assignee: Jean-Baptiste Onofré
>
> There is an installed blueprint.xml. (by install -s 
> blueprint:mvn:org.abc/my-project/1.0-SNAPSHOT/xml, or deploy this 
> blueprint.xml into deploy folder).
> then, if you do feature:install , to install some other feature (no 
> dependencies to the blueprint.xml above), the installed blueprint.xml will 
> always be updated and restarted, that's not expected behavious.
> After checking with org.apache.karaf.features.internal.service.Deployer 
> class, I found that the old checksum will only be calculated in case of url 
> start with "jar:" (Line 1159), so in case of the url start with "blueprint:", 
> the new checksum will never equal with old checksum, then it will be put into 
> deployment.toUpdate Map.
> The Deployer class should be fixed for "blueprint:" deployment.



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

[jira] [Comment Edited] (KARAF-3918) An installed blueprint.xml has always been updated and restarted when install another unrelated feature

2015-12-01 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/KARAF-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033303#comment-15033303
 ] 

Jean-Baptiste Onofré edited comment on KARAF-3918 at 12/1/15 8:11 AM:
--

It's the same for blueprint and spring deployers: it's related to the 
DynamicImport-Package: * header created in the BlueprintTransformer and 
SpringTransformer. Unfortunately, as the classes are not known before, we have 
to use this header, I don't see another way to deal with it at deployer level.


was (Author: jbonofre):
It's the same for blueprint and spring deployers: it's related to the 
DynamicImport-Package: * header. Unfortunately, as the classes are not known 
before, we have to use this header, I don't see another way to deal with it at 
deployer level.

> An installed blueprint.xml has always been updated and restarted when install 
> another unrelated feature
> ---
>
> Key: KARAF-3918
> URL: https://issues.apache.org/jira/browse/KARAF-3918
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0
> Environment: Java 7
>Reporter: Xilai Dai
>Assignee: Jean-Baptiste Onofré
>
> There is an installed blueprint.xml. (by install -s 
> blueprint:mvn:org.abc/my-project/1.0-SNAPSHOT/xml, or deploy this 
> blueprint.xml into deploy folder).
> then, if you do feature:install , to install some other feature (no 
> dependencies to the blueprint.xml above), the installed blueprint.xml will 
> always be updated and restarted, that's not expected behavious.
> After checking with org.apache.karaf.features.internal.service.Deployer 
> class, I found that the old checksum will only be calculated in case of url 
> start with "jar:" (Line 1159), so in case of the url start with "blueprint:", 
> the new checksum will never equal with old checksum, then it will be put into 
> deployment.toUpdate Map.
> The Deployer class should be fixed for "blueprint:" deployment.



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

[jira] [Commented] (KARAF-3918) An installed blueprint.xml has always been updated and restarted when install another unrelated feature

2015-12-01 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/KARAF-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033308#comment-15033308
 ] 

Jean-Baptiste Onofré commented on KARAF-3918:
-

Agree, we can simply wrap the blueprint in a "dummy" bundle: it will work.

> An installed blueprint.xml has always been updated and restarted when install 
> another unrelated feature
> ---
>
> Key: KARAF-3918
> URL: https://issues.apache.org/jira/browse/KARAF-3918
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0
> Environment: Java 7
>Reporter: Xilai Dai
>Assignee: Jean-Baptiste Onofré
>
> There is an installed blueprint.xml. (by install -s 
> blueprint:mvn:org.abc/my-project/1.0-SNAPSHOT/xml, or deploy this 
> blueprint.xml into deploy folder).
> then, if you do feature:install , to install some other feature (no 
> dependencies to the blueprint.xml above), the installed blueprint.xml will 
> always be updated and restarted, that's not expected behavious.
> After checking with org.apache.karaf.features.internal.service.Deployer 
> class, I found that the old checksum will only be calculated in case of url 
> start with "jar:" (Line 1159), so in case of the url start with "blueprint:", 
> the new checksum will never equal with old checksum, then it will be put into 
> deployment.toUpdate Map.
> The Deployer class should be fixed for "blueprint:" deployment.



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

[jira] [Updated] (KARAF-4156) [karaf-3.0.x] set 'karaf.clean.all' as true will cause data folder cleaned while checking status

2015-12-01 Thread Jerry Meng (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KARAF-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jerry Meng updated KARAF-4156:
--
Description: 
Scenario
===

In etc/system.properties, it describes

# Deletes the entire karaf.data directory at every start
karaf.clean.all = false

When I set the property as true, I expect it will clean data folder ONLY at 
karaf start; however it also causes the command 'stop' and 'status' to delete 
data folder so that the command complains "shutdown port file doesn't exist. 
The container is not running."

Root Cause
=

The class 'org.apache.karaf.main.ConfigProperties' checks the property 
'karaf.clean.all' in the constructor and deletes the data folder if it's set as 
true.

In  'org.apache.karaf.main.Stop' and 'org.apache.karaf.main.Status', they will 
instantiate ConfigProperties at the very beginning. They will never get port 
file correctly in this case and even cause working directory being deleted.

It seams that to delete data folder in the constructor of ConfigProperties does 
not make sense to me.


  was:
Scenario
===

In etc/system.properties, it describes
"
# Deletes the entire karaf.data directory at every start
karaf.clean.all = false
"

When I set the property as true, I expect it will clean data folder ONLY at 
karaf start; however it also causes the command 'stop' and 'status' to delete 
data folder so that the command complains "shutdown port file doesn't exist. 
The container is not running."

Root Cause
=

The class 'org.apache.karaf.main.ConfigProperties' checks the property 
'karaf.clean.all' in the constructor and deletes the data folder if it's set as 
true.

In  'org.apache.karaf.main.Stop' and 'org.apache.karaf.main.Status', they will 
instantiate ConfigProperties at the very beginning. They will never get port 
file correctly in this case and even cause working directory being deleted.

It seams that to delete data folder in the constructor of ConfigProperties does 
not make sense to me.



> [karaf-3.0.x] set 'karaf.clean.all' as true will cause data folder cleaned 
> while checking status
> 
>
> Key: KARAF-4156
> URL: https://issues.apache.org/jira/browse/KARAF-4156
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 3.0.5
> Environment: Running on Mac OS X 10.11
>Reporter: Jerry Meng
>Priority: Critical
> Fix For: 3.0.6
>
>
> Scenario
> ===
> In etc/system.properties, it describes
> # Deletes the entire karaf.data directory at every start
> karaf.clean.all = false
> When I set the property as true, I expect it will clean data folder ONLY at 
> karaf start; however it also causes the command 'stop' and 'status' to delete 
> data folder so that the command complains "shutdown port file doesn't exist. 
> The container is not running."
> Root Cause
> =
> The class 'org.apache.karaf.main.ConfigProperties' checks the property 
> 'karaf.clean.all' in the constructor and deletes the data folder if it's set 
> as true.
> In  'org.apache.karaf.main.Stop' and 'org.apache.karaf.main.Status', they 
> will instantiate ConfigProperties at the very beginning. They will never get 
> port file correctly in this case and even cause working directory being 
> deleted.
> It seams that to delete data folder in the constructor of ConfigProperties 
> does not make sense to me.



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

[jira] [Updated] (KARAF-4156) [karaf-3.0.x] set 'karaf.clean.all' as true will cause data folder cleaned while checking status

2015-12-01 Thread Jerry Meng (JIRA) 

 [ 
https://issues.apache.org/jira/browse/KARAF-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jerry Meng updated KARAF-4156:
--
Description: 
Scenario
===

In etc/system.properties, it describes

\# Deletes the entire karaf.data directory at every start
karaf.clean.all = false

When I set the property as true, I expect it will clean data folder ONLY at 
karaf start; however it also causes the command 'stop' and 'status' to delete 
data folder so that the command complains "shutdown port file doesn't exist. 
The container is not running."

Root Cause
=

The class 'org.apache.karaf.main.ConfigProperties' checks the property 
'karaf.clean.all' in the constructor and deletes the data folder if it's set as 
true.

In  'org.apache.karaf.main.Stop' and 'org.apache.karaf.main.Status', they will 
instantiate ConfigProperties at the very beginning. They will never get port 
file correctly in this case and even cause working directory being deleted.

It seams that to delete data folder in the constructor of ConfigProperties does 
not make sense to me.


  was:
Scenario
===

In etc/system.properties, it describes

# Deletes the entire karaf.data directory at every start
karaf.clean.all = false

When I set the property as true, I expect it will clean data folder ONLY at 
karaf start; however it also causes the command 'stop' and 'status' to delete 
data folder so that the command complains "shutdown port file doesn't exist. 
The container is not running."

Root Cause
=

The class 'org.apache.karaf.main.ConfigProperties' checks the property 
'karaf.clean.all' in the constructor and deletes the data folder if it's set as 
true.

In  'org.apache.karaf.main.Stop' and 'org.apache.karaf.main.Status', they will 
instantiate ConfigProperties at the very beginning. They will never get port 
file correctly in this case and even cause working directory being deleted.

It seams that to delete data folder in the constructor of ConfigProperties does 
not make sense to me.



> [karaf-3.0.x] set 'karaf.clean.all' as true will cause data folder cleaned 
> while checking status
> 
>
> Key: KARAF-4156
> URL: https://issues.apache.org/jira/browse/KARAF-4156
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 3.0.5
> Environment: Running on Mac OS X 10.11
>Reporter: Jerry Meng
>Priority: Critical
> Fix For: 3.0.6
>
>
> Scenario
> ===
> In etc/system.properties, it describes
> \# Deletes the entire karaf.data directory at every start
> karaf.clean.all = false
> When I set the property as true, I expect it will clean data folder ONLY at 
> karaf start; however it also causes the command 'stop' and 'status' to delete 
> data folder so that the command complains "shutdown port file doesn't exist. 
> The container is not running."
> Root Cause
> =
> The class 'org.apache.karaf.main.ConfigProperties' checks the property 
> 'karaf.clean.all' in the constructor and deletes the data folder if it's set 
> as true.
> In  'org.apache.karaf.main.Stop' and 'org.apache.karaf.main.Status', they 
> will instantiate ConfigProperties at the very beginning. They will never get 
> port file correctly in this case and even cause working directory being 
> deleted.
> It seams that to delete data folder in the constructor of ConfigProperties 
> does not make sense to me.



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

[jira] [Created] (KARAF-4156) [karaf-3.0.x] set 'karaf.clean.all' as true will cause data folder cleaned while checking status

2015-12-01 Thread Jerry Meng (JIRA) 
Jerry Meng created KARAF-4156:
-

 Summary: [karaf-3.0.x] set 'karaf.clean.all' as true will cause 
data folder cleaned while checking status
 Key: KARAF-4156
 URL: https://issues.apache.org/jira/browse/KARAF-4156
 Project: Karaf
  Issue Type: Bug
Affects Versions: 3.0.5
 Environment: Running on Mac OS X 10.11
Reporter: Jerry Meng
Priority: Critical
 Fix For: 3.0.6


Scenario
===

In etc/system.properties, it describes
"
# Deletes the entire karaf.data directory at every start
karaf.clean.all = false
"

When I set the property as true, I expect it will clean data folder ONLY at 
karaf start; however it also causes the command 'stop' and 'status' to delete 
data folder so that the command complains "shutdown port file doesn't exist. 
The container is not running."

Root Cause
=

The class 'org.apache.karaf.main.ConfigProperties' checks the property 
'karaf.clean.all' in the constructor and deletes the data folder if it's set as 
true.

In  'org.apache.karaf.main.Stop' and 'org.apache.karaf.main.Status', they will 
instantiate ConfigProperties at the very beginning. They will never get port 
file correctly in this case and even cause working directory being deleted.

It seams that to delete data folder in the constructor of ConfigProperties does 
not make sense to me.




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

[jira] [Created] (KARAF-4157) Provide system script to start Karaf without service wrapper

2015-12-01 Thread Luca Burgazzoli (JIRA) 
Luca Burgazzoli created KARAF-4157:
--

 Summary: Provide system script to start Karaf without service 
wrapper
 Key: KARAF-4157
 URL: https://issues.apache.org/jira/browse/KARAF-4157
 Project: Karaf
  Issue Type: New Feature
Reporter: Luca Burgazzoli
Priority: Minor


For some user/scenario it may be needed to start karaf as a service without the 
service wrapper i.e. on architectures not supported by JSW



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