[jira] [Commented] (KARAF-6454) FeaturesServiceImpl downloadThreads does not improve throughput

[Fabian Lange (Jira)]

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

Fabian Lange commented on KARAF-6454:
-

Yes that seems to be the case, it waits for a feature to install before moving 
to the next one.

{{* Thread group "main":

  Thread "features-3-thread-1":
at java.lang.Object.wait(long)
at java.lang.Object.wait() (line: 502)
at 
org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.await()
 (line: 101)
at 
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(org.apache.karaf.features.internal.download.DownloadManager,
 java.lang.String, 
org.apache.karaf.features.FeaturesService$ServiceRequirementsBehavior, 
org.apache.karaf.features.internal.region.RepositoryManager, 
org.apache.karaf.features.internal.region.SubsystemResolverCallback) (line: 537)
at 
org.apache.karaf.features.internal.region.Subsystem.downloadBundles(org.apache.karaf.features.internal.download.DownloadManager,
 java.lang.String, 
org.apache.karaf.features.FeaturesService$ServiceRequirementsBehavior, 
org.apache.karaf.features.internal.region.RepositoryManager, 
org.apache.karaf.features.internal.region.SubsystemResolverCallback) (line: 452)
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(java.lang.String,
 org.apache.karaf.features.FeaturesService$ServiceRequirementsBehavior, 
org.osgi.service.repository.Repository, java.lang.String) (line: 224)
at 
org.apache.karaf.features.internal.service.Deployer.deploy(org.apache.karaf.features.internal.service.Deployer$DeploymentState,
 org.apache.karaf.features.internal.service.Deployer$DeploymentRequest) (line: 
393)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(java.util.Map,
 java.util.Map, org.apache.karaf.features.internal.service.State, 
java.util.Map, java.util.EnumSet, java.lang.String) (line: 1062)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(java.util.Map,
 java.util.Map, org.apache.karaf.features.internal.service.State, 
java.util.Map, java.util.EnumSet, java.lang.String) (line: 998)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$$Lambda$78.672983579.call()
at java.util.concurrent.FutureTask.run() (line: 266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 (line: 1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 624)
at java.lang.Thread.run() (line: 748)}}

Not sure if this is intentional, as the graph resolution was done before so 
this should be possible to parallelise 


> FeaturesServiceImpl downloadThreads does not improve throughput
> ---
>
> Key: KARAF-6454
> URL: https://issues.apache.org/jira/browse/KARAF-6454
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
>Priority: Major
> Attachments: Screenshot 2019-10-15 at 16.53.00.png
>
>
> I am looking into a slow Karaf startup and I stumbled onto this problem
> FeaturesServiceImpl does allow for parallelism thanks to the downloadThreads 
> configuration
> It does respect this value and createDownloadManager() will use it to size 
> the threadpool.
> However adding a large amount of features at the same time results in one by 
> one downloads across these threads.
> I am currently looking for any pointers where the features install could be 
> sequenced.
> Attached is a JProfiler screenshot illustrating this problem.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (KARAF-6454) FeaturesServiceImpl downloadThreads does not improve throughput

[Fabian Lange (Jira)]

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

Fabian Lange commented on KARAF-6454:
-

Looks to me like Subsystem#deploy() is invoked for each feature, and it does do 
a downloader.await()
Since this is a single deployment request, this is running on the threadpool, 
but it is not forking out the work for the subsystems.

> FeaturesServiceImpl downloadThreads does not improve throughput
> ---
>
> Key: KARAF-6454
> URL: https://issues.apache.org/jira/browse/KARAF-6454
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
>Priority: Major
> Attachments: Screenshot 2019-10-15 at 16.53.00.png
>
>
> I am looking into a slow Karaf startup and I stumbled onto this problem
> FeaturesServiceImpl does allow for parallelism thanks to the downloadThreads 
> configuration
> It does respect this value and createDownloadManager() will use it to size 
> the threadpool.
> However adding a large amount of features at the same time results in one by 
> one downloads across these threads.
> I am currently looking for any pointers where the features install could be 
> sequenced.
> Attached is a JProfiler screenshot illustrating this problem.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (KARAF-6454) FeaturesServiceImpl downloadThreads does not improve throughput

[Fabian Lange (Jira)]

Fabian Lange created KARAF-6454:
---

 Summary: FeaturesServiceImpl downloadThreads does not improve 
throughput
 Key: KARAF-6454
 URL: https://issues.apache.org/jira/browse/KARAF-6454
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange
 Attachments: Screenshot 2019-10-15 at 16.53.00.png

I am looking into a slow Karaf startup and I stumbled onto this problem

FeaturesServiceImpl does allow for parallelism thanks to the downloadThreads 
configuration
It does respect this value and createDownloadManager() will use it to size the 
threadpool.

However adding a large amount of features at the same time results in one by 
one downloads across these threads.
I am currently looking for any pointers where the features install could be 
sequenced.
Attached is a JProfiler screenshot illustrating this problem.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (KARAF-6453) Registering a FeaturesListener re-loads all repositories

[Fabian Lange (Jira)]

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

Fabian Lange commented on KARAF-6453:
-

Well I have not yet figured out if it is intentional ;) It doesn't look like 
however.

> Registering a FeaturesListener re-loads all repositories
> 
>
> Key: KARAF-6453
> URL: https://issues.apache.org/jira/browse/KARAF-6453
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 4.2.0
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>  Labels: features
> Fix For: 4.3.0, 4.2.8
>
>
> This is a regression from 4.2, just discovered.
> It was caused in 2017 by this commit:
> https://github.com/apache/karaf/commit/a75fabaf071b8274c7f266affa7ce7cdd87a2a22
> https://github.com/apache/karaf/commit/a75fabaf071b8274c7f266affa7ce7cdd87a2a22#diff-29d341aa18575466b113be9168a6e7adR264
> Here  the new RepositoryCacheImpl is used to create the repository. But 
> despite its name, it does not use something from the cache, but it creates a 
> new Repository.
> This now will always "load" the repository, potentially refreshing it over 
> http.
> https://github.com/apache/karaf/commit/a75fabaf071b8274c7f266affa7ce7cdd87a2a22#diff-a3bb3d36b86e3a4c291627077972097aR47
> previously it only returned a Repository that was unloaded.
> Registering many FeaturesListeners wastes a lot of CPU.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (KARAF-6453) Registering a FeaturesListener re-loads all repositories

[Fabian Lange (Jira)]

Fabian Lange created KARAF-6453:
---

 Summary: Registering a FeaturesListener re-loads all repositories
 Key: KARAF-6453
 URL: https://issues.apache.org/jira/browse/KARAF-6453
 Project: Karaf
  Issue Type: Bug
  Components: karaf
Affects Versions: 4.2.0
Reporter: Fabian Lange


This is a regression from 4.2, just discovered.
It was caused in 2017 by this commit:
https://github.com/apache/karaf/commit/a75fabaf071b8274c7f266affa7ce7cdd87a2a22

https://github.com/apache/karaf/commit/a75fabaf071b8274c7f266affa7ce7cdd87a2a22#diff-29d341aa18575466b113be9168a6e7adR264
Here  the new RepositoryCacheImpl is used to create the repository. But despite 
its name, it does not use something from the cache, but it creates a new 
Repository.

This now will always "load" the repository, potentially refreshing it over http.
https://github.com/apache/karaf/commit/a75fabaf071b8274c7f266affa7ce7cdd87a2a22#diff-a3bb3d36b86e3a4c291627077972097aR47

previously it only returned a Repository that was unloaded.


Registering many FeaturesListeners wastes a lot of CPU.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (KARAF-6276) Bundle update results in leaking update*.jar files

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-6276:
-

BTW:  the bundle in question is the AWS SDK osgi bundle.
https://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk-osgi

> Bundle update results in leaking update*.jar files
> --
>
> Key: KARAF-6276
> URL: https://issues.apache.org/jira/browse/KARAF-6276
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 4.2.3
>Reporter: Henning Treu
>Priority: Major
>
> We encounter leaking update*.jar files which ultimately result in a full 
> disk. Listing files shows something like this:
> {quote}-rw-r--r-- 1 root root 458M Apr 28 04:44 update-7283235896174400181.jar
> -rw-r--r-- 1 root root 458M May  5 04:25 update-7296484626001425386.jar
> -rw-r--r-- 1 root root 458M Apr 24 04:20 update-7339530845064123545.jar
> -rw-r--r-- 1 root root 458M Apr 30 04:45 update-7807707341953713899.jar
> -rw-r--r-- 1 root root 458M May  2 04:25 update-8043037041286514887.jar
> -rw-r--r-- 1 root root 458M May  3 04:16 update-8313433533207318564.jar
> -rw-r--r-- 1 root root 458M Apr 27 04:16 update-839710980329827978.jar
> -rw-r--r-- 1 root root 458M Apr 25 04:31 update-8877699798146551228.jar
> {quote}
>  
> As you can tell from the timestamps our update process kicks in somewhere 
> around 4 in the morning. We call 
> {{URI featureRepo;}}
> {{featuresService.refreshRepository(featureRepo);}}
> {{...}}
> {{EnumSet NO_OPTIONS = EnumSet.noneOf(Option.class);}}
> {{Map> NO_CHANGES = 
> Collections.singletonMap(FeaturesService.ROOT_REGION, 
> Collections.emptySet());}}
> {{featuresService.addRequirements(NO_CHANGES, NO_OPTIONS);}}
>  
> Both calls to featuresService are guarded by the same ReentrantLock which is 
> released after each call. Unfortunately we are not able to reproduce this 
> issue. It seems to happen once in a while. What bothers me is the size of the 
> update.jar with 458MB. From the code I understand it should be a single 
> bundle.
>  
> The stacktrace when the disk is finally full:
> {quote}org.osgi.framework.BundleException: Unable to update bundle
>  at 
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.updateBundle(BundleInstallSupportImpl.java:149)
>  ~[?:?]
>  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.updateBundle(FeaturesServiceImpl.java:1139)
>  ~[?:?]
>  at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:834) 
> ~[?:?]
>  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1058)
>  ~[?:?]
>  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:994)
>  ~[?:?]
>  at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  [?:?]
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [?:?]
>  at java.lang.Thread.run(Thread.java:748) [?:?]
> Caused by: java.io.IOException: No space left on device
>  at java.io.FileOutputStream.write(Native Method) ~[?:?]
>  at java.io.FileOutputStream.write(FileOutputStream.java:290) ~[?:?]
>  at java.util.zip.ZipOutputStream.writeInt(ZipOutputStream.java:720) ~[?:?]
>  at java.util.zip.ZipOutputStream.writeLOC(ZipOutputStream.java:391) ~[?:?]
>  at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:238) 
> ~[?:?]
>  at 
> org.apache.karaf.util.bundles.BundleUtils.fixBundleWithUpdateLocation(BundleUtils.java:67)
>  ~[?:?]
>  at 
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.updateBundle(BundleInstallSupportImpl.java:145)
>  ~[?:?]
>  ... 8 more
> {quote}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (KARAF-5573) Karaf on Windows does not pass the version check when JAVA_HOME contains whitespace

[Fabian Lange (JIRA)]

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

Fabian Lange resolved KARAF-5573.
-
   Resolution: Fixed
 Assignee: Fabian Lange
Fix Version/s: 4.1.5
   4.2.0

> Karaf on Windows does not pass the version check when JAVA_HOME contains 
> whitespace
> ---
>
> Key: KARAF-5573
> URL: https://issues.apache.org/jira/browse/KARAF-5573
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
>Assignee: Fabian Lange
>Priority: Major
> Fix For: 4.2.0, 4.1.5
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (KARAF-5573) Karaf on Windows does not pass the version check when JAVA_HOME contains whitespace

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-5573:
---

 Summary: Karaf on Windows does not pass the version check when 
JAVA_HOME contains whitespace
 Key: KARAF-5573
 URL: https://issues.apache.org/jira/browse/KARAF-5573
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (KARAF-5481) NullPointer when invoking Karaf.stop()

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-5481:
---

 Summary: NullPointer when invoking Karaf.stop()
 Key: KARAF-5481
 URL: https://issues.apache.org/jira/browse/KARAF-5481
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


customer sees this when they run a package upgrade of our karaf distribution

```Nov 12 04:15:54 karaf[21250]: Exception in thread "main" 
java.lang.NullPointerException
Nov 12 04:15:54 karaf[21250]: at 
org.apache.karaf.main.Stop.main(Stop.java:60)```

https://github.com/apache/karaf/blob/master/main/src/main/java/org/apache/karaf/main/Stop.java#L60

We have the feeling this is kind of a race condition between sending the stop 
command and deleting the file which contains the stop command.

whats your thoughts? shouldn'T we at least ensure that `config.shutdownCommand` 
is non null?





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KARAF-5423) Karaf is flagged as vulnerable to CVE-2015-5262

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-5423:
---

 Summary: Karaf is flagged as vulnerable to CVE-2015-5262
 Key: KARAF-5423
 URL: https://issues.apache.org/jira/browse/KARAF-5423
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.1.2
Reporter: Fabian Lange


Pax Url up to the current 2.5.2 include apache httpclient 4.3.5 which is 
flagged vulnerable to CVE-2015-5262.

I already provided a patch upstream 
https://ops4j1.jira.com/projects/PAXURL/issues/PAXURL-345?filter=allopenissues
in 
https://github.com/ops4j/org.ops4j.pax.url/commit/6f938ab159c606c45ec293c116aad41b6cf62510

but it would require a pax-url release first followed by a dependency upgrade 
in karaf.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KARAF-5273) karaf-maven-plugin assembly should take feature wildcards

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-5273:
---

 Summary: karaf-maven-plugin assembly should take feature wildcards
 Key: KARAF-5273
 URL: https://issues.apache.org/jira/browse/KARAF-5273
 Project: Karaf
  Issue Type: Improvement
Reporter: Fabian Lange


As per discussion in:
http://karaf.922171.n3.nabble.com/Building-custom-dist-including-all-features-of-a-repository-td4051100.html

it would be great if the assembly part of the karaf-maven-plugin would respect 
wildcards for startup/boot/installed feature names. currently it only performs 
an equals check, requiring dist builders to explicitly list all the features 
they want.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (KARAF-5233) LogService does not work with log4j2

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-5233:
---

 Summary: LogService does not work with log4j2
 Key: KARAF-5233
 URL: https://issues.apache.org/jira/browse/KARAF-5233
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.1.1
Reporter: Fabian Lange


log:get / log:set and similar do not work with log4j2.
the reason is that the LogServiceImpl has hardcoded prefixes and assumes a 
certain property name convention. 
of course this totally changed with log4j2, making LogServiceImpl quite broken



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange resolved KARAF-4748.
-
Resolution: Fixed

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Fix For: 4.2.0, 4.1.2
>
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-4748:

Fix Version/s: 4.1.2
   4.2.0

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Fix For: 4.2.0, 4.1.2
>
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange reassigned KARAF-4748:
---

Assignee: Fabian Lange

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
>Assignee: Fabian Lange
> Fix For: 4.2.0, 4.1.2
>
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-4748:

Issue Type: Improvement  (was: Bug)

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Improvement
>Reporter: Fabian Lange
>Assignee: Fabian Lange
> Fix For: 4.2.0, 4.1.2
>
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

[~gnt] what do you think? The Felix change has been merged, but the problem 
remains for me. I really would like to control this somehow. Could we allow

Resolver resolver = new ResolverImpl(new 
Slf4jResolverLog(LoggerFactory.getLogger(ResolverImpl.class)));

to take the additional new parallelism argument?

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (KARAF-5067) Add option not to register StandardManageableRegionDigraph

[Fabian Lange (JIRA)]

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

Fabian Lange resolved KARAF-5067.
-
Resolution: Fixed

> Add option not to register StandardManageableRegionDigraph
> --
>
> Key: KARAF-5067
> URL: https://issues.apache.org/jira/browse/KARAF-5067
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Reporter: Fabian Lange
>Priority: Minor
> Fix For: 4.1.1
>
>
> To create a very low footprint karaf container, we disabled all jmx/mbean 
> functionality, but the features activator still registers the 
> StandardManageableRegionDigraph.
> Having an option not to register that mbean would also help us avoid the 
> startup of the mbeanserver at all, preventing some amount of memory usage and 
> classloading.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (KARAF-5067) Add option not to register StandardManageableRegionDigraph

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-5067:

Fix Version/s: 4.1.1

> Add option not to register StandardManageableRegionDigraph
> --
>
> Key: KARAF-5067
> URL: https://issues.apache.org/jira/browse/KARAF-5067
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Reporter: Fabian Lange
>Priority: Minor
> Fix For: 4.1.1
>
>
> To create a very low footprint karaf container, we disabled all jmx/mbean 
> functionality, but the features activator still registers the 
> StandardManageableRegionDigraph.
> Having an option not to register that mbean would also help us avoid the 
> startup of the mbeanserver at all, preventing some amount of memory usage and 
> classloading.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (KARAF-5067) Add option not to register StandardManageableRegionDigraph

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-5067:
---

 Summary: Add option not to register StandardManageableRegionDigraph
 Key: KARAF-5067
 URL: https://issues.apache.org/jira/browse/KARAF-5067
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Reporter: Fabian Lange
Priority: Minor


To create a very low footprint karaf container, we disabled all jmx/mbean 
functionality, but the features activator still registers the 
StandardManageableRegionDigraph.

Having an option not to register that mbean would also help us avoid the 
startup of the mbeanserver at all, preventing some amount of memory usage and 
classloading.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (KARAF-5002) Upgrade to Felix Configadmin 1.8.14

[Fabian Lange (JIRA)]

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

Fabian Lange resolved KARAF-5002.
-
Resolution: Fixed

> Upgrade to Felix Configadmin 1.8.14
> ---
>
> Key: KARAF-5002
> URL: https://issues.apache.org/jira/browse/KARAF-5002
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Fix For: 4.0.9, 4.1.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (KARAF-5002) Upgrade to Felix Configadmin 1.8.14

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-5002:

Fix Version/s: 4.1.1
   4.0.9

> Upgrade to Felix Configadmin 1.8.14
> ---
>
> Key: KARAF-5002
> URL: https://issues.apache.org/jira/browse/KARAF-5002
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Fix For: 4.0.9, 4.1.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (KARAF-5002) Upgrade to Felix Configadmin 1.8.14

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-5002:
---

 Summary: Upgrade to Felix Configadmin 1.8.14
 Key: KARAF-5002
 URL: https://issues.apache.org/jira/browse/KARAF-5002
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (KARAF-4210) Unreleased Resource: Streams

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4210:
-

good find, made me find KARAF-4979 as well.

> Unreleased Resource: Streams
> 
>
> Key: KARAF-4210
> URL: https://issues.apache.org/jira/browse/KARAF-4210
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Eduardo Aguinaga
>Assignee: Christian Schneider
> Fix For: 4.1.1
>
>
> HP Fortify SCA and SciTools Understand were used to perform an application 
> security analysis on the karaf source code.
> The function getLocalRepoFromConfig() in MavenConfigService.java sometimes 
> fails to release a system resource allocated by FileInputStream() on line 74.
> File: 
> bundle/core/src/main/java/org/apache/karaf/bundle/core/internal/MavenConfigService.java
> Line: 74
> MavenConfigService.java, lines 66-76:
> 66 static String getLocalRepoFromConfig(Dictionary dict) 
> throws XMLStreamException, FileNotFoundException {
> 67 String path = null;
> 68 if (dict != null) {
> 69 path = (String) dict.get("org.ops4j.pax.url.mvn.localRepository");
> 70 if (path == null) {
> 71 String settings = (String) 
> dict.get("org.ops4j.pax.url.mvn.settings");
> 72 if (settings != null) {
> 73 File file = new File(settings);
> 74 XMLStreamReader reader = 
> XMLInputFactory.newFactory().createXMLStreamReader(new FileInputStream(file));
> 75 try {
> 76 int event;



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (KARAF-4979) Features StaxParser and UrlLoader leak resources

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4979:
---

 Summary: Features StaxParser and UrlLoader leak resources
 Key: KARAF-4979
 URL: https://issues.apache.org/jira/browse/KARAF-4979
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


UrlLoader makes a GzipInputStream which is not properly closed
StaxParser uses XmlReader/writer without closing them



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (KARAF-4978) Features Subsystem leaks native memory

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4978:
---

 Summary: Features Subsystem leaks native memory
 Key: KARAF-4978
 URL: https://issues.apache.org/jira/browse/KARAF-4978
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange
Priority: Critical


org.apache.karaf.features.internal.region.Subsystem.getMetadata(StreamProvider) 
leaks java native memory because it creates a ZipInputStream it doesnt close, 
which leaves the Inflater open.
This leaks native memory:
http://www.evanjones.ca/java-native-leak-bug.html

the fix is to close the ZipInputStream instead of only the InputStream



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (KARAF-4951) Incorrect Equals/HashCode implementation crashes Deployer

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-4951:

Fix Version/s: 4.0.9
   4.1.0

> Incorrect Equals/HashCode implementation crashes Deployer
> -
>
> Key: KARAF-4951
> URL: https://issues.apache.org/jira/browse/KARAF-4951
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.8
>Reporter: Fabian Lange
>Priority: Critical
> Fix For: 4.1.0, 4.0.9
>
>
> java.lang.IllegalArgumentException: Comparison method violates its general 
> contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)[:1.8.0_101]
> at java.util.TimSort.mergeAt(TimSort.java:514)[:1.8.0_101]
> at java.util.TimSort.mergeCollapse(TimSort.java:441)[:1.8.0_101]
> at java.util.TimSort.sort(TimSort.java:245)[:1.8.0_101]
> at java.util.Arrays.sort(Arrays.java:1512)[:1.8.0_101]
> at java.util.ArrayList.sort(ArrayList.java:1454)[:1.8.0_101]
> at java.util.Collections.sort(Collections.java:175)[:1.8.0_101]
> at 
> org.apache.karaf.features.internal.service.Deployer.getBundlesToStop(Deployer.java:1334)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:798)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1152)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1048)[6:org.apache.karaf.features.core:4.0.5]
> at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]



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

[jira] [Closed] (KARAF-4951) Incorrect Equals/HashCode implementation crashes Deployer

[Fabian Lange (JIRA)]

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

Fabian Lange closed KARAF-4951.
---
Resolution: Fixed

> Incorrect Equals/HashCode implementation crashes Deployer
> -
>
> Key: KARAF-4951
> URL: https://issues.apache.org/jira/browse/KARAF-4951
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.8
>Reporter: Fabian Lange
>Priority: Critical
> Fix For: 4.1.0, 4.0.9
>
>
> java.lang.IllegalArgumentException: Comparison method violates its general 
> contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)[:1.8.0_101]
> at java.util.TimSort.mergeAt(TimSort.java:514)[:1.8.0_101]
> at java.util.TimSort.mergeCollapse(TimSort.java:441)[:1.8.0_101]
> at java.util.TimSort.sort(TimSort.java:245)[:1.8.0_101]
> at java.util.Arrays.sort(Arrays.java:1512)[:1.8.0_101]
> at java.util.ArrayList.sort(ArrayList.java:1454)[:1.8.0_101]
> at java.util.Collections.sort(Collections.java:175)[:1.8.0_101]
> at 
> org.apache.karaf.features.internal.service.Deployer.getBundlesToStop(Deployer.java:1334)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:798)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1152)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1048)[6:org.apache.karaf.features.core:4.0.5]
> at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]



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

[jira] [Commented] (KARAF-4951) Incorrect Equals/HashCode implementation crashes Deployer

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4951:
-

closed via 
https://github.com/apache/karaf/commit/c9efa88037652a91073ed31702a016a9b5b36136 
for master
and for 4.0.x on 
https://github.com/apache/karaf/commit/d7c5d3858d802f48e4ef23ae78089499184dbc8b

> Incorrect Equals/HashCode implementation crashes Deployer
> -
>
> Key: KARAF-4951
> URL: https://issues.apache.org/jira/browse/KARAF-4951
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.8
>Reporter: Fabian Lange
>Priority: Critical
>
> java.lang.IllegalArgumentException: Comparison method violates its general 
> contract!
> at java.util.TimSort.mergeLo(TimSort.java:777)[:1.8.0_101]
> at java.util.TimSort.mergeAt(TimSort.java:514)[:1.8.0_101]
> at java.util.TimSort.mergeCollapse(TimSort.java:441)[:1.8.0_101]
> at java.util.TimSort.sort(TimSort.java:245)[:1.8.0_101]
> at java.util.Arrays.sort(Arrays.java:1512)[:1.8.0_101]
> at java.util.ArrayList.sort(ArrayList.java:1454)[:1.8.0_101]
> at java.util.Collections.sort(Collections.java:175)[:1.8.0_101]
> at 
> org.apache.karaf.features.internal.service.Deployer.getBundlesToStop(Deployer.java:1334)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:798)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1152)[6:org.apache.karaf.features.core:4.0.5]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1048)[6:org.apache.karaf.features.core:4.0.5]
> at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_101]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]



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

[jira] [Created] (KARAF-4951) Incorrect Equals/HashCode implementation crashes Deployer

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4951:
---

 Summary: Incorrect Equals/HashCode implementation crashes Deployer
 Key: KARAF-4951
 URL: https://issues.apache.org/jira/browse/KARAF-4951
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.8
Reporter: Fabian Lange
Priority: Critical


java.lang.IllegalArgumentException: Comparison method violates its general 
contract!
at java.util.TimSort.mergeLo(TimSort.java:777)[:1.8.0_101]
at java.util.TimSort.mergeAt(TimSort.java:514)[:1.8.0_101]
at java.util.TimSort.mergeCollapse(TimSort.java:441)[:1.8.0_101]
at java.util.TimSort.sort(TimSort.java:245)[:1.8.0_101]
at java.util.Arrays.sort(Arrays.java:1512)[:1.8.0_101]
at java.util.ArrayList.sort(ArrayList.java:1454)[:1.8.0_101]
at java.util.Collections.sort(Collections.java:175)[:1.8.0_101]
at 
org.apache.karaf.features.internal.service.Deployer.getBundlesToStop(Deployer.java:1334)[6:org.apache.karaf.features.core:4.0.5]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:798)[6:org.apache.karaf.features.core:4.0.5]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1152)[6:org.apache.karaf.features.core:4.0.5]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1048)[6:org.apache.karaf.features.core:4.0.5]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_101]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_101]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_101]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]



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

[jira] [Commented] (KARAF-4865) Karaf startup no longer works on platforms without "readlink"

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4865:
-

yeah thanks. i just saw https://issues.apache.org/jira/browse/KARAF-4564 was 
reopened. in our case it is z/OS not aix (similar however)

> Karaf startup no longer works on platforms without "readlink"
> -
>
> Key: KARAF-4865
> URL: https://issues.apache.org/jira/browse/KARAF-4865
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
>
> With KARAF-4564 we used "readlink" to resolve some symlink issues. but this 
> broke karaf now for platforms which do not support "readlink". we should make 
> it optional.



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

[jira] [Commented] (KARAF-4865) Karaf startup no longer works on platforms without "readlink"

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4865:
-

it has been enhanced in KARAF-4628 to recursively check links, but without 
readlink karaf no longer starts

> Karaf startup no longer works on platforms without "readlink"
> -
>
> Key: KARAF-4865
> URL: https://issues.apache.org/jira/browse/KARAF-4865
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
>
> With KARAF-4564 we used "readlink" to resolve some symlink issues. but this 
> broke karaf now for platforms which do not support "readlink". we should make 
> it optional.



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

[jira] [Created] (KARAF-4865) Karaf startup no longer works on platforms without "readlink"

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4865:
---

 Summary: Karaf startup no longer works on platforms without 
"readlink"
 Key: KARAF-4865
 URL: https://issues.apache.org/jira/browse/KARAF-4865
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


With KARAF-4564 we used "readlink" to resolve some symlink issues. but this 
broke karaf now for platforms which do not support "readlink". we should make 
it optional.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

Indeed the majority of the calls are happening from felix activator.
But the deadlocking behaviour is even scarier. I guess EnhancedExecutor doesnt 
even work when shared.
I guess ill start with working on Felix first and then picking up here again.

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

the synchronizationin 
org.apache.felix.resolver.ResolverImpl.EnhancedExecutor.EnhancedExecutor(Executor)
 doesnt look right to me. scary :(

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

interestingly this change makes the startup of karaf hang

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

The PR was updated after your last comment
https://github.com/apache/karaf/pull/246

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Updated] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-4748:

Attachment: Screen Shot 2016-10-04 at 11.54.19.png

all thread pools on one timeline.
only the "short ones" are actually created by felix resolver. the long ones are 
other thread pools.
for each -1 thread there are 7 more.

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png, Screen Shot 2016-10-04 at 11.54.19.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

Please review my new suggestion 

It fixes the concerns I have and also the concerns reported in 
https://issues.apache.org/jira/browse/FELIX-5247.
It has very little difference to the current implementation.
Concurrent uses will see some more contention, but according to my 
investigation this is not invoked concurrently already.
Se attached screenshot

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

Hey Guillaume, 
you are right about the felix startlevel thing. but isn't this the thread which 
handles bundle startup? so in the end the bundle installs that are trigged by a 
bundle during its activation will have exactly this signature.

I also do not understand why it is a problem to "reuse" a thread pool 
concurrently. What situation are you concerned about? 

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Updated] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-4748:

Attachment: Screen Shot 2016-10-04 at 09.25.48.png
Screen Shot 2016-10-04 at 09.26.04.png
Screen Shot 2016-10-04 at 09.26.17.png
Screen Shot 2016-10-04 at 09.27.45.png
Screen Shot 2016-10-04 at 09.28.20.png
Screen Shot 2016-10-04 at 09.28.50.png
Screen Shot 2016-10-04 at 09.30.14.png
Screen Shot 2016-10-04 at 09.31.16.png

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png, Screen Shot 
> 2016-10-04 at 09.25.48.png, Screen Shot 2016-10-04 at 09.26.04.png, Screen 
> Shot 2016-10-04 at 09.26.17.png, Screen Shot 2016-10-04 at 09.27.45.png, 
> Screen Shot 2016-10-04 at 09.28.20.png, Screen Shot 2016-10-04 at 
> 09.28.50.png, Screen Shot 2016-10-04 at 09.30.14.png, Screen Shot 2016-10-04 
> at 09.31.16.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

Hi Guillaume,
what would be proof for you that my analysis is correct?

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Commented] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4748:
-

My implementation adds resolverThreads property, which by default behaves the 
same.
if set to -1 it will create an unbounded CachedExecutorPool which is reused.
It can also be set to a positive number to limit the amount of concurrent 
threads.

By using a ThreadPoolExecutor, I mimic the current behaviour which leaves no 
threads behind (after timeout), as the resolve calls a usually very infrequent 
after startup.

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Updated] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-4748:

Attachment: Screen Shot 2016-10-03 at 20.13.47.png

All those threads are created by not supplying an executor to ResolverImpl.

> Make Felix Resolver Threads configurable
> 
>
> Key: KARAF-4748
> URL: https://issues.apache.org/jira/browse/KARAF-4748
> Project: Karaf
>  Issue Type: Bug
>Reporter: Fabian Lange
> Attachments: Screen Shot 2016-10-03 at 20.13.47.png
>
>
> It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
> the resolver threads configurable to avoid creating many threads by karaf.
> It turns out Felix already has that feature, but Karaf is not using it:
> https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119
> Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));
> I propose to configure and supply an Executor with the desired threads. As 
> additional up, this prevents situations where there are unnecessary threads 
> created.



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

[jira] [Created] (KARAF-4748) Make Felix Resolver Threads configurable

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4748:
---

 Summary: Make Felix Resolver Threads configurable
 Key: KARAF-4748
 URL: https://issues.apache.org/jira/browse/KARAF-4748
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


It was requested in https://issues.apache.org/jira/browse/FELIX-5247 to make 
the resolver threads configurable to avoid creating many threads by karaf.
It turns out Felix already has that feature, but Karaf is not using it:

https://github.com/apache/karaf/blob/karaf-4.0.x/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L119

Resolver resolver = new ResolverImpl(new Logger(Logger.LOG_INFO));

I propose to configure and supply an Executor with the desired threads. As 
additional up, this prevents situations where there are unnecessary threads 
created.



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

[jira] [Created] (KARAF-4700) Overrides and blacklist do not work by default and produce an exception

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4700:
---

 Summary: Overrides and blacklist do not work by default and 
produce an exception
 Key: KARAF-4700
 URL: https://issues.apache.org/jira/browse/KARAF-4700
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


The FeaturesServiceImpl supports overrides and blacklist.
They are configured in the Activator:
https://github.com/apache/karaf/blob/791ebb5f908e27fa389616c8bba456cf85807f4d/features/core/src/main/java/org/apache/karaf/features/internal/osgi/Activator.java#L175

If not configured they will default to a file which is not existing in the 
distribution by default:
String overrides = getString("overrides", new 
File(System.getProperty("karaf.etc"), 
"overrides.properties").toURI().toString());
String blacklisted = getString("blacklisted", new 
File(System.getProperty("karaf.etc"), 
"blacklisted.properties").toURI().toString());

This causes Exceptions later down the line, e.g. here: 
https://github.com/apache/karaf/blob/b8c2617c278bb899c0af2ea1a8d2dc987f22f1cb/features/core/src/main/java/org/apache/karaf/features/internal/service/Overrides.java#L116

The code is guarded with a null check, so there has been a possibility not to 
use the blacklist or override feature at all by providing them as "null".
but the way these properties are read, they never can be null, they either 
refer to a file the user configured or to the default file.

It would be great if it would be possible to turn the feature off some how.

the best workaround right now is to add empty files, which will at least 
prevent the file not found exception, but it is still unnecessary file io 
(which admittedly is a minor concern)



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

[jira] [Commented] (KARAF-4633) Allow disabling registration of StandardManageableRegionDigraph

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4633:
-

If thats the case, then thats even better.
I have to admit I have no clue about the whole Digraph thingy. Thats why I did 
not question it :)
As our use case calls for low memory footprint, I would welcome any change in 
that direction.

> Allow disabling registration of StandardManageableRegionDigraph
> ---
>
> Key: KARAF-4633
> URL: https://issues.apache.org/jira/browse/KARAF-4633
> Project: Karaf
>  Issue Type: Improvement
>Reporter: Fabian Lange
>
> As part of my activities to reduce karaf footprint, I was wondering what was 
> triggering the mbean server infrastructure to come up in karaf.
> I saw that org.apache.karaf.features.internal.osgi.Activator.doStart() 
> registers the StandardManageableRegionDigraph.
> As i could not find any internal interaction with that mbean, could we make 
> it configurable to not register? That would avoid initializing a lot of mbean 
> server stuff.



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

[jira] [Created] (KARAF-4633) Allow disabling registration of StandardManageableRegionDigraph

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4633:
---

 Summary: Allow disabling registration of 
StandardManageableRegionDigraph
 Key: KARAF-4633
 URL: https://issues.apache.org/jira/browse/KARAF-4633
 Project: Karaf
  Issue Type: Improvement
Reporter: Fabian Lange


As part of my activities to reduce karaf footprint, I was wondering what was 
triggering the mbean server infrastructure to come up in karaf.
I saw that org.apache.karaf.features.internal.osgi.Activator.doStart() 
registers the StandardManageableRegionDigraph.

As i could not find any internal interaction with that mbean, could we make it 
configurable to not register? That would avoid initializing a lot of mbean 
server stuff.



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

[jira] [Commented] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-3798:
-

Hi JB,

i am proposing to merge my PR https://github.com/apache/karaf/pull/138 to 
address this issue.
I have dug deeper into bad startup performance of karaf on multi core systems.
what happen is what the attached screenshot shows:
Each provision in Thread spawns an Executor pool with core count threads.
Out of those threads only one is ever used.

As a compromise I would accept to still used a cachedExecutorPool, but I 
strongly recommend to construct it only once as I did in my PR

Let me know what we can do to get this into next release, as I have customers 
complaining about startup performance.

> FeaturesServiceImpl not threadsafe
> --
>
> Key: KARAF-3798
> URL: https://issues.apache.org/jira/browse/KARAF-3798
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0.M3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.6
>
>
> This error happens pretty frequently with M3, when there are multiple 
> features installed on startup and config files to activate them created.
> {code}
> 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
> | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
> delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
> id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
> java.lang.NullPointerException
>   at 
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
>   at 
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
>   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
> {code}
> As written in latest comment, the root cause seems to be that multiple 
> installFeature calls to FeatureService mess up the state of the bundles. In 
> my case it left a bundle in a corrupt state, which was noticed when the 
> configuration change did not really activate the service.



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

[jira] [Commented] (KARAF-4583) Upgrade to equinox 3.10.101.v20150820-1432

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4583:
-

I was just curious. I found it strange not to upgrade to the latest, and while 
I find the reasoning unusual, I know that eclipse projects tend to change their 
maven coordinates without notice.
I think if one really wants to use eclipse maven artifactes one should follow 
what they did: https://github.com/diffplug/spotless/blob/master/build.gradle

Download the zip and upload to your own repo.

"You might think this is crappy, and try to find some kind of maven upload. 
You'll find a couple random artifacts, but they're all a trap.  Mismatching 
versions and missing deps."

I leave this up to you, just wanted to point it out. probably the new tycho 
osgi jar is as bad ad the prvious one, but maybe it is the newest found in 
maven central.

> Upgrade to equinox 3.10.101.v20150820-1432
> --
>
> Key: KARAF-4583
> URL: https://issues.apache.org/jira/browse/KARAF-4583
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 4.1.0, 4.0.6
>
>




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

[jira] [Commented] (KARAF-4583) Upgrade to equinox 3.10.101.v20150820-1432

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4583:
-

may I ask why this specific version? This is Mars SR1. Why not Mars SR 2? 
org.eclipse.osgi_3.10.102.v20160118-1700

> Upgrade to equinox 3.10.101.v20150820-1432
> --
>
> Key: KARAF-4583
> URL: https://issues.apache.org/jira/browse/KARAF-4583
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 4.1.0, 4.0.6
>
>




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

[jira] [Commented] (KARAF-4156) Set 'karaf.clean.all' as true will cause data folder cleaned while checking status

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4156:
-

It is merged in 4.0.5 (maybe somebody can give me permissions to do stuff here 
in jira, so i can update it)

> 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, 4.0.3
> Environment: Running on Mac OS X 10.11
>Reporter: Jerry Meng
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 4.1.0, 3.0.7, 4.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] [Commented] (KARAF-4156) Set 'karaf.clean.all' as true will cause data folder cleaned while checking status

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4156:
-

sorry, just now found this issue.
I opened a duplicate KARAF-4475 and already pushed and merged a fix, very 
similar to this one.

> 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, 4.0.3
> Environment: Running on Mac OS X 10.11
>Reporter: Jerry Meng
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 4.1.0, 3.0.7, 4.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-4475) Performing status check will wipe cache if karaf.clean.all/karaf.clean.cache is set

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4475:
---

 Summary: Performing status check will wipe cache if 
karaf.clean.all/karaf.clean.cache is set
 Key: KARAF-4475
 URL: https://issues.apache.org/jira/browse/KARAF-4475
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


Whenever somebody does "new ConfigProperties()" the cache files are deleted:
https://github.com/apache/karaf/blob/master/main/src/main/java/org/apache/karaf/main/ConfigProperties.java#L181

This is problematic, as with a running karaf instance, somebody who will invoke 
the status script, will wipe the cache directory of the running instance, 
resulting in various problems

Both: Status and Stop are guilty of doing that.
https://github.com/apache/karaf/blob/b8c2617c278bb899c0af2ea1a8d2dc987f22f1cb/main/src/main/java/org/apache/karaf/main/Status.java#L38
https://github.com/apache/karaf/blob/b8c2617c278bb899c0af2ea1a8d2dc987f22f1cb/main/src/main/java/org/apache/karaf/main/Stop.java#L42

I propose to move the deletion logic to Main.launch()
https://github.com/apache/karaf/blob/b8c2617c278bb899c0af2ea1a8d2dc987f22f1cb/main/src/main/java/org/apache/karaf/main/Main.java#L230



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

[jira] [Created] (KARAF-4423) jaas: AutoEncryptionSupport can fail to shutdown

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4423:
---

 Summary: jaas: AutoEncryptionSupport can fail to shutdown
 Key: KARAF-4423
 URL: https://issues.apache.org/jira/browse/KARAF-4423
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


AutoEncryptionSupport has the wrong field marked as volatile. there is a flag 
to toggle the runnable off, but that one is not volatile.
additionally, there is no need to start the thread if encryption is not used.



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

[jira] [Commented] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-3798:
-

A new stack trace which seems common in 4.0.4 for the same issue:
{code}
java.lang.NullPointerException
at java.io.FileOutputStream.(FileOutputStream.java:203)[:1.8.0_72]
at java.io.FileOutputStream.(FileOutputStream.java:162)[:1.8.0_72]
at 
org.apache.karaf.features.internal.osgi.Activator$1.getOutputStream(Activator.java:197)[7:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.StateStorage.save(StateStorage.java:56)[7:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:297)[7:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.saveState(FeaturesServiceImpl.java:1154)[7:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:764)[7:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1089)[7:org.apache.karaf.features.core:4.0.4]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:985)[7:org.apache.karaf.features.core:4.0.4]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_72]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_72]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_72]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_72]
{code}
What I noticed is that also "BootFinished" is called prematurely.

>From 
>org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures():
{code}
List stagedFeatures = parseBootFeatures(features);
for (Set features : stagedFeatures) {
featuresService.installFeatures(features, 
EnumSet.of(FeaturesService.Option.NoFailOnFeatureNotFound));
}
featuresService.bootDone();
publishBootFinished();
{code}
because installFeatures is async, bootFinished is invoked as soon as the task 
for the thread has been scheduled, but not when the boot is actually done (and 
all boot features are in state installed

> FeaturesServiceImpl not threadsafe
> --
>
> Key: KARAF-3798
> URL: https://issues.apache.org/jira/browse/KARAF-3798
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0.M3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.5
>
>
> This error happens pretty frequently with M3, when there are multiple 
> features installed on startup and config files to activate them created.
> {code}
> 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
> | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
> delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
> id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
> java.lang.NullPointerException
>   at 
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
>   at 
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
>   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
> {code}
> As written in latest comment, the root cause seems to be that multiple 
> installFeature calls to FeatureService mess up the state of the bundles. In 
> my case it left a bundle in a corrupt state, which was noticed when the 
> configuration change did not really activate the service.



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

[jira] [Commented] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-3798:
-

Also this is probably the cause for the state problem:
{code}
void bootDone() {
synchronized (lock) {
state.bootDone.set(true);
saveState();
}
}
{code}
will save the state while features are still installing

> FeaturesServiceImpl not threadsafe
> --
>
> Key: KARAF-3798
> URL: https://issues.apache.org/jira/browse/KARAF-3798
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.0.M3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.5
>
>
> This error happens pretty frequently with M3, when there are multiple 
> features installed on startup and config files to activate them created.
> {code}
> 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
> | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
> delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
> id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
> java.lang.NullPointerException
>   at 
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
>   at 
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
>   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
> {code}
> As written in latest comment, the root cause seems to be that multiple 
> installFeature calls to FeatureService mess up the state of the bundles. In 
> my case it left a bundle in a corrupt state, which was noticed when the 
> configuration change did not really activate the service.



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

[jira] [Commented] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4255:
-

Thanks for Merging JB,
It works for packaging, but when I start karaf these optionals are installed 
anyway. It seems that in a different place the same check is also missing.

> karaf-maven-plugin does include unused feature conditional dependencies in 
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.5
>
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at: 
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional 
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is 
> actually met.



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

[jira] [Created] (KARAF-4267) Remove derby config from windows karaf.bat

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4267:
---

 Summary: Remove derby config from windows karaf.bat
 Key: KARAF-4267
 URL: https://issues.apache.org/jira/browse/KARAF-4267
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange
Priority: Minor


The windows version of the launch script configures derby.
I assume it is not used, because it is not done in linux, so this should be 
probably removed.



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

[jira] [Updated] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-4255:

Summary: karaf-maven-plugin does include unused feature conditional 
dependencies in assembly  (was: karaf-maven-plugin does include unused 
optionals in assembly)

> karaf-maven-plugin does include unused feature conditional dependencies in 
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at: 
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional 
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is 
> actually met.



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

[jira] [Created] (KARAF-4255) karaf-maven-plugin does include unused optionals in assembly

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4255:
---

 Summary: karaf-maven-plugin does include unused optionals in 
assembly
 Key: KARAF-4255
 URL: https://issues.apache.org/jira/browse/KARAF-4255
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.3
Reporter: Fabian Lange


I am using karaf-maven-plugin to make a custom assembly.
I do include SCR, but I do not include webconsole.
When I look into the system folder of my generated assembly, I can see:
{code}
target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
{code}
this correlates to the maven output:

{code}
[INFO] Feature scr is defined as a boot feature
[INFO] == Installing artifact 
mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
[INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
[INFO] == Installing artifact 
mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
[INFO] == Installing artifact 
mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
[INFO] == Installing artifact 
mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
[INFO] == Installing artifact 
mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
{code}

however looking at: 
https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
you can see that this is an conditional dependency only.

This is caused by the fact that assembly does not check if the conditional had 
been met:
https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822

I believe we need a check for the conditionals wether the condition is actually 
met.



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

[jira] [Commented] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4255:
-

I guess the place at runtime is here:
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/region/Subsystem.java#L289
but unfortunately my understanding of that code is too limited to figure out if 
thats correct and how to fix.

> karaf-maven-plugin does include unused feature conditional dependencies in 
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at: 
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional 
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is 
> actually met.



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

[jira] [Commented] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4255:
-

My PR works for assembly, but it seems that also during runtime the 
conditionals are not evaluated correctly, because when starting karaf the 
excluded bundles (e.g.  
mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2) are still 
installed (then from internet not system folder)

> karaf-maven-plugin does include unused feature conditional dependencies in 
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at: 
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional 
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is 
> actually met.



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

[jira] [Commented] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4255:
-

This also applies to conditional config entries, like the conditional to  
feature "management" in feature "bundle"

> karaf-maven-plugin does include unused feature conditional dependencies in 
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at: 
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional 
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is 
> actually met.



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

[jira] [Commented] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4255:
-

I am using 
{code}
false
{code}
which will cause it to install the bundle regardless of it being marked a 
dependency.
I could not use it, but that would not change much because they are not marked 
as dependency

Also the runtime aspect seems to also be handling it not as true conditional 
either

> karaf-maven-plugin does include unused feature conditional dependencies in 
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at: 
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional 
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is 
> actually met.



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

[jira] [Comment Edited] (KARAF-4255) karaf-maven-plugin does include unused feature conditional dependencies in assembly

[Fabian Lange (JIRA)]

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

Fabian Lange edited comment on KARAF-4255 at 1/10/16 4:59 PM:
--

I am using 
{code}
false
{code}
which will cause it to install the bundle regardless of it being marked a 
dependency.
I could not use it, but that would not change much because they are not marked 
as dependency

Also the runtime aspect seems to also be handling it not as true conditional 
either

(just also verified with ignoreDependency=true -> same behaviour. I get the 
webconsole bundle installed through scr


was (Author: fabianlange):
I am using 
{code}
false
{code}
which will cause it to install the bundle regardless of it being marked a 
dependency.
I could not use it, but that would not change much because they are not marked 
as dependency

Also the runtime aspect seems to also be handling it not as true conditional 
either

> karaf-maven-plugin does include unused feature conditional dependencies in 
> assembly
> ---
>
> Key: KARAF-4255
> URL: https://issues.apache.org/jira/browse/KARAF-4255
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
>
> I am using karaf-maven-plugin to make a custom assembly.
> I do include SCR, but I do not include webconsole.
> When I look into the system folder of my generated assembly, I can see:
> {code}
> target/assembly/system/org/apache/felix/org.apache.felix.webconsole.plugins.ds/2.0.2/org.apache.felix.webconsole.plugins.ds-2.0.2.jar
> {code}
> this correlates to the maven output:
> {code}
> [INFO] Feature scr is defined as a boot feature
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.command/4.0.3
> [INFO] == Installing artifact mvn:org.apache.felix/org.apache.felix.scr/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.scr.compat/1.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.0.2
> [INFO] == Installing artifact 
> mvn:org.apache.felix/org.apache.felix.metatype/1.1.2
> [INFO] == Installing artifact 
> mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.0.3
> {code}
> however looking at: 
> https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L524
> you can see that this is an conditional dependency only.
> This is caused by the fact that assembly does not check if the conditional 
> had been met:
> https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L822
> I believe we need a check for the conditionals wether the condition is 
> actually met.



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

[jira] [Commented] (KARAF-4199) Privacy Violation: Heap Inspection

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4199:
-

The PR is insufficient, as I noted in the PR.
The problem is not (only) in Karaf, but the whole Apache Mina sshd 
UserAuthKeyboardInteractive is broken (if you consider this a valid attack)

A proper fix would be to rewrite Mina sshd to work with byte char arrays 
instead of Strings.

A hot fix could be to to use reflection to remove the backing array after 
session.auth() (but this will break in java9 with compact strings)

> Privacy Violation: Heap Inspection
> --
>
> Key: KARAF-4199
> URL: https://issues.apache.org/jira/browse/KARAF-4199
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Eduardo Aguinaga
>
> HP Fortify and SciTools Understand were used to perform an application 
> security scan on the karaf source code.
> The method interactive() in Main.java stores sensitive data in a String 
> object on line 127, making it impossible to reliably purge the data from 
> memory.
> Main.java, lines 120-137:
> {code}
> 120 public String[] interactive(String destination, String name, String 
> instruction, String[] prompt, boolean[] echo) {
> 121 String[] answers = new String[prompt.length];
> 122 try {
> 123 for (int i = 0; i < prompt.length; i++) {
> 124 if (echo[i]) {
> 125 answers[i] = console.readLine(prompt[i] + " ");
> 126 } else {
> 127 answers[i] = new String(console.readPassword(prompt[i] + 
> " "));
> 128 }
> 129 if (answers[i] == null) {
> 130 return null;
> 131 }
> 132 }
> 133 return answers;
> 134 } catch (IOError e) {
> 135 return null;
> 136 }
> 137 }
> {code}



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

[jira] [Commented] (KARAF-4235) WIndows start script requires data dir

[Fabian Lange (JIRA)]

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

Fabian Lange commented on KARAF-4235:
-

yes but start.bat sets a non empty variable, which will cause the directory 
existing check in karaf.bat to fail. This is what my error output confirms.
The reason i wonder is that on linux it has similar code but does start with 
nonexistant data dir.

> WIndows start script requires data dir
> --
>
> Key: KARAF-4235
> URL: https://issues.apache.org/jira/browse/KARAF-4235
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Fabian Lange
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.0.4
>
>
> I am observing the following problem
> On linux, if I delete the data dir, it is recreated.
> On Windows, if I run the start.bat, the output is:
> karaf.bat: Ignoring predefined value for KARAF_HOME
> karaf.bat: KARAF_DATA is not valid: 
> "C:\Users\Fabian\Downloads\apache-karaf-4.0.3\bin\..\data"
> C:\Users\Fabian\Downloads\apache-karaf-4.0.3\bin>
> I checked the difference, and right now I am actually wondering more why it 
> works on linux, rather than why it doesn't on windows, but I think also n 
> windows the data dir should be recreated.
> STR:
> Download Karaf 4.0.3 on windows.
> unpack and delete data dir.
> try to run start.bat
> running karaf.bat will work however



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

[jira] [Created] (KARAF-4235) WIndows start script requires data dir

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-4235:
---

 Summary: WIndows start script requires data dir
 Key: KARAF-4235
 URL: https://issues.apache.org/jira/browse/KARAF-4235
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.3
Reporter: Fabian Lange


I am observing the following problem

On linux, if I delete the data dir, it is recreated.
On Windows, if I run the start.bat, the output is:

karaf.bat: Ignoring predefined value for KARAF_HOME
karaf.bat: KARAF_DATA is not valid: 
"C:\Users\Fabian\Downloads\apache-karaf-4.0.3\bin\..\data"
C:\Users\Fabian\Downloads\apache-karaf-4.0.3\bin>

I checked the difference, and right now I am actually wondering more why it 
works on linux, rather than why it doesn't on windows, but I think also n 
windows the data dir should be recreated.

STR:
Download Karaf 4.0.3 on windows.
unpack and delete data dir.
try to run start.bat


running karaf.bat will work however





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

[jira] [Created] (KARAF-3935) Cannot build distribution from repository other than central

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3935:
---

 Summary: Cannot build distribution from repository other than 
central
 Key: KARAF-3935
 URL: https://issues.apache.org/jira/browse/KARAF-3935
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


I am hitting a roadblock building a custom distribution with staging repo.
I looks like that the karaf-maven-plugin:4.0.1:assembly (default-assembly) uses 
an unconfigured pax-url MavenResolver:
https://github.com/apache/karaf/blob/master/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L370

The only repository this thing knows is maven central.
So of course the distribution build fails:
Error resolving artifact 
org.apache.karaf.package:org.apache.karaf.package.core:jar:4.0.1: Could not 
find artifact org.apache.karaf.package:org.apache.karaf.package.core:jar:4.0.1 
in central (http://repo1.maven.org/maven2/)

I have yet been unsuccessful in convincing it to use ay maven settings i can 
actually influence and point to the staging repo.


This is also the reason why the jenkins build fails:
https://builds.apache.org/view/H-L/view/Karaf/job/karaf-master/



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

[jira] [Created] (KARAF-3923) Karaf opens RMI port even when not using the managemtn feature

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3923:
---

 Summary: Karaf opens RMI port even when not using the managemtn 
feature
 Key: KARAF-3923
 URL: https://issues.apache.org/jira/browse/KARAF-3923
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange
 Attachments: Screen Shot 2015-08-11 at 00.03.37.png

My Karaf opens a random port (one below the shutdown port) on startup.
I figured out it is an RM Port (see screenshot)

This port cannot be influenced by org.apache.karaf.management.cfg.

I need to either disable the port, or at least let it listen to localhost only.

I have the following bundles:
ID | State  | Lvl | Version | Name

 0 | Active |   0 | 5.0.1   | System Bundle
 1 | Active |   8 | 1.8.3   | OPS4J Pax Logging - API
 2 | Active |   8 | 1.8.3   | OPS4J Pax Logging - Service
 3 | Active |  10 | 1.8.4   | Apache Felix Configuration Admin Service
 4 | Active |  11 | 3.5.0   | Apache Felix File Install
 5 | Active |   5 | 2.4.1   | OPS4J Pax Url - aether:
 6 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Core
 7 | Active |  80 | 1.0.5   | Fabians Bootstrap - Bundle
 8 | Active |  30 | 2.12.1  | JLine
 9 | Active |  30 | 1.0.12  | Apache Felix Metatype Service
10 | Active |  30 | 1.8.2   | Apache Felix Declarative Services
11 | Active |  30 | 4.0.0   | Apache Karaf :: Bundle :: Core
12 | Active |  30 | 4.0.0   | Apache Karaf :: ConfigAdmin :: Core
13 | Active |  80 | 4.0.0   | Apache Karaf :: Diagnostic :: Boot
14 | Active |  30 | 4.0.0   | Apache Karaf :: Diagnostic :: Core
15 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Command
16 | Active |  80 | 4.0.0   | Apache Karaf :: JAAS :: Boot
17 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Command
18 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Config
19 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Modules
20 | Active |  30 | 4.0.0   | Apache Karaf :: Log :: Core
21 | Active |  30 | 4.0.0   | Apache Karaf :: Package :: Core
22 | Active |  30 | 4.0.0   | Apache Karaf :: SCR :: Shell Commands
23 | Active |  30 | 4.0.0   | Apache Karaf :: Service :: Core
24 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Various Commands
25 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Core
26 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: SSH
27 | Active |  30 | 4.0.0   | Apache Karaf :: System :: Core
28 | Active |  30 | 0.14.0  | Apache Mina SSHD :: Core



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

[jira] [Updated] (KARAF-3923) Karaf opens RMI port even when not using the management feature

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-3923:

Attachment: Screen Shot 2015-08-11 at 00.03.37.png

 Karaf opens RMI port even when not using the management feature
 ---

 Key: KARAF-3923
 URL: https://issues.apache.org/jira/browse/KARAF-3923
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange
 Attachments: Screen Shot 2015-08-11 at 00.03.37.png


 My Karaf opens a random port (one below the shutdown port) on startup.
 I figured out it is an RM Port (see screenshot)
 This port cannot be influenced by org.apache.karaf.management.cfg.
 I need to either disable the port, or at least let it listen to localhost 
 only.
 I have the following bundles:
 ID | State  | Lvl | Version | Name
 
  0 | Active |   0 | 5.0.1   | System Bundle
  1 | Active |   8 | 1.8.3   | OPS4J Pax Logging - API
  2 | Active |   8 | 1.8.3   | OPS4J Pax Logging - Service
  3 | Active |  10 | 1.8.4   | Apache Felix Configuration Admin Service
  4 | Active |  11 | 3.5.0   | Apache Felix File Install
  5 | Active |   5 | 2.4.1   | OPS4J Pax Url - aether:
  6 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Core
  7 | Active |  80 | 1.0.5   | Fabians Bootstrap - Bundle
  8 | Active |  30 | 2.12.1  | JLine
  9 | Active |  30 | 1.0.12  | Apache Felix Metatype Service
 10 | Active |  30 | 1.8.2   | Apache Felix Declarative Services
 11 | Active |  30 | 4.0.0   | Apache Karaf :: Bundle :: Core
 12 | Active |  30 | 4.0.0   | Apache Karaf :: ConfigAdmin :: Core
 13 | Active |  80 | 4.0.0   | Apache Karaf :: Diagnostic :: Boot
 14 | Active |  30 | 4.0.0   | Apache Karaf :: Diagnostic :: Core
 15 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Command
 16 | Active |  80 | 4.0.0   | Apache Karaf :: JAAS :: Boot
 17 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Command
 18 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Config
 19 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Modules
 20 | Active |  30 | 4.0.0   | Apache Karaf :: Log :: Core
 21 | Active |  30 | 4.0.0   | Apache Karaf :: Package :: Core
 22 | Active |  30 | 4.0.0   | Apache Karaf :: SCR :: Shell Commands
 23 | Active |  30 | 4.0.0   | Apache Karaf :: Service :: Core
 24 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Various Commands
 25 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Core
 26 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: SSH
 27 | Active |  30 | 4.0.0   | Apache Karaf :: System :: Core
 28 | Active |  30 | 0.14.0  | Apache Mina SSHD :: Core



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

[jira] [Updated] (KARAF-3923) Karaf opens RMI port even when not using the management feature

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-3923:

Summary: Karaf opens RMI port even when not using the management feature  
(was: Karaf opens RMI port even when not using the managemtn feature)

 Karaf opens RMI port even when not using the management feature
 ---

 Key: KARAF-3923
 URL: https://issues.apache.org/jira/browse/KARAF-3923
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange
 Attachments: Screen Shot 2015-08-11 at 00.03.37.png


 My Karaf opens a random port (one below the shutdown port) on startup.
 I figured out it is an RM Port (see screenshot)
 This port cannot be influenced by org.apache.karaf.management.cfg.
 I need to either disable the port, or at least let it listen to localhost 
 only.
 I have the following bundles:
 ID | State  | Lvl | Version | Name
 
  0 | Active |   0 | 5.0.1   | System Bundle
  1 | Active |   8 | 1.8.3   | OPS4J Pax Logging - API
  2 | Active |   8 | 1.8.3   | OPS4J Pax Logging - Service
  3 | Active |  10 | 1.8.4   | Apache Felix Configuration Admin Service
  4 | Active |  11 | 3.5.0   | Apache Felix File Install
  5 | Active |   5 | 2.4.1   | OPS4J Pax Url - aether:
  6 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Core
  7 | Active |  80 | 1.0.5   | Fabians Bootstrap - Bundle
  8 | Active |  30 | 2.12.1  | JLine
  9 | Active |  30 | 1.0.12  | Apache Felix Metatype Service
 10 | Active |  30 | 1.8.2   | Apache Felix Declarative Services
 11 | Active |  30 | 4.0.0   | Apache Karaf :: Bundle :: Core
 12 | Active |  30 | 4.0.0   | Apache Karaf :: ConfigAdmin :: Core
 13 | Active |  80 | 4.0.0   | Apache Karaf :: Diagnostic :: Boot
 14 | Active |  30 | 4.0.0   | Apache Karaf :: Diagnostic :: Core
 15 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Command
 16 | Active |  80 | 4.0.0   | Apache Karaf :: JAAS :: Boot
 17 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Command
 18 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Config
 19 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Modules
 20 | Active |  30 | 4.0.0   | Apache Karaf :: Log :: Core
 21 | Active |  30 | 4.0.0   | Apache Karaf :: Package :: Core
 22 | Active |  30 | 4.0.0   | Apache Karaf :: SCR :: Shell Commands
 23 | Active |  30 | 4.0.0   | Apache Karaf :: Service :: Core
 24 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Various Commands
 25 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Core
 26 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: SSH
 27 | Active |  30 | 4.0.0   | Apache Karaf :: System :: Core
 28 | Active |  30 | 0.14.0  | Apache Mina SSHD :: Core



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

[jira] [Commented] (KARAF-3923) Karaf opens RMI port even when not using the management feature

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14680899#comment-14680899
 ] 

Fabian Lange commented on KARAF-3923:
-

Ok, that was much easier than I thought. The karaf.sh and karaf.bat files 
specify both:

-Dcom.sun.management.jmxremote

I guess it could be documented in the management.cfg file or elsewhere that 
this flag needs to be removed if jmx is not wanted.

 Karaf opens RMI port even when not using the management feature
 ---

 Key: KARAF-3923
 URL: https://issues.apache.org/jira/browse/KARAF-3923
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange
 Attachments: Screen Shot 2015-08-11 at 00.03.37.png


 My Karaf opens a random port (one below the shutdown port) on startup.
 I figured out it is an RM Port (see screenshot)
 This port cannot be influenced by org.apache.karaf.management.cfg.
 I need to either disable the port, or at least let it listen to localhost 
 only.
 I have the following bundles:
 ID | State  | Lvl | Version | Name
 
  0 | Active |   0 | 5.0.1   | System Bundle
  1 | Active |   8 | 1.8.3   | OPS4J Pax Logging - API
  2 | Active |   8 | 1.8.3   | OPS4J Pax Logging - Service
  3 | Active |  10 | 1.8.4   | Apache Felix Configuration Admin Service
  4 | Active |  11 | 3.5.0   | Apache Felix File Install
  5 | Active |   5 | 2.4.1   | OPS4J Pax Url - aether:
  6 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Core
  7 | Active |  80 | 1.0.5   | Fabians Bootstrap - Bundle
  8 | Active |  30 | 2.12.1  | JLine
  9 | Active |  30 | 1.0.12  | Apache Felix Metatype Service
 10 | Active |  30 | 1.8.2   | Apache Felix Declarative Services
 11 | Active |  30 | 4.0.0   | Apache Karaf :: Bundle :: Core
 12 | Active |  30 | 4.0.0   | Apache Karaf :: ConfigAdmin :: Core
 13 | Active |  80 | 4.0.0   | Apache Karaf :: Diagnostic :: Boot
 14 | Active |  30 | 4.0.0   | Apache Karaf :: Diagnostic :: Core
 15 | Active |  30 | 4.0.0   | Apache Karaf :: Features :: Command
 16 | Active |  80 | 4.0.0   | Apache Karaf :: JAAS :: Boot
 17 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Command
 18 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Config
 19 | Active |  30 | 4.0.0   | Apache Karaf :: JAAS :: Modules
 20 | Active |  30 | 4.0.0   | Apache Karaf :: Log :: Core
 21 | Active |  30 | 4.0.0   | Apache Karaf :: Package :: Core
 22 | Active |  30 | 4.0.0   | Apache Karaf :: SCR :: Shell Commands
 23 | Active |  30 | 4.0.0   | Apache Karaf :: Service :: Core
 24 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Various Commands
 25 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: Core
 26 | Active |  30 | 4.0.0   | Apache Karaf :: Shell :: SSH
 27 | Active |  30 | 4.0.0   | Apache Karaf :: System :: Core
 28 | Active |  30 | 0.14.0  | Apache Mina SSHD :: Core



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

[jira] [Created] (KARAF-3912) Make default client log level configurable

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3912:
---

 Summary: Make default client log level configurable
 Key: KARAF-3912
 URL: https://issues.apache.org/jira/browse/KARAF-3912
 Project: Karaf
  Issue Type: Improvement
Reporter: Fabian Lange


I would like to change the default log level of the bin/client shell.
I checked the Client Config and it is hardcoded to SimpleLogger.WARN

Could you please make it configurable via org.apache.karaf.shell.cfg ?

The patch is trivial:

{{{
level = Integer.parseInt(shellCfg.getProperty(logLevel, 1));
}}}

Thanks



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

[jira] [Commented] (KARAF-3912) Make default client log level configurable

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14663322#comment-14663322
 ] 

Fabian Lange commented on KARAF-3912:
-

Thanks for the quick reaction and this useful addition

 Make default client log level configurable
 --

 Key: KARAF-3912
 URL: https://issues.apache.org/jira/browse/KARAF-3912
 Project: Karaf
  Issue Type: Improvement
Reporter: Fabian Lange
Assignee: Jean-Baptiste Onofré
 Fix For: 4.0.1


 I would like to change the default log level of the bin/client shell.
 I checked the Client Config and it is hardcoded to SimpleLogger.WARN
 Could you please make it configurable via org.apache.karaf.shell.cfg ?
 The patch is trivial:
 {{{
 level = Integer.parseInt(shellCfg.getProperty(logLevel, 1));
 }}}
 Thanks



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

[jira] [Created] (KARAF-3910) Client.sh references nonexistant mina-core jar

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3910:
---

 Summary: Client.sh references nonexistant mina-core jar
 Key: KARAF-3910
 URL: https://issues.apache.org/jira/browse/KARAF-3910
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.0
Reporter: Fabian Lange


The client.sh script references this file:
CLASSPATH=$CLASSPATH:$KARAF_HOME/system/org/apache/mina/mina-core/2.0.7/mina-core-2.0.7.jar

however I could not find it in a default karaf installation.



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

[jira] [Commented] (KARAF-3807) Strange file included in release by assembly plugin

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604064#comment-14604064
 ] 

Fabian Lange commented on KARAF-3807:
-

sry, jira search did not find it and I didnt look back 2 days. thanks

 Strange file included in release by assembly plugin
 ---

 Key: KARAF-3807
 URL: https://issues.apache.org/jira/browse/KARAF-3807
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.0
Reporter: Fabian Lange
Assignee: Jean-Baptiste Onofré

 The 4.0 GA and custom dists built with the assembly plugin include files here:
 apache-karaf-4.0.0/apache-karaf-4.0.0/system/file:/x1/asf/karaf/k40x/target/checkout/assemblies/apache-karaf/target
 This was reported also on dev, creating issue to track.



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

[jira] [Created] (KARAF-3807) Strange file included in release by assembly plugin

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3807:
---

 Summary: Strange file included in release by assembly plugin
 Key: KARAF-3807
 URL: https://issues.apache.org/jira/browse/KARAF-3807
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.0
Reporter: Fabian Lange


The 4.0 GA and custom dists built with the assembly plugin include files here:

apache-karaf-4.0.0/apache-karaf-4.0.0/system/file:/x1/asf/karaf/k40x/target/checkout/assemblies/apache-karaf/target

This was reported also on dev, creating issue to track.



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

[jira] [Commented] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595417#comment-14595417
 ] 

Fabian Lange commented on KARAF-3798:
-

I can check this on 4.0 once its out.
I have a theoretical STR in my head, which should be as follows:

feature a
 - bundle a1
 - bundle a2

feature b
 - bundle b1

bundle a1 activation does feature.install(feature b), bundle a2 activation does 
Thread sleep.

Bundle b1 should provide an immediate Service. If the bug exists, the service 
will not be there.

It might be necessary to add a few more bundles to a, to produce it (in my case 
i have about 20)

 FeaturesServiceImpl not threadsafe
 --

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Affects Versions: 4.0.0.M3
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there are multiple 
 features installed on startup and config files to activate them created.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}
 As written in latest comment, the root cause seems to be that multiple 
 installFeature calls to FeatureService mess up the state of the bundles. In 
 my case it left a bundle in a corrupt state, which was noticed when the 
 configuration change did not really activate the service.



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

[jira] [Issue Comment Deleted] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-3798:

Comment: was deleted

(was: removing and installing the bundle makes it work, so its not the bundle 
itself, but the loading)

 FeaturesServiceImpl not threadsafe
 --

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Issue Comment Deleted] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-3798:

Comment: was deleted

(was: More info,
after this happens, the service which doesn't work has BundleLocation: null
other config files loaded have a correct bundleLocation)

 FeaturesServiceImpl not threadsafe
 --

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Commented] (KARAF-3798) NullPointerException when fileinstall/configadmin is used directly after startup

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14594026#comment-14594026
 ] 

Fabian Lange commented on KARAF-3798:
-

Ok, i have narrowed it down. My bootFeature was installing further features 
simultaneously. 

it seems that org.apache.karaf.features.internal.service.FeaturesServiceImpl is 
not threadsafe in the following sense:

when a Thread calls installFeature, while another installFeature is still 
running, the bundle state will be strange, as seen above.
The bundle will be listed as installed but not have any services deployed.

I worked around this by waiting for the installation to finish.

 NullPointerException when fileinstall/configadmin is used directly after 
 startup
 

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Updated] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-3798:

Summary: FeaturesServiceImpl not threadsafe  (was: NullPointerException 
when fileinstall/configadmin is used directly after startup)

 FeaturesServiceImpl not threadsafe
 --

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Updated] (KARAF-3798) FeaturesServiceImpl not threadsafe

[Fabian Lange (JIRA)]

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

Fabian Lange updated KARAF-3798:

Description: 
This error happens pretty frequently with M3, when there are multiple features 
installed on startup and config files to activate them created.
{code}
2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin
  | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
java.lang.NullPointerException
at 
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
at 
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
{code}

As written in latest comment, the root cause seems to be that multiple 
installFeature calls to FeatureService mess up the state of the bundles. In my 
case it left a bundle in a corrupt state, which was noticed when the 
configuration change did not really activate the service.

  was:
This error happens pretty frequently with M3, when there is a config file 
created directly after startup. I tried to look how scr is implemented, but 
everything newer than 1.8.2 seems to be a mess in git.
{code}
2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin
  | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
java.lang.NullPointerException
at 
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
at 
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
{code}


 FeaturesServiceImpl not threadsafe
 --

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there are multiple 
 features installed on startup and config files to activate them created.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}
 As written in latest comment, the root cause seems to be that multiple 
 installFeature calls to FeatureService mess up the state of the bundles. In 
 my case it left a bundle in a corrupt state, which was noticed when the 
 configuration change did not really activate the service.



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

[jira] [Created] (KARAF-3798) NullPointerException when fileinstall/configadmin is used directly after startup

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3798:
---

 Summary: NullPointerException when fileinstall/configadmin is used 
directly after startup
 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


This error happens pretty frequently with M3, when there is a config file 
created directly after startup. I tried to look how scr is implemented, but 
everything newer than 1.8.2 seems to be a mess in git.
{code}
2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin
  | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
java.lang.NullPointerException
at 
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
at 
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
{code}



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

[jira] [Commented] (KARAF-3798) NullPointerException when fileinstall/configadmin is used directly after startup

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593460#comment-14593460
 ] 

Fabian Lange commented on KARAF-3798:
-

when i stop karaf, the following exception is printed for that bundle
{code}
java.lang.IllegalStateException: Invalid BundleContext.
at 
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:475)[org.apache.felix.framework-5.0.0.jar:]
at 
org.osgi.util.tracker.ServiceTracker.removedService(ServiceTracker.java:456)[9:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956)[9:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864)[9:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)[9:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:375)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:353)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:313)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.Activator.access$300(Activator.java:45)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:198)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)[9:org.apache.felix.scr:1.8.2]
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 
org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.utils.extender.AbstractExtender.stop(AbstractExtender.java:125)[9:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.Felix.stopBundle(Felix.java:2604)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1383)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)[org.apache.felix.framework-5.0.0.jar:]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
{code}

 NullPointerException when fileinstall/configadmin is used directly after 
 startup
 

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Commented] (KARAF-3798) NullPointerException when fileinstall/configadmin is used directly after startup

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593689#comment-14593689
 ] 

Fabian Lange commented on KARAF-3798:
-

More info,
after this happens, the service which doesn't work has BundleLocation: null
other config files loaded have a correct bundleLocation

 NullPointerException when fileinstall/configadmin is used directly after 
 startup
 

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Commented] (KARAF-3798) NullPointerException when fileinstall/configadmin is used directly after startup

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593846#comment-14593846
 ] 

Fabian Lange commented on KARAF-3798:
-

maybe its really a follow up problem. the bundle:info of said bundle does not 
return anything. despite is claim that its started

 NullPointerException when fileinstall/configadmin is used directly after 
 startup
 

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Commented] (KARAF-3798) NullPointerException when fileinstall/configadmin is used directly after startup

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593848#comment-14593848
 ] 

Fabian Lange commented on KARAF-3798:
-

removing and installing the bundle makes it work, so its not the bundle itself, 
but the loading

 NullPointerException when fileinstall/configadmin is used directly after 
 startup
 

 Key: KARAF-3798
 URL: https://issues.apache.org/jira/browse/KARAF-3798
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange

 This error happens pretty frequently with M3, when there is a config file 
 created directly after startup. I tried to look how scr is implemented, but 
 everything newer than 1.8.2 seems to be a mess in git.
 {code}
 2015-06-19 15:55:12,249 | ERROR | 43-3aaf88a7bd8b) | configadmin  
 | 3 - org.apache.felix.configadmin - 1.8.4 | Unexpected problem 
 delivering configuration event to [org.osgi.service.cm.ConfigurationListener, 
 id=30, bundle=9/mvn:org.apache.felix/org.apache.felix.scr/1.8.2]
 java.lang.NullPointerException
   at 
 org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283)[9:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2036)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2005)[3:org.apache.felix.configadmin:1.8.4]
   at 
 org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4]
   at java.lang.Thread.run(Thread.java:745)[:1.8.0_40]
 {code}



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

[jira] [Created] (KARAF-3765) Eventadmin loggs warnings about wrong values

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3765:
---

 Summary: Eventadmin loggs warnings about wrong values
 Key: KARAF-3765
 URL: https://issues.apache.org/jira/browse/KARAF-3765
 Project: Karaf
  Issue Type: Bug
Reporter: Fabian Lange


015-06-09 11:15:29,373 | WARN  | Thread-12| eventadmin  
 | 31 - org.apache.karaf.services.eventadmin - 4.0.0.M3 | EventAdmin: Value 
for property: org.apache.felix.eventadmin.IgnoreTimeout is neither a string nor 
a string array - Using default
2015-06-09 11:15:29,374 | WARN  | Thread-12| eventadmin 
  | 31 - org.apache.karaf.services.eventadmin - 4.0.0.M3 | EventAdmin: 
Value for property: org.apache.felix.eventadmin.IgnoreTopic is neither a string 
nor a string array - Using default



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

[jira] [Created] (KARAF-3764) Features Service Refresh

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3764:
---

 Summary: Features Service Refresh
 Key: KARAF-3764
 URL: https://issues.apache.org/jira/browse/KARAF-3764
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.0.M3
Reporter: Fabian Lange


My Karaf startup does not work anymore with M3. in M2 it worked.

Here are he relevant parts from the log file:
{code}
2015-06-09 11:16:29,606 | INFO  | pool-16-thread-1 | FeaturesServiceImpl
  | 6 - org.apache.karaf.features.core - 4.0.0.M3 | Refreshing bundles:
2015-06-09 11:16:29,606 | INFO  | pool-16-thread-1 | FeaturesServiceImpl
  | 6 - org.apache.karaf.features.core - 4.0.0.M3 | 
org.apache.karaf.diagnostic.core / 4.0.0.M3 (Wired to 
org.apache.karaf.features.core/4.0.0.M3 which is being refreshed)
2015-06-09 11:16:29,607 | INFO  | pool-16-thread-1 | FeaturesServiceImpl
  | 6 - org.apache.karaf.features.core - 4.0.0.M3 | 
org.apache.karaf.features.command / 4.0.0.M3 (Wired to 
org.apache.karaf.features.core/4.0.0.M3 which is being refreshed)
2015-06-09 11:16:29,607 | INFO  | pool-16-thread-1 | FeaturesServiceImpl
  | 6 - org.apache.karaf.features.core - 4.0.0.M3 | 
org.apache.karaf.features.core / 4.0.0.M3 (Should be wired to: 
org.apache.karaf.services.eventadmin/4.0.0.M3 (through 
[org.apache.karaf.features.core/4.0.0.M3] osgi.wiring.package; 
filter:=((osgi.wiring.package=org.osgi.service.event)(version=1.3.0)(!(version=2.0.0)));
 resolution:=optional))
{code}

this in turn then fails
{code}
Cannot register Component
java.lang.IllegalStateException: Invalid BundleContext.
at 
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:114)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:357)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:258)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:158)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.BundleComponentActivator.init(BundleComponentActivator.java:120)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:258)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.Activator.access$000(Activator.java:45)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:185)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)[14:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:479)[14:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:414)[14:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)[14:org.apache.felix.scr:1.8.2]
at 
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)[14:org.apache.felix.scr:1.8.2]
at 
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4520)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2166)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)[org.apache.felix.framework-5.0.0.jar:]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1171)[6:org.apache.karaf.features.core:4.0.0.M3]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:826)[6:org.apache.karaf.features.core:4.0.0.M3]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1061)[6:org.apache.karaf.features.core:4.0.0.M3]
   

[jira] [Commented] (KARAF-3764) Features Service Refresh

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578950#comment-14578950
 ] 

Fabian Lange commented on KARAF-3764:
-

To work around this (basically to prevent the features core from refreshing) i 
have loaded eventadmin via startup properties
{code}
mvn\:org.apache.karaf.services/org.apache.karaf.services.eventadmin/4.0.0.M3 = 
14
mvn\:org.apache.karaf.features/org.apache.karaf.features.core/4.0.0.M3 = 15
{code}

 Features Service Refresh
 

 Key: KARAF-3764
 URL: https://issues.apache.org/jira/browse/KARAF-3764
 Project: Karaf
  Issue Type: Bug
Affects Versions: 4.0.0.M3
Reporter: Fabian Lange

 My Karaf startup does not work anymore with M3. in M2 it worked.
 Here are he relevant parts from the log file:
 {code}
 2015-06-09 11:16:29,606 | INFO  | pool-16-thread-1 | FeaturesServiceImpl  
 | 6 - org.apache.karaf.features.core - 4.0.0.M3 | Refreshing bundles:
 2015-06-09 11:16:29,606 | INFO  | pool-16-thread-1 | FeaturesServiceImpl  
 | 6 - org.apache.karaf.features.core - 4.0.0.M3 | 
 org.apache.karaf.diagnostic.core / 4.0.0.M3 (Wired to 
 org.apache.karaf.features.core/4.0.0.M3 which is being refreshed)
 2015-06-09 11:16:29,607 | INFO  | pool-16-thread-1 | FeaturesServiceImpl  
 | 6 - org.apache.karaf.features.core - 4.0.0.M3 | 
 org.apache.karaf.features.command / 4.0.0.M3 (Wired to 
 org.apache.karaf.features.core/4.0.0.M3 which is being refreshed)
 2015-06-09 11:16:29,607 | INFO  | pool-16-thread-1 | FeaturesServiceImpl  
 | 6 - org.apache.karaf.features.core - 4.0.0.M3 | 
 org.apache.karaf.features.core / 4.0.0.M3 (Should be wired to: 
 org.apache.karaf.services.eventadmin/4.0.0.M3 (through 
 [org.apache.karaf.features.core/4.0.0.M3] osgi.wiring.package; 
 filter:=((osgi.wiring.package=org.osgi.service.event)(version=1.3.0)(!(version=2.0.0)));
  resolution:=optional))
 {code}
 this in turn then fails
 {code}
 Cannot register Component
 java.lang.IllegalStateException: Invalid BundleContext.
   at 
 org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)[org.apache.felix.framework-5.0.0.jar:]
   at 
 org.apache.felix.framework.BundleContextImpl.getBundle(BundleContextImpl.java:114)[org.apache.felix.framework-5.0.0.jar:]
   at 
 org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:357)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:258)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:158)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.scr.impl.BundleComponentActivator.init(BundleComponentActivator.java:120)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:258)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.scr.impl.Activator.access$000(Activator.java:45)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:185)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.utils.extender.AbstractExtender.createExtension(AbstractExtender.java:259)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.utils.extender.AbstractExtender.modifiedBundle(AbstractExtender.java:232)[14:org.apache.felix.scr:1.8.2]
   at 
 org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:479)[14:org.apache.felix.scr:1.8.2]
   at 
 org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:414)[14:org.apache.felix.scr:1.8.2]
   at 
 org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)[14:org.apache.felix.scr:1.8.2]
   at 
 org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)[14:org.apache.felix.scr:1.8.2]
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:913)[org.apache.felix.framework-5.0.0.jar:]
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)[org.apache.felix.framework-5.0.0.jar:]
   at 
 org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)[org.apache.felix.framework-5.0.0.jar:]
   at 
 org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4520)[org.apache.felix.framework-5.0.0.jar:]
   at 
 org.apache.felix.framework.Felix.startBundle(Felix.java:2166)[org.apache.felix.framework-5.0.0.jar:]
   at 
 org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)[org.apache.felix.framework-5.0.0.jar:]
   at 
 

[jira] [Commented] (KARAF-3515) branding.properties file in the etc folder doesn't work

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578960#comment-14578960
 ] 

Fabian Lange commented on KARAF-3515:
-

confirmed ok in M3

 branding.properties file in the etc folder doesn't work
 ---

 Key: KARAF-3515
 URL: https://issues.apache.org/jira/browse/KARAF-3515
 Project: Karaf
  Issue Type: Bug
  Components: karaf-shell
Affects Versions: 4.0.0.M1, 4.0.0.M2
Reporter: Jean-Baptiste Onofré
Assignee: Jean-Baptiste Onofré
 Fix For: 4.0.0.M3


 Dropping a branding.properties file in the etc folder doesn't work. The 
 default branding is used.



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

[jira] [Commented] (KARAF-3567) Branding not applied to shell

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578953#comment-14578953
 ] 

Fabian Lange commented on KARAF-3567:
-

I can confirm this works now with the branding.properties in etc. I have not 
checked the old way of branding.

 Branding not applied to shell
 -

 Key: KARAF-3567
 URL: https://issues.apache.org/jira/browse/KARAF-3567
 Project: Karaf
  Issue Type: Bug
  Components: karaf-shell
Affects Versions: 4.0.0.M2
Reporter: Fabian Lange
Assignee: Freeman Fang
 Fix For: 4.0.0.M3


 I have applied the branding according to the instructions here: 
 http://karaf.apache.org/manual/latest/developers-guide/branding.html
 When I start karaf using ./karaf I can see the branding.
 when I connect to that instance using the ./client script, I get the default 
 branding



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

[jira] [Commented] (KARAF-3543) ClassNotFoundException when running shell.sh

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578954#comment-14578954
 ] 

Fabian Lange commented on KARAF-3543:
-

I can confirm this works with M3

 ClassNotFoundException when running shell.sh
 

 Key: KARAF-3543
 URL: https://issues.apache.org/jira/browse/KARAF-3543
 Project: Karaf
  Issue Type: Bug
  Components: karaf-shell
Affects Versions: 4.0.0.M2
Reporter: Fabian Lange
Assignee: Guillaume Nodet
 Fix For: 4.0.0.M3


 Please correct component if I have guessed it wrong.
 If I run karaf with ./start and then try to log into it using ./shell the 
 following error pops up
 {code}
 Exception in thread main java.lang.ClassNotFoundException: 
 org.jledit.ConcreteEditorFactory
   at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
   at 
 org.apache.karaf.shell.impl.console.standalone.Main.discoverCommands(Main.java:209)
   at 
 org.apache.karaf.shell.impl.console.standalone.Main.run(Main.java:148)
   at 
 org.apache.karaf.shell.impl.console.standalone.Main.run(Main.java:136)
   at org.apache.karaf.shell.impl.console.standalone.Main.run(Main.java:76)
   at 
 org.apache.karaf.shell.impl.console.standalone.Main.main(Main.java:59)
 {code}
 this is reproducable with a Karaf M2 standalone build. (in case it matters, I 
 am on osx)



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

[jira] [Commented] (KARAF-3517) Typo in features bundle info

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578959#comment-14578959
 ] 

Fabian Lange commented on KARAF-3517:
-

thanks. confirmed ok in M3

 Typo in features bundle info
 

 Key: KARAF-3517
 URL: https://issues.apache.org/jira/browse/KARAF-3517
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Reporter: Fabian Lange
Assignee: Jean-Baptiste Onofré
Priority: Minor
 Fix For: 3.0.4, 4.0.0.M3


 The Bundle Info for the features bundle claims that all commands are 
 features:
 https://github.com/apache/karaf/blob/d53de84df42a98681bc4cbe4cdb9b226244e6bd9/features/command/src/main/resources/OSGI-INF/bundle.info
 {code}
 The following commands are available:
  * features:addUrl - Adds a list of repository URLs to the features service.
 {code}
 however, the commands actually are named feature:
 {code}
 karaf@root() feature
 feature   feature:info  feature:install   
 feature:list  feature:regions   
 feature:repo-add  feature:repo-list 
 feature:repo-refresh  feature:repo-remove   
 feature:requirement-add   
 feature:requirement-list  feature:requirement-removefeature:start 
 feature:stop  feature:uninstall 
 feature:version-list   
 {code}



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

[jira] [Commented] (KARAF-3585) Snapshots are not updated for the features service

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14347300#comment-14347300
 ] 

Fabian Lange commented on KARAF-3585:
-

Thanks to Guillaume for working on this, even if the fix was reverted.

Just a quick rundown of the problem:

If you install a feature, then the bundles contained in it will be not checked 
for updates if they are of a snapshot version.

The initial fix seemed to be to pass through the updateSpnapshot strategy:
https://github.com/apache/karaf/commit/f4f2c91fa549d504f751f53ff5b65418a04ee163

I am very interested in a fix and would love to help with it.

 Snapshots are not updated for the features service
 --

 Key: KARAF-3585
 URL: https://issues.apache.org/jira/browse/KARAF-3585
 Project: Karaf
  Issue Type: Bug
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
 Fix For: 4.0.0






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

[jira] [Created] (KARAF-3567) Branding not applied to shell

[Fabian Lange (JIRA)]

Fabian Lange created KARAF-3567:
---

 Summary: Branding not applied to shell
 Key: KARAF-3567
 URL: https://issues.apache.org/jira/browse/KARAF-3567
 Project: Karaf
  Issue Type: Bug
  Components: karaf-shell
Affects Versions: 4.0.0.M2
Reporter: Fabian Lange


I have applied the branding according to the instructions here: 
http://karaf.apache.org/manual/latest/developers-guide/branding.html

When I start karaf using ./karaf I can see the branding.
when I connect to that instance using the ./client script, I get the default 
branding



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

[jira] [Commented] (KARAF-2742) karaf-maven-plugin can not include filtered resources in a custom distribution

[Fabian Lange (JIRA)]

[ 
https://issues.apache.org/jira/browse/KARAF-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14333133#comment-14333133
 ] 

Fabian Lange commented on KARAF-2742:
-

I would also like to see this slightly improved.
The reason is that using the maven resources plugin is quite tricky to get 
right, especially if you want to replace a file ususally in the standard bundle 
(like custom.properties). Its actually quite easy to end up with a 
custom.properties.1 file because the karaf bundle will not overwrite.

 karaf-maven-plugin can not include filtered resources in a custom distribution
 --

 Key: KARAF-2742
 URL: https://issues.apache.org/jira/browse/KARAF-2742
 Project: Karaf
  Issue Type: Bug
  Components: karaf-tooling
Affects Versions: 3.0.0
 Environment: Fedora 20, Oracle JDK 1.7.0_51, Maven 3.0.4
Reporter: Partha Roy
Assignee: Jean-Baptiste Onofré
 Fix For: 4.0.0, 3.0.2

 Attachments: CreateArchiveMojo.patch, karaf-filtering-bug.tar.gz


 I am trying to build a custom Karaf distribution by following 
 http://karaf.apache.org/manual/latest/developers-guide/custom-distribution.html.
  I need to add a .cfg file in the karaf/etc directory. However, the maven 
 resource filtering on that .cfg file does not work.
 The sample project looks like:
 {code}
 karaf-filtering-bug
 ├── pom.xml
 ├── readme.txt
 └── src
 └── main
 └── filtered-resources
 └── etc
 └── filtering.bug.cfg
 {code}
 The filtering.bug.cfg file should be filtered with maven resource plugin. I 
 am expecting that the filtered file will get included in the karaf 
 distribution. I can see that target/classes/etc/filtering.bug.cfg actually 
 has the correct content but the karaf/etc/filtering.bug.cfg still has the 
 maven variables.
 I'll upload the sample project as well.



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