[jira] [Commented] (KARAF-6608) Add vaadin example

[Markus Rathgeb (Jira)]

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

Markus Rathgeb commented on KARAF-6608:
---

Hi Julian,

I am not really using Vaadin but I tried to get it running in an OSGi 
environment (the starter application).

I used Vaddin 14.1.5 and Flow 2.1.4.

For the simple demo I don't need to wrap any of the used bundled to get them 
running into an OSGi runtime (they already contains the respective manifest 
entries).

I could create a Karaf feature if desired.

Would it make sense or is there an important point why you stick at Vaadin 13?

> Add vaadin example
> --
>
> Key: KARAF-6608
> URL: https://issues.apache.org/jira/browse/KARAF-6608
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.3.0, 4.2.9
>
>




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

[jira] [Commented] (KARAF-6536) StackOverflowError in karaf-maven-plugin:verify when referencing feature which uses version ranges on Windows

[Markus Rathgeb (Jira)]

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

Markus Rathgeb commented on KARAF-6536:
---

My colleagues working on Windows machines run into the same problem while it 
(feature verification / custom distribution build) is working on my and other 
Linux machines.

> StackOverflowError in karaf-maven-plugin:verify when referencing feature 
> which uses version ranges on Windows
> -
>
> Key: KARAF-6536
> URL: https://issues.apache.org/jira/browse/KARAF-6536
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf
>Affects Versions: 4.2.7
>Reporter: Donnie McMahan
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>  Labels: windows
> Fix For: 4.3.0, 4.2.9
>
> Attachments: test-features.zip
>
>
> When running karaf-maven-plugin:verify on a feature which references the 
> aries-jax-rs feature, I'm getting a StackOverflowException:
> {code:java}
> Exception in thread "main" java.lang.StackOverflowError
>   at org.osgi.framework.Version.toString(Version.java:308)
>   at 
> org.apache.felix.utils.resource.SimpleFilter.convert(SimpleFilter.java:532)
>   at 
> org.apache.felix.utils.resource.RequirementImpl.getFilter(RequirementImpl.java:133)
>   at 
> org.apache.felix.utils.resource.RequirementImpl.(RequirementImpl.java:77)
>   at 
> org.apache.felix.utils.resource.RequirementImpl.(RequirementImpl.java:44)
>   at 
> org.apache.karaf.features.internal.resolver.ResourceUtils.addIdentityRequirement(ResourceUtils.java:127)
>   at 
> org.apache.karaf.features.internal.resolver.ResourceUtils.addIdentityRequirement(ResourceUtils.java:107)
>   at 
> org.apache.karaf.features.internal.resolver.ResourceUtils.addIdentityRequirement(ResourceUtils.java:99)
>   at 
> org.apache.karaf.features.internal.region.Subsystem.requireFeature(Subsystem.java:284)
>   at 
> org.apache.karaf.features.internal.region.Subsystem.doBuild(Subsystem.java:350)
>   at 
> org.apache.karaf.features.internal.region.Subsystem.build(Subsystem.java:332)
>   at 
> org.apache.karaf.features.internal.region.Subsystem.doBuild(Subsystem.java:390)
>   at 
> org.apache.karaf.features.internal.region.Subsystem.build(Subsystem.java:332)
>   at 
> org.apache.karaf.features.internal.region.Subsystem.doBuild(Subsystem.java:390)
>   at 
> org.apache.karaf.features.internal.region.Subsystem.build(Subsystem.java:332)
> ...
> {code}
> The issue seems to be related to the use of version ranges in the 
> aries-jax-rs feature:
> {code:xml|title=https://github.com/apache/aries-jax-rs-whiteboard/blob/org.apache.aries.jax.rs-1.0.6/jax-rs.features/src/main/feature/feature.xml}
> ...
> mvn:org.apache.karaf.features/standard/[4,5)/xml/features
> ...
> {code}
> I've attached a simple project which illustrates the issue. The verify goal 
> completes successfully using the "norange" profile but fails when using the 
> "range" profile.
> Is there a workaround for this?
> Thanks in advance!



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

[jira] [Commented] (KARAF-6355) improve usage for "log collector" + "mail alerter" usecases

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-6355:
---

For me a usecase would be, create an alert / sent email for:
 * log message level is WARN or ERROR
 * log message contains the word (case insensitive): stacktrace
 * log message contains the word (case insensitive): exception

and as the log message properties already contain the fields loc.class, 
loc.method, loc.line, I would like to be able to filter special log message 
that should not be alerted fore (so, the above list is a logic or and the loc 
properties would be used for an exclusion).

> improve usage for "log collector" + "mail alerter" usecases
> ---
>
> Key: KARAF-6355
> URL: https://issues.apache.org/jira/browse/KARAF-6355
> Project: Karaf
>  Issue Type: Bug
>  Components: decanter
>Affects Versions: decanter-2.2.0
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: decanter-2.3.0
>
>
> If you would like to be informed per mail about special log events (e.g. log 
> level warn) the current implementation does not work as (perhaps) expected.
> Assume you would like to be informed about every log message of level WARN.
> The current implementation will notify you about the first log message of 
> level WARN and the next alert that is triggered is for a log message not 
> using the WARN level.
> I would like to be informed about every WARN log message and not about any 
> other (so not loosing multiple WARN messages that are followed immediately 
> and not informed about a log message that is not WARN).
> Another improvement would about the combination of multiple patterns.
> E.g. keep me informed about
> type = log
> priority = WARN | ERROR
> not ( loc.class = Foo.class & loc.method = magic)
>  
> Perhaps we could reuse 
> [https://osgi.org/javadoc/r2/org/osgi/framework/Filter.html]
> log.warn.filter = 
> "(&((|(priority=WARN)(priority=ERROR))(loc.class=Foo.class)(loc.method=magic)))"
> (do not assume the filter above is correct)
>  
> Perhaps we could already reuse the current implementation and its match 
> method.
> Just need to think about substring matching...



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

[jira] [Created] (KARAF-6355) improve usage for "log collector" + "mail alerter" usecases

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-6355:
-

 Summary: improve usage for "log collector" + "mail alerter" 
usecases
 Key: KARAF-6355
 URL: https://issues.apache.org/jira/browse/KARAF-6355
 Project: Karaf
  Issue Type: Bug
  Components: decanter
Affects Versions: decanter-2.2.0
Reporter: Markus Rathgeb


If you would like to be informed per mail about special log events (e.g. log 
level warn) the current implementation does not work as (perhaps) expected.

Assume you would like to be informed about every log message of level WARN.

The current implementation will notify you about the first log message of level 
WARN and the next alert that is triggered is for a log message not using the 
WARN level.

I would like to be informed about every WARN log message and not about any 
other (so not loosing multiple WARN messages that are followed immediately and 
not informed about a log message that is not WARN).

Another improvement would about the combination of multiple patterns.

E.g. keep me informed about

type = log

priority = WARN | ERROR

not ( loc.class = Foo.class & loc.method = magic)

 

Perhaps we could reuse 
[https://osgi.org/javadoc/r2/org/osgi/framework/Filter.html]

log.warn.filter = 
"(&((|(priority=WARN)(priority=ERROR))(loc.class=Foo.class)(loc.method=magic)))"

(do not assume the filter above is correct)

 

Perhaps we could already reuse the current implementation and its match method.

Just need to think about substring matching...



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

[jira] [Commented] (KARAF-5376) Processor mechanism for feature definitions (a.k.a. "better overrides")

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-5376:
---

{{Is there an official documentation about the syntax and options of 
_org.apache.karaf.features.xml_?}}

> Processor mechanism for feature definitions (a.k.a. "better overrides")
> ---
>
> Key: KARAF-5376
> URL: https://issues.apache.org/jira/browse/KARAF-5376
> Project: Karaf
>  Issue Type: Proposal
>  Components: karaf
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 4.2.0.M2
>
>
> It'd be good to have a mechanism that could transform/enhance/process feature 
> definitions after reading them from original feature XML descriptors and 
> before passing them to Karaf features deployer.
> Current overrides mechanism could be generalized beyond simple version change 
> for {{/}} URIs.



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

[jira] [Created] (KARAF-5701) feature installation: Crash and ResolutionException

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-5701:
-

 Summary: feature installation: Crash and ResolutionException
 Key: KARAF-5701
 URL: https://issues.apache.org/jira/browse/KARAF-5701
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Affects Versions: 4.2.0
Reporter: Markus Rathgeb


It seems that the feature "pax-jetty-http2" does not work as expected or 
perhaps that feature identify a regression.

Start with a fresh working copy:
{noformat}
rm -rf apache-karaf-4.2.0
tar xzf apache-karaf-4.2.0.tar.gz
{noformat}

Start Karaf:
{noformat}
apache-karaf-4.2.0/bin/karaf
{noformat}


h2. Reproduce ResolutionException

Install feature:
{noformat}
feature:install pax-jetty-http2
{noformat}

Error message:
{noformat}
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity;
osgi.identity=pax-jetty-http2; type=karaf.feature;
version="[7.0.0,7.0.0]";
filter:="(&(osgi.identity=pax-jetty-http2)(type=karaf.feature)(version>=7.0.0)(version<=7.0.0))"
[caused by: Unable to resolve pax-jetty-http2/7.0.0: missing
requirement [pax-jetty-http2/7.0.0] osgi.identity;
osgi.identity=org.eclipse.jetty.http2.common; type=osgi.bundle;
version="[9.4.6.v20170531,9.4.6.v20170531]"; resolution:=mandatory
[caused by: Unable to resolve
org.eclipse.jetty.http2.common/9.4.6.v20170531: missing requirement
[org.eclipse.jetty.http2.common/9.4.6.v20170531] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.eclipse.jetty.http2.hpack)(version>=9.4.6)(!(version>=9.4.7)))"
[caused by: Unable to resolve
org.eclipse.jetty.http2.hpack/9.4.6.v20170531: missing requirement
[org.eclipse.jetty.http2.hpack/9.4.6.v20170531] osgi.extender;
filter:="(osgi.extender=osgi.serviceloader.registrar)" [caused by:
Unable to resolve org.apache.aries.spifly.dynamic.bundle/1.0.10:
missing requirement [org.apache.aries.spifly.dynamic.bundle/1.0.10]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.objectweb.asm)(version>=5.0.0)(!(version>=7.0.0)))"
at 
org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:391)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:377)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:331)
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:248)
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Error executing command: Unable to resolve root: missing requirement
[root] osgi.identity; osgi.identity=pax-jetty-http2;
type=karaf.feature; version="[7.0.0,7.0.0]";
filter:="(&(osgi.identity=pax-jetty-http2)(type=karaf.feature)(version>=7.0.0)(version<=7.0.0))"
[caused by: Unable to resolve pax-jetty-http2/7.0.0: missing
requirement [pax-jetty-http2/7.0.0] osgi.identity;
osgi.identity=org.eclipse.jetty.http2.common; type=osgi.bundle;
version="[9.4.6.v20170531,9.4.6.v20170531]"; resolution:=mandatory
[caused by: Unable to resolve
org.eclipse.jetty.http2.common/9.4.6.v20170531: missing requirement
[org.eclipse.jetty.http2.common/9.4.6.v20170531] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.eclipse.jetty.http2.hpack)(version>=9.4.6)(!(version>=9.4.7)))"
[caused by: Unable to resolve
org.eclipse.jetty.http2.hpack/9.4.6.v20170531: missing requirement
[org.eclipse.jetty.http2.hpack/9.4.6.v20170531] osgi.extender;
filter:="(osgi.extender=osgi.serviceloader.registrar)" [caused by:
Unable to resolve org.apache.aries.spifly.dynamic.bundle/1.0.10:
missing requirement [org.apache.aries.spifly.dynamic.bundle/1.0.10]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.objectweb.asm)(version>=5.0.0)(!(version>=7.0.0)))"
{noformat}


h2. Reproduce Crash

Install whiteboard feature
{noformat}
karaf@root()> feature:install pax-http-whiteboard
{noformat}

Install http2 feature
{noformat}
karaf@root()> feature:install pax-jetty-http2
{noformat}

Crash of Karaf (KAraf is terminated after the message):
{noformat}
java.lang.IllegalStateException: Invalid BundleContext.
at 
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)
at 
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:146)
at 
org.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundle0(BundleIdBasedRegion.java:117)
at 
org.ecli

[jira] [Commented] (KARAF-5397) Remove org.apache.karaf.shell config from ssh feature

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-5397:
---

Could this be related to https://issues.apache.org/jira/browse/KARAF-5335

> Remove org.apache.karaf.shell config from ssh feature
> -
>
> Key: KARAF-5397
> URL: https://issues.apache.org/jira/browse/KARAF-5397
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.1.2
>Reporter: Benjamin Graf
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 4.1.3, 4.0.11
>
>
> Feature ssh still sets config:
> 
>  sshPort=8101
>  sshHost=0.0.0.0
>  sshRealm=karaf
>  hostKey=${karaf.etc}/host.key
> 
> The config for "org.apache.karaf.shell.cfg" is set twice in the standard 
> feature file causing a mess up in the result (distribution). It has been 
> removed from trunk in KARAF-5074 yet.



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

[jira] [Updated] (KARAF-5335) Karaf assembly property edit not working reliable

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-5335:
--
Summary: Karaf assembly property edit not working reliable  (was: Karaf 
assembly prpperty edit not working reliable)

> Karaf assembly property edit not working reliable
> -
>
> Key: KARAF-5335
> URL: https://issues.apache.org/jira/browse/KARAF-5335
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-tooling
>Affects Versions: 4.1.2
>Reporter: Markus Rathgeb
>
> In a custom distribution we could use the file 
> "src/main/karaf/assembly-property-edits.xml" to edit porperty files on 
> assembly stage.
> This does work for some files but don't for other ones - at least if we look 
> at the final result.
> Perhaps all files are edited and some are overwritten again, I don't know -- 
> but it seems so.
> So, perhaps it is not only about "karaf-tooling" but also other components 
> that overwrite existing files.
> I created a simple custom distribution project to reproduce the error:
> https://github.com/maggu2810/karaf-demo/tree/master/assembly-property-edits-unclear
> There is a "src/main/karaf/assembly-property-edits.xml" that want to ensure 
> that there are one property available in two files.
> * test=test in system.properties
> * sshHost=127.0.0.1 in org.apache.karaf.shell.cfg
> The file looks like
> {noformat}
> 
> http://karaf.apache.org/tools/property-edits/1.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://karaf.apache.org/tools/property-edits/1.0.0 
> http://karaf.apache.org/xsd/property-edits-1.0.0.xsd";>
>   
> 
>   system.properties
>   put
>   test
>   test
> 
> 
>   org.apache.karaf.shell.cfg
>   put
>   sshHost
>   127.0.0.1
> 
>   
> 
> {noformat}
> The first one works as expected:
> {noformat}
> $ grep test= ./target/assembly/etc/system.properties 
> test=test
> {noformat}
> The second one doesn't
> {noformat}
> grep sshHost ./target/assembly/etc/org.apache.karaf.shell.cfg
> sshHost=0.0.0.0
> {noformat}
> Changes on e.g. org.ops4j.pax.web.cfg are also overwritten again.
> I assume (but don't know) the feature installation on assembly stage 
> overwrites existing configuration files.
> Is this the expected behavior?
> Would it be possible to move the property edit after that stage so files that 
> are added by the feature installation are edited?



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

[jira] [Created] (KARAF-5335) Karaf assembly prpperty edit not working reliable

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-5335:
-

 Summary: Karaf assembly prpperty edit not working reliable
 Key: KARAF-5335
 URL: https://issues.apache.org/jira/browse/KARAF-5335
 Project: Karaf
  Issue Type: Bug
  Components: karaf-tooling
Affects Versions: 4.1.2
Reporter: Markus Rathgeb


In a custom distribution we could use the file 
"src/main/karaf/assembly-property-edits.xml" to edit porperty files on assembly 
stage.

This does work for some files but don't for other ones - at least if we look at 
the final result.
Perhaps all files are edited and some are overwritten again, I don't know -- 
but it seems so.

So, perhaps it is not only about "karaf-tooling" but also other components that 
overwrite existing files.

I created a simple custom distribution project to reproduce the error:
https://github.com/maggu2810/karaf-demo/tree/master/assembly-property-edits-unclear

There is a "src/main/karaf/assembly-property-edits.xml" that want to ensure 
that there are one property available in two files.

* test=test in system.properties
* sshHost=127.0.0.1 in org.apache.karaf.shell.cfg

The file looks like
{noformat}

http://karaf.apache.org/tools/property-edits/1.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://karaf.apache.org/tools/property-edits/1.0.0 
http://karaf.apache.org/xsd/property-edits-1.0.0.xsd";>
  


  system.properties
  put
  test
  test



  org.apache.karaf.shell.cfg
  put
  sshHost
  127.0.0.1


  

{noformat}

The first one works as expected:
{noformat}
$ grep test= ./target/assembly/etc/system.properties 
test=test
{noformat}

The second one doesn't
{noformat}
grep sshHost ./target/assembly/etc/org.apache.karaf.shell.cfg
sshHost=0.0.0.0
{noformat}

Changes on e.g. org.ops4j.pax.web.cfg are also overwritten again.

I assume (but don't know) the feature installation on assembly stage overwrites 
existing configuration files.
Is this the expected behavior?

Would it be possible to move the property edit after that stage so files that 
are added by the feature installation are edited?



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

[jira] [Updated] (KARAF-5091) log:get does not show correct level

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-5091:
--
Description: 
The log:get command shows the "logger" as "Logger" and as "Level".
The correct "Level" is not shown anymore.

Unpack the standard Karaf 4.1.1 distribution.

{noformat}
karaf@root()> log:get
Logger  │ Level
┼
ROOT│ INFO
org.apache.aries.spifly │ org.apache.aries.spifly
org.apache.karaf.jaas.modules.audit │ org.apache.karaf.jaas.modules.audit
{noformat}

Also an entry added with "log:set" is not shown correctly:

{noformat}
karaf@root()> log:set ERROR org.jupnp
karaf@root()> log:get org.jupnp
org.jupnp
{noformat}

  was:
The log:get command shows the "logger" as "Logger" and as "Level".
The correct "Level" is not shown anymore.

Unpack the standard Karaf 4.1.1 distribution.

{noformat}
karaf@root()> log:get   


  Logger
  │ Level
┼
ROOT│ INFO
org.apache.aries.spifly │ org.apache.aries.spifly
org.apache.karaf.jaas.modules.audit │ org.apache.karaf.jaas.modules.audit
{noformat}

Also an entry added with "log:set" is not shown correctly:

{noformat}
karaf@root()> log:set ERROR org.jupnp   


  
karaf@root()> log:get org.jupnp 


  org.jupnp
{noformat}


> log:get does not show correct level
> ---
>
> Key: KARAF-5091
> URL: https://issues.apache.org/jira/browse/KARAF-5091
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 4.1.1
> Environment: Tested with the standard Karaf 4.1.1 distribution.
>Reporter: Markus Rathgeb
>
> The log:get command shows the "logger" as "Logger" and as "Level".
> The correct "Level" is not shown anymore.
> Unpack the standard Karaf 4.1.1 distribution.
> {noformat}
> karaf@root()> log:get
> Logger  │ Level
> ┼
> ROOT│ INFO
> org.apache.aries.spifly │ org.apache.aries.spifly
> org.apache.karaf.jaas.modules.audit │ org.apache.karaf.jaas.modules.audit
> {noformat}
> Also an entry added with "log:set" is not shown correctly:
> {noformat}
> karaf@root()> log:set ERROR org.jupnp
> karaf@root()> log:get org.jupnp
> org.jupnp
> {noformat}



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

[jira] [Created] (KARAF-5091) log:get does not show correct level

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-5091:
-

 Summary: log:get does not show correct level
 Key: KARAF-5091
 URL: https://issues.apache.org/jira/browse/KARAF-5091
 Project: Karaf
  Issue Type: Bug
  Components: karaf-core
Affects Versions: 4.1.1
 Environment: Tested with the standard Karaf 4.1.1 distribution.
Reporter: Markus Rathgeb


The log:get command shows the "logger" as "Logger" and as "Level".
The correct "Level" is not shown anymore.

Unpack the standard Karaf 4.1.1 distribution.

{noformat}
karaf@root()> log:get   


  Logger
  │ Level
┼
ROOT│ INFO
org.apache.aries.spifly │ org.apache.aries.spifly
org.apache.karaf.jaas.modules.audit │ org.apache.karaf.jaas.modules.audit
{noformat}

Also an entry added with "log:set" is not shown correctly:

{noformat}
karaf@root()> log:set ERROR org.jupnp   


  
karaf@root()> log:get org.jupnp 


  org.jupnp
{noformat}



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

[jira] [Commented] (KARAF-4990) Exception caused by Jetty Websocket server

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4990:
---

The Pax Web issue has been resolved in master 
(https://ops4j1.jira.com/browse/PAXWEB-1065).

> Exception caused by Jetty Websocket server
> --
>
> Key: KARAF-4990
> URL: https://issues.apache.org/jira/browse/KARAF-4990
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.1.0
>Reporter: Markus Rathgeb
>
> Hi,
> after I changed some stuff to use the recent Karaf 4.1.0 I realized an error 
> in my log (message is attached below).
> The error has been cased by a bug in the "org.eclipse.jetty.websocket.server" 
> bundle (SPI without no-arg
> constructor).
> The issue has already been reported upstream 
> (https://github.com/eclipse/jetty.project/issues/1276).
> The Pax Web version Karaf 4.1.0 is using 6.0.2 uses jetty-9.3.15.v20161220 
> which contains that bug.
> The issue has been reported for Pax Web, too 
> (https://ops4j1.jira.com/browse/PAXWEB-1065).
> It has been resolved in the master branch and in the new 9.3 release
> "9.3.16.v20170120" 
> (https://github.com/eclipse/jetty.project/commit/a205fb3aae65f9cd6721def40bc5956b04bfa9e4)
>  already.
> {noformat}
> 2017-02-16 20:13:16,994 | ERROR | lixDispatchQueue | publisher
>| 12 - com.eclipsesource.jaxrs.publisher -
> 5.3.1.201602281253 | FrameworkEvent ERROR -
> com.eclipsesource.jaxrs.publisher
> org.osgi.framework.ServiceException: Service factory exception: Unable
> to instantiate class class
> org.eclipse.jetty.websocket.server.WebSocketServerFactory Does it have
> a public no-arg constructor?
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352)
> [?:?]
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
> [?:?]
> at 
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344)
> [?:?]
> at org.apache.felix.framework.Felix.getService(Felix.java:3699) [?:?]
> at 
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)
> [?:?]
> at 
> com.eclipsesource.jaxrs.publisher.internal.ResourceTracker.addingService(ResourceTracker.java:39)
> [12:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> [?:?]
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> [?:?]
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> [?:?]
> at 
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> [?:?]
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318) 
> [?:?]
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261) 
> [?:?]
> at 
> com.eclipsesource.jaxrs.publisher.internal.Activator.openAllServiceTracker(Activator.java:91)
> [12:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
> at 
> com.eclipsesource.jaxrs.publisher.internal.Activator.start(Activator.java:55)
> [12:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> [?:?]
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226) [?:?]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) [?:?]
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
> [?:?]
> at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> [?:?]
> at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: java.lang.RuntimeException: Unable to instantiate class
> class org.eclipse.jetty.websocket.server.WebSocketServerFactory Does
> it have a public no-arg constructor?
> at 
> org.apache.aries.spifly.ProviderServiceFactory.getService(ProviderServiceFactory.java:37)
> ~[?:?]
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
> ~[?:?]
> ... 19 more
> Caused by: java.lang.InstantiationException:
> org.eclipse.jetty.websocket.server.WebSocketServerFactory
> at java.lang.Class.newInstance(Class.java:427) ~[?:?]
> at 
> org.apache.aries.spifly.ProviderServiceFactory.getService(ProviderServiceFactory.java:35)
> ~[?:?]
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
> ~[?:?]
> ... 19 more
> Caused by: java.lang.NoSuchMethodException:
> org.eclipse.jetty.websocket.server.WebSocketServerFactory.()
> at java.lang.Class.getConstructor0(Class.

[jira] [Created] (KARAF-4990) Exception caused by Jetty Websocket server

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4990:
-

 Summary: Exception caused by Jetty Websocket server
 Key: KARAF-4990
 URL: https://issues.apache.org/jira/browse/KARAF-4990
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Affects Versions: 4.1.0
Reporter: Markus Rathgeb


Hi,

after I changed some stuff to use the recent Karaf 4.1.0 I realized an error in 
my log (message is attached below).

The error has been cased by a bug in the "org.eclipse.jetty.websocket.server" 
bundle (SPI without no-arg
constructor).
The issue has already been reported upstream 
(https://github.com/eclipse/jetty.project/issues/1276).

The Pax Web version Karaf 4.1.0 is using 6.0.2 uses jetty-9.3.15.v20161220 
which contains that bug.
The issue has been reported for Pax Web, too 
(https://ops4j1.jira.com/browse/PAXWEB-1065).

It has been resolved in the master branch and in the new 9.3 release
"9.3.16.v20170120" 
(https://github.com/eclipse/jetty.project/commit/a205fb3aae65f9cd6721def40bc5956b04bfa9e4)
 already.

{noformat}
2017-02-16 20:13:16,994 | ERROR | lixDispatchQueue | publisher
   | 12 - com.eclipsesource.jaxrs.publisher -
5.3.1.201602281253 | FrameworkEvent ERROR -
com.eclipsesource.jaxrs.publisher
org.osgi.framework.ServiceException: Service factory exception: Unable
to instantiate class class
org.eclipse.jetty.websocket.server.WebSocketServerFactory Does it have
a public no-arg constructor?
at 
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352)
[?:?]
at 
org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
[?:?]
at 
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:344)
[?:?]
at org.apache.felix.framework.Felix.getService(Felix.java:3699) [?:?]
at 
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)
[?:?]
at 
com.eclipsesource.jaxrs.publisher.internal.ResourceTracker.addingService(ResourceTracker.java:39)
[12:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
[?:?]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
[?:?]
at 
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
[?:?]
at 
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
[?:?]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318) [?:?]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261) [?:?]
at 
com.eclipsesource.jaxrs.publisher.internal.Activator.openAllServiceTracker(Activator.java:91)
[12:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
at 
com.eclipsesource.jaxrs.publisher.internal.Activator.start(Activator.java:55)
[12:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
[?:?]
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226) [?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) [?:?]
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
[?:?]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
[?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
Caused by: java.lang.RuntimeException: Unable to instantiate class
class org.eclipse.jetty.websocket.server.WebSocketServerFactory Does
it have a public no-arg constructor?
at 
org.apache.aries.spifly.ProviderServiceFactory.getService(ProviderServiceFactory.java:37)
~[?:?]
at 
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
~[?:?]
... 19 more
Caused by: java.lang.InstantiationException:
org.eclipse.jetty.websocket.server.WebSocketServerFactory
at java.lang.Class.newInstance(Class.java:427) ~[?:?]
at 
org.apache.aries.spifly.ProviderServiceFactory.getService(ProviderServiceFactory.java:35)
~[?:?]
at 
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
~[?:?]
... 19 more
Caused by: java.lang.NoSuchMethodException:
org.eclipse.jetty.websocket.server.WebSocketServerFactory.()
at java.lang.Class.getConstructor0(Class.java:3082) ~[?:?]
at java.lang.Class.newInstance(Class.java:412) ~[?:?]
at 
org.apache.aries.spifly.ProviderServiceFactory.getService(ProviderServiceFactory.java:35)
~[?:?]
at 
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
~[?:?]
... 19 more
{noformat}



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

[jira] [Commented] (KARAF-4980) OSGi framework capabilities: add all services

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4980:
---

Hm, has you read my comment above completely:
https://issues.apache.org/jira/browse/KARAF-4980?focusedCommentId=15855565&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855565

As you added now all Equinox capability didn't you see all of them twice?

> OSGi framework capabilities: add all services
> -
>
> Key: KARAF-4980
> URL: https://issues.apache.org/jira/browse/KARAF-4980
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-core
>Affects Versions: 4.1.0
>Reporter: Markus Rathgeb
>Assignee: Guillaume Nodet
> Fix For: 4.1.1
>
>
> The services provided by the Felix and the Equinox framework differs and 
> should be provided by the system capabilities.
> I used service:list to find the services that are provided by Felix and the 
> ones that are provided by Equinox.
> I would like to propagate this change to the config.properties (I will create 
> a PR if you agree):
> {noformat}
> org.osgi.framework.system.capabilities= \
>  ${eecap-${java.specification.version}}, \
>  ${${karaf.framework}-capabilities}
> felix-capabilities= \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel
> equinox-capabilities= \
>  osgi.service;effective:=active;objectClass=java.lang.ClassLoader, \
>  
> osgi.service;effective:=active;objectClass=javax.xml.parsers.DocumentBuilderFactory,
>  \
>  
> osgi.service;effective:=active;objectClass=javax.xml.parsers.SAXParserFactory,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogReaderService,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogService,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.framework.log.FrameworkLog,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.datalocation.Location,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptions,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptionsListener,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.environment.EnvironmentInfo,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.localization.BundleLocalization,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.security.TrustEngine,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.urlconversion.URLConverter,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.signedcontent.SignedContentFactory,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.condpermadmin.ConditionalPermissionAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.log.LogReaderService,
>  \
>  osgi.service;effective:=active;objectClass=org.osgi.service.log.LogService, \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.permissionadmin.PermissionAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel
> {noformat}
> The currently configuration also contains:
> {noformat}
> osgi.service;effective:=active;objectClass=org.osgi.service.url.URLHandlers
> {noformat}
> but this service is not listed by service:list.
> Is it still valid?



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

[jira] [Commented] (KARAF-4980) OSGi framework capabilities: add all services

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4980:
---

I already asked some time on the mailing list, because AFAIK 
"effective:=active" is only used for "Require-Capability"
See: 
http://karaf.922171.n3.nabble.com/What-does-effective-active-mean-tp4047770p4047787.html

Also this comment I found on some vogella site seems to be informative that it 
is only necessary for "Require-Capability" and not for "Provide-Capability"
"You should notice the effective:=active directive here. It is necessary so the 
OSGi Framework will resolve the bundle without checking if another bundle 
provides that capability. Without that directive or setting effective:=resolve 
the resolution of the bundle would be prevented."

I updated the PR:
* I removed "effective:=active"
* I removed all services that are already provided (in the bundle:headers 0 
list)
* I added all capabilities where properties are missing
* I added the missing capabilities

> OSGi framework capabilities: add all services
> -
>
> Key: KARAF-4980
> URL: https://issues.apache.org/jira/browse/KARAF-4980
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-core
>Affects Versions: 4.1.0
>Reporter: Markus Rathgeb
>Assignee: Guillaume Nodet
>
> The services provided by the Felix and the Equinox framework differs and 
> should be provided by the system capabilities.
> I used service:list to find the services that are provided by Felix and the 
> ones that are provided by Equinox.
> I would like to propagate this change to the config.properties (I will create 
> a PR if you agree):
> {noformat}
> org.osgi.framework.system.capabilities= \
>  ${eecap-${java.specification.version}}, \
>  ${${karaf.framework}-capabilities}
> felix-capabilities= \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel
> equinox-capabilities= \
>  osgi.service;effective:=active;objectClass=java.lang.ClassLoader, \
>  
> osgi.service;effective:=active;objectClass=javax.xml.parsers.DocumentBuilderFactory,
>  \
>  
> osgi.service;effective:=active;objectClass=javax.xml.parsers.SAXParserFactory,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogReaderService,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogService,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.framework.log.FrameworkLog,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.datalocation.Location,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptions,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptionsListener,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.environment.EnvironmentInfo,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.localization.BundleLocalization,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.security.TrustEngine,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.urlconversion.URLConverter,
>  \
>  
> osgi.service;effective:=active;objectClass=org.eclipse.osgi.signedcontent.SignedContentFactory,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.condpermadmin.ConditionalPermissionAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.log.LogReaderService,
>  \
>  osgi.service;effective:=active;objectClass=org.osgi.service.log.LogService, \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.permissionadmin.PermissionAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel
> {noformat}
> The currently configuration also contains:
> {noformat}
> osgi.service;effective:=active;objectClass=org.osgi.service.url.URLHandlers
> {noformat}
> but this service is not listed by service:list.
> Is it still valid?



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

[jira] [Commented] (KARAF-4980) OSGi framework capabilities: add all services

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4980:
---

{quote}
It would be nice to add the karaf service
{quote}

Done (I was not sure if this should be added to the system capabilities).

{quote}
Anyway, I came up with this small script that can be run in the console:
{quote}

Really great! It seems it is time to read about Karaf shell scripting.

I will update the PR soon.
Thanks for your support.

I realized (sorry, don't know why this has not seend before) now using the most 
Karaf 4.1.0 distribution from Maven Central that if the Equinox framework is 
used the most services are already part of "Provide-Capability" in the output 
of "bundle:headers 0".

{noformat}
osgi.service;objectClass:List="org.osgi.service.log.LogReaderService, 
org.eclipse.equinox.log.ExtendedLogReaderService",
osgi.service;objectClass:List="org.osgi.service.log.LogService, 
org.eclipse.equinox.log.ExtendedLogService",
osgi.service;objectClass:List=org.eclipse.osgi.framework.log.FrameworkLog,
osgi.service;objectClass:List=org.eclipse.osgi.service.datalocation.Location;type=osgi.user.area,
osgi.service;objectClass:List=org.eclipse.osgi.service.datalocation.Location;type=osgi.instance.area,
osgi.service;objectClass:List=org.eclipse.osgi.service.datalocation.Location;type=osgi.configuration.area,
osgi.service;objectClass:List=org.eclipse.osgi.service.datalocation.Location;type=osgi.install.area,
osgi.service;objectClass:List=org.eclipse.osgi.service.datalocation.Location;type=eclipse.home.location,
osgi.service;objectClass:List=org.eclipse.osgi.service.environment.EnvironmentInfo,
osgi.service;objectClass:List=org.osgi.service.packageadmin.PackageAdmin,
osgi.service;objectClass:List=org.osgi.service.startlevel.StartLevel,
osgi.service;objectClass:List=org.osgi.service.permissionadmin.PermissionAdmin,
osgi.service;objectClass:List=org.osgi.service.condpermadmin.ConditionalPermissionAdmin,
osgi.service;objectClass:List=org.osgi.service.resolver.Resolver,
osgi.service;objectClass:List=org.eclipse.osgi.service.debug.DebugOptions,
osgi.service;objectClass:List=org.eclipse.osgi.service.urlconversion.URLConverter,
osgi.service;objectClass:List=org.eclipse.osgi.service.localization.BundleLocalization,
osgi.service;objectClass:List=org.eclipse.osgi.service.security.TrustEngine,
osgi.service;objectClass:List=org.eclipse.osgi.signedcontent.SignedContentFactory,
{noformat}

Questions / remarks:
* adding the whole capabilities to the config.properties will result into two 
entries (using bundle:headers 0) -- at least a little bit different, see below
* "effective:=active" is missing on the current output, so adding it to 
config.properties will bring in the currently one and new ones with the 
effective property (can you point me to some details about the effective flag 
-- IIRC it is also used because it is ignored if set to active in some cases)
* if there are the two capabilities, the first without the performance property 
and the second with the property, should we keep both?
** 
"osgi.service;effective:=active;objectClass=org.eclipse.osgi.framework.log.FrameworkLog"
** 
"osgi.service;effective:=active;objectClass=org.eclipse.osgi.framework.log.FrameworkLog;performance=true"
* the current list misses some properties for some services
* the current list misses some services at all
** java.lang.ClassLoader;equinox.classloader.type=contextClassLoader
** javax.xml.parsers.DocumentBuilderFactory
** javax.xml.parsers.SAXParserFactory


> OSGi framework capabilities: add all services
> -
>
> Key: KARAF-4980
> URL: https://issues.apache.org/jira/browse/KARAF-4980
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-core
>Affects Versions: 4.1.0
>Reporter: Markus Rathgeb
>Assignee: Guillaume Nodet
>
> The services provided by the Felix and the Equinox framework differs and 
> should be provided by the system capabilities.
> I used service:list to find the services that are provided by Felix and the 
> ones that are provided by Equinox.
> I would like to propagate this change to the config.properties (I will create 
> a PR if you agree):
> {noformat}
> org.osgi.framework.system.capabilities= \
>  ${eecap-${java.specification.version}}, \
>  ${${karaf.framework}-capabilities}
> felix-capabilities= \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver,
>  \
>  
> osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel
> equinox-capabilities= \
>  osgi.service;effective:=active;objectClass=java.lang.ClassLoader, \
>  
> osgi.service;effective:=active;objectClass

[jira] [Updated] (KARAF-4980) OSGi framework capabilities: add all services

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-4980:
--
Description: 
The services provided by the Felix and the Equinox framework differs and should 
be provided by the system capabilities.

I used service:list to find the services that are provided by Felix and the 
ones that are provided by Equinox.

I would like to propagate this change to the config.properties (I will create a 
PR if you agree):
{noformat}
org.osgi.framework.system.capabilities= \
 ${eecap-${java.specification.version}}, \
 ${${karaf.framework}-capabilities}

felix-capabilities= \
 
osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
 \
 osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver, 
\
 
osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel

equinox-capabilities= \
 osgi.service;effective:=active;objectClass=java.lang.ClassLoader, \
 
osgi.service;effective:=active;objectClass=javax.xml.parsers.DocumentBuilderFactory,
 \
 osgi.service;effective:=active;objectClass=javax.xml.parsers.SAXParserFactory, 
\
 
osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogReaderService,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogService,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.framework.log.FrameworkLog,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.datalocation.Location,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptions,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptionsListener,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.environment.EnvironmentInfo,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.localization.BundleLocalization,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.security.TrustEngine,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.urlconversion.URLConverter,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.signedcontent.SignedContentFactory,
 \
 
osgi.service;effective:=active;objectClass=org.osgi.service.condpermadmin.ConditionalPermissionAdmin,
 \
 
osgi.service;effective:=active;objectClass=org.osgi.service.log.LogReaderService,
 \
 osgi.service;effective:=active;objectClass=org.osgi.service.log.LogService, \
 
osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
 \
 
osgi.service;effective:=active;objectClass=org.osgi.service.permissionadmin.PermissionAdmin,
 \
 osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver, 
\
 
osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel
{noformat}


The currently configuration also contains:
{noformat}
osgi.service;effective:=active;objectClass=org.osgi.service.url.URLHandlers
{noformat}
but this service is not listed by service:list.
Is it still valid?

  was:
The services provided by the Felix and the Equinox framework differs and should 
be provided by the system capabilities.

I used service:list to find the services that are provided by Felix and the 
ones that are provided by Equinox.

I would like to propagate this change to the config.properties (I will create a 
PR if you agree):
{{noformat}}
org.osgi.framework.system.capabilities= \
 ${eecap-${java.specification.version}}, \
 ${${karaf.framework}-capabilities}

felix-capabilities= \
 
osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
 \
 osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver, 
\
 
osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel

equinox-capabilities= \
 osgi.service;effective:=active;objectClass=java.lang.ClassLoader, \
 
osgi.service;effective:=active;objectClass=javax.xml.parsers.DocumentBuilderFactory,
 \
 osgi.service;effective:=active;objectClass=javax.xml.parsers.SAXParserFactory, 
\
 
osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogReaderService,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogService,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.framework.log.FrameworkLog,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.datalocation.Location,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptions,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptionsListener,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.environment.EnvironmentInfo,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.localization.BundleLocalization,
 \
 
osgi.service;effective:=active;

[jira] [Created] (KARAF-4980) OSGi framework capabilities: add all services

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4980:
-

 Summary: OSGi framework capabilities: add all services
 Key: KARAF-4980
 URL: https://issues.apache.org/jira/browse/KARAF-4980
 Project: Karaf
  Issue Type: Improvement
  Components: karaf-core
Affects Versions: 4.1.0
Reporter: Markus Rathgeb


The services provided by the Felix and the Equinox framework differs and should 
be provided by the system capabilities.

I used service:list to find the services that are provided by Felix and the 
ones that are provided by Equinox.

I would like to propagate this change to the config.properties (I will create a 
PR if you agree):
{{noformat}}
org.osgi.framework.system.capabilities= \
 ${eecap-${java.specification.version}}, \
 ${${karaf.framework}-capabilities}

felix-capabilities= \
 
osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
 \
 osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver, 
\
 
osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel

equinox-capabilities= \
 osgi.service;effective:=active;objectClass=java.lang.ClassLoader, \
 
osgi.service;effective:=active;objectClass=javax.xml.parsers.DocumentBuilderFactory,
 \
 osgi.service;effective:=active;objectClass=javax.xml.parsers.SAXParserFactory, 
\
 
osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogReaderService,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.equinox.log.ExtendedLogService,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.framework.log.FrameworkLog,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.datalocation.Location,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptions,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.debug.DebugOptionsListener,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.environment.EnvironmentInfo,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.localization.BundleLocalization,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.security.TrustEngine,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.service.urlconversion.URLConverter,
 \
 
osgi.service;effective:=active;objectClass=org.eclipse.osgi.signedcontent.SignedContentFactory,
 \
 
osgi.service;effective:=active;objectClass=org.osgi.service.condpermadmin.ConditionalPermissionAdmin,
 \
 
osgi.service;effective:=active;objectClass=org.osgi.service.log.LogReaderService,
 \
 osgi.service;effective:=active;objectClass=org.osgi.service.log.LogService, \
 
osgi.service;effective:=active;objectClass=org.osgi.service.packageadmin.PackageAdmin,
 \
 
osgi.service;effective:=active;objectClass=org.osgi.service.permissionadmin.PermissionAdmin,
 \
 osgi.service;effective:=active;objectClass=org.osgi.service.resolver.Resolver, 
\
 
osgi.service;effective:=active;objectClass=org.osgi.service.startlevel.StartLevel
{{noformat}}


The currently configuration also contains:
{{noformat}}
osgi.service;effective:=active;objectClass=org.osgi.service.url.URLHandlers
{{noformat}}
but this service is not listed by service:list.
Is it still valid?



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

[jira] [Commented] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4714:
---

Have you realized that my latest report already uses the most recent one 
(apache-karaf-4.0.8-20161014.054643-15.tar.gz)? ;)

> shell (so also ssh) not working anymore on ARM
> --
>
> Key: KARAF-4714
> URL: https://issues.apache.org/jira/browse/KARAF-4714
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-shell
>Affects Versions: 4.0.6
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
>Priority: Blocker
> Fix For: 4.1.0, 4.0.8
>
> Attachments: karaf.log.k405.txt, karaf.log.k406.txt
>
>
> The official Karaf 4.0.6 distribution (the archive 
> "apache-karaf-4.0.6.tar.gz" from your homepage) does not work correctly on 
> ARM systems.
> I unpacked and started the official distribution (bin/karaf).
> The log file shows this content:
> {noformat}
> 2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
> BootFeaturesInstaller| 8 - org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.apache.karaf.features.internal.util.MultiException: Error restarting 
> bundles
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.6]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
> Caused by: org.osgi.framework.BundleException: Activator start error
> in bundle org.apache.karaf.shell.core [43].
> at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.6]
> ... 6 more
> Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
> Reasons: [no jansi in java.library.path,
> /home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
> /home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
> cannot open shared object file: No such file or directory (Possible
> cause: can't load IA 32-bit .so on a ARM-bit platform)]
> at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
> at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
> at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
> at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
> at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
> at 
> org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
> at 
> org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
> at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_65]
> at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
> at 
> org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:112)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
> ... 11 more
> {noformat}



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

[jira] [Commented] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4714:
---

Thanks JBO,

I will test it if you ping me.
Just tested the next nightly build, it still fails.

{noformat}
$ tar xzf apache-karaf-4.0.8-20161014.054643-15.tar.gz
$ apache-karaf-4.0.8-SNAPSHOT/bin/karaf 
karaf: JAVA_HOME not set; results may vary
ERROR: Bundle org.apache.karaf.shell.core [43] Error starting 
mvn:org.apache.karaf.shell/org.apache.karaf.shell.core/4.0.8-SNAPSHOT 
(org.osgi.framework.BundleException: Activator start error in bundle 
org.apache.karaf.shell.core [43].)
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no jansi in 
java.library.path, 
/home/alarm/apache-karaf-4.0.8-SNAPSHOT/data/tmp/libjansi-32-3318861443599153555.so:
 
/home/alarm/apache-karaf-4.0.8-SNAPSHOT/data/tmp/libjansi-32-3318861443599153555.so:
 cannot open shared object file: No such file or directory (Possible cause: 
can't load IA 32-bit .so on a ARM-bit platform)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at 
org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
at 
org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:112)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2227)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2145)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
ERROR: Bundle org.apache.karaf.shell.core [43] Error starting/stopping bundle. 
(org.osgi.framework.BundleException: Activator start error in bundle 
org.apache.karaf.shell.core [43].)
java.lang.IllegalStateException: Thread Print Stream already set
at 
org.apache.felix.gogo.runtime.threadio.ThreadIOImpl.start(ThreadIOImpl.java:49)
at 
org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:63)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2227)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2145)
at org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1564)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:338)
at java.lang.Thread.run(Thread.java:745)
{noformat}

> shell (so also ssh) not working anymore on ARM
> --
>
> Key: KARAF-4714
> URL: https://issues.apache.org/jira/browse/KARAF-4714
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-shell
>Affects Versions: 4.0.6
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
>Priority: Blocker
> Fix For: 4.1.0, 4.0.8
>
> Attachments: karaf.log.k405.txt, karaf.log.k406.txt
>
>
> The official Karaf 4.0.6 distribution (the archive 
> "apache-karaf-4.0.6.tar.gz" from your homepage) does not work correctly on 
> ARM systems.
> I unpacked and started the official distribution (bin/karaf).
> The log file shows this content:
> {noformat}
> 2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
> BootFeaturesInstaller| 8 - org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.apache.karaf.features.internal.util.MultiException: Error restarting 
> bundles
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
>  

[jira] [Commented] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4714:
---

I cannot confirm that this issue is resolved.
I tested the most recent snapshot of the Apache Snapshot Repository.
I unapcked "apache-karaf-4.0.8-20161012.133451-14.tar.gz" and started bin/karaf 
on ARM (a RPi2B).

{noformat}
$ tar xzf apache-karaf-4.0.8-20161012.133451-14.tar.gz 
$ cd apache-karaf-4.0.8-SNAPSHOT/
$ bin/karaf
karaf: JAVA_HOME not set; results may vary
ERROR: Bundle org.apache.karaf.shell.core [43] Error starting 
mvn:org.apache.karaf.shell/org.apache.karaf.shell.core/4.0.8-SNAPSHOT 
(org.osgi.framework.BundleException: Activator start error in bundle 
org.apache.karaf.shell.core [43].)
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no jansi in 
java.library.path, 
/home/alarm/apache-karaf-4.0.8-SNAPSHOT/data/tmp/libjansi-32-2478131505029641357.so:
 
/home/alarm/apache-karaf-4.0.8-SNAPSHOT/data/tmp/libjansi-32-2478131505029641357.so:
 cannot open shared object file: No such file or directory (Possible cause: 
can't load IA 32-bit .so on a ARM-bit platform)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at 
org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
at 
org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:112)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2227)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2145)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
ERROR: Bundle org.apache.karaf.shell.core [43] Error starting/stopping bundle. 
(org.osgi.framework.BundleException: Activator start error in bundle 
org.apache.karaf.shell.core [43].)
java.lang.IllegalStateException: Thread Print Stream already set
at 
org.apache.felix.gogo.runtime.threadio.ThreadIOImpl.start(ThreadIOImpl.java:49)
at 
org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:63)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2227)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2145)
at org.apache.felix.framework.Felix.setBundleStartLevel(Felix.java:1564)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:338)
at java.lang.Thread.run(Thread.java:745)
{noformat}

> shell (so also ssh) not working anymore on ARM
> --
>
> Key: KARAF-4714
> URL: https://issues.apache.org/jira/browse/KARAF-4714
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-shell
>Affects Versions: 4.0.6
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
>Priority: Blocker
> Fix For: 4.1.0, 4.0.8
>
> Attachments: karaf.log.k405.txt, karaf.log.k406.txt
>
>
> The official Karaf 4.0.6 distribution (the archive 
> "apache-karaf-4.0.6.tar.gz" from your homepage) does not work correctly on 
> ARM systems.
> I unpacked and started the official distribution (bin/karaf).
> The log file shows this content:
> {noformat}
> 2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
> BootFeaturesInstaller| 8 - org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.apache.karaf.features.internal.util.MultiException: Error restarting 
> bundles
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features

[jira] [Commented] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4714:
---

FYI: Problems remains in K407 staging from here: 
https://repository.apache.org/content/repositories/orgapachekaraf-1075/org/apache/karaf/apache-karaf/4.0.7/apache-karaf-4.0.7.tar.gz

{noformat}
2016-09-19 08:50:03,726 | ERROR | pool-7-thread-1  | BootFeaturesInstaller  
  | 8 - org.apache.karaf.features.core - 4.0.7 | Error installing boot 
features
org.apache.karaf.features.internal.util.MultiException: Error restarting bundles
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.7]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.7]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.7]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
Caused by: org.osgi.framework.BundleException: Activator start error in bundle 
org.apache.karaf.shell.core [43].
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.7]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.7]
... 6 more
Caused by: java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no 
jansi in java.library.path, 
/home/alarm/apache-karaf-4.0.7/data/tmp/libjansi-32-6289284179178364483.so: 
/home/alarm/apache-karaf-4.0.7/data/tmp/libjansi-32-6289284179178364483.so: 
cannot open shared object file: No such file or directory (Possible cause: 
can't load IA 32-bit .so on a ARM-bit platform)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at 
org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_65]
at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
at 
org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:112)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
... 11 more
{noformat}

> shell (so also ssh) not working anymore on ARM
> --
>
> Key: KARAF-4714
> URL: https://issues.apache.org/jira/browse/KARAF-4714
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-shell
>Affects Versions: 4.0.6
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
> Attachments: karaf.log.k405.txt, karaf.log.k406.txt
>
>
> The official Karaf 4.0.6 distribution (the archive 
> "apache-karaf-4.0.6.tar.gz" from your homepage) does not work correctly on 
> ARM systems.
> I unpacked and started the official distribution (bin/karaf).
> The log file shows this content:
> {noformat}
> 2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
> BootFeaturesInstaller| 8 - org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.ap

[jira] [Commented] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4714:
---

Interesting...
The so itself (in data/tmp) is also a "Intel 80386" one for K405.
But it seems this does not care.

{noformat}
$ file 
/home/alarm/apache-karaf-4.0.5/data/tmp/libjansi-32-3767049652815180199.so
/home/alarm/apache-karaf-4.0.5/data/tmp/libjansi-32-3767049652815180199.so: ELF 
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, 
not stripped
{noformat}

{noformat}
$ file 
/home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-6236156654120354517.so
/home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-6236156654120354517.so: ELF 
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, 
not stripped
{noformat}

> shell (so also ssh) not working anymore on ARM
> --
>
> Key: KARAF-4714
> URL: https://issues.apache.org/jira/browse/KARAF-4714
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-shell
>Affects Versions: 4.0.6
>Reporter: Markus Rathgeb
> Attachments: karaf.log.k405.txt, karaf.log.k406.txt
>
>
> The official Karaf 4.0.6 distribution (the archive 
> "apache-karaf-4.0.6.tar.gz" from your homepage) does not work correctly on 
> ARM systems.
> I unpacked and started the official distribution (bin/karaf).
> The log file shows this content:
> {noformat}
> 2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
> BootFeaturesInstaller| 8 - org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.apache.karaf.features.internal.util.MultiException: Error restarting 
> bundles
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.6]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
> Caused by: org.osgi.framework.BundleException: Activator start error
> in bundle org.apache.karaf.shell.core [43].
> at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.6]
> ... 6 more
> Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
> Reasons: [no jansi in java.library.path,
> /home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
> /home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
> cannot open shared object file: No such file or directory (Possible
> cause: can't load IA 32-bit .so on a ARM-bit platform)]
> at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
> at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
> at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
> at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
> at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
> at 
> org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
> at 
> org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
> at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_65]
> at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
> at 
> org.apache.karaf.shell.impl.

[jira] [Updated] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-4714:
--
Attachment: karaf.log.k406.txt
karaf.log.k405.txt

I started a clean / new extracted distribution and attached the log file for 
K405 and K406.

> shell (so also ssh) not working anymore on ARM
> --
>
> Key: KARAF-4714
> URL: https://issues.apache.org/jira/browse/KARAF-4714
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-shell
>Affects Versions: 4.0.6
>Reporter: Markus Rathgeb
> Attachments: karaf.log.k405.txt, karaf.log.k406.txt
>
>
> The official Karaf 4.0.6 distribution (the archive 
> "apache-karaf-4.0.6.tar.gz" from your homepage) does not work correctly on 
> ARM systems.
> I unpacked and started the official distribution (bin/karaf).
> The log file shows this content:
> {noformat}
> 2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
> BootFeaturesInstaller| 8 - org.apache.karaf.features.core
> - 4.0.6 | Error installing boot features
> org.apache.karaf.features.internal.util.MultiException: Error restarting 
> bundles
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.6]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
> Caused by: org.osgi.framework.BundleException: Activator start error
> in bundle org.apache.karaf.shell.core [43].
> at 
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.6]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.6]
> ... 6 more
> Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
> Reasons: [no jansi in java.library.path,
> /home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
> /home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
> cannot open shared object file: No such file or directory (Possible
> cause: can't load IA 32-bit .so on a ARM-bit platform)]
> at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
> at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
> at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
> at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
> at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
> at 
> org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
> at 
> org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
> at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_65]
> at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
> at 
> org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
> at 
> org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:112)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
> ... 11 more
> {noformat}



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

[jira] [Updated] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-4714:
--
Description: 
The official Karaf 4.0.6 distribution (the archive "apache-karaf-4.0.6.tar.gz" 
from your homepage) does not work correctly on ARM systems.

I unpacked and started the official distribution (bin/karaf).

The log file shows this content:
{noformat}
2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
BootFeaturesInstaller| 8 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.apache.karaf.features.internal.util.MultiException: Error restarting bundles
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.6]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
Caused by: org.osgi.framework.BundleException: Activator start error
in bundle org.apache.karaf.shell.core [43].
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.6]
... 6 more
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
/home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
cannot open shared object file: No such file or directory (Possible
cause: can't load IA 32-bit .so on a ARM-bit platform)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_65]
at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
at 
org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:112)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
... 11 more
{noformat}

  was:
The official Karaf 4.0.6 distribution (the archive "apache-karaf-4.0.6.tar.gz" 
from your homepage) does not work correctly on ARM systems.

I unpacked and started the official distribution (bin/karaf).

The log file shows this content:
===
2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
BootFeaturesInstaller| 8 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.apache.karaf.features.internal.util.MultiException: Error restarting bundles
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.6]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
at 
java.util.concurrent.T

[jira] [Created] (KARAF-4714) shell (so also ssh) not working anymore on ARM

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4714:
-

 Summary: shell (so also ssh) not working anymore on ARM
 Key: KARAF-4714
 URL: https://issues.apache.org/jira/browse/KARAF-4714
 Project: Karaf
  Issue Type: Bug
  Components: karaf-shell
Affects Versions: 4.0.6
Reporter: Markus Rathgeb


The official Karaf 4.0.6 distribution (the archive "apache-karaf-4.0.6.tar.gz" 
from your homepage) does not work correctly on ARM systems.

I unpacked and started the official distribution (bin/karaf).

The log file shows this content:
===
2016-09-14 19:25:16,104 | ERROR | pool-7-thread-1  |
BootFeaturesInstaller| 8 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.apache.karaf.features.internal.util.MultiException: Error restarting bundles
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:854)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.6]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
Caused by: org.osgi.framework.BundleException: Activator start error
in bundle org.apache.karaf.shell.core [43].
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2144)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1286)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:846)[8:org.apache.karaf.features.core:4.0.6]
... 6 more
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
/home/alarm/apache-karaf-4.0.6/data/tmp/libjansi-32-1562974624645500249.so:
cannot open shared object file: No such file or directory (Possible
cause: can't load IA 32-bit .so on a ARM-bit platform)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.wrap(StreamWrapUtil.java:62)
at 
org.apache.karaf.shell.impl.console.osgi.StreamWrapUtil.reWrap(StreamWrapUtil.java:89)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:81)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager$2.run(LocalConsoleManager.java:76)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_65]
at org.apache.karaf.util.jaas.JaasHelper.doAs(JaasHelper.java:93)
at 
org.apache.karaf.shell.impl.console.osgi.LocalConsoleManager.start(LocalConsoleManager.java:76)
at 
org.apache.karaf.shell.impl.console.osgi.Activator.start(Activator.java:112)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
... 11 more
===



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

[jira] [Commented] (KARAF-4278) clean not working

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4278:
---

{noformat}rm -rf "$KARAF_DATA/"*{noformat}
will work but files starting with a dot are not removed.

{noformat}rm -Rf "$KARAF_DATA"/{.[^.],.??*,*}{noformat}
should remove the "hidden" directory entries, too (but omit "." and ".."). But 
I do not know if the usage of the curly bracket is okay (portable). For bash it 
should be no problem.

> clean not working
> -
>
> Key: KARAF-4278
> URL: https://issues.apache.org/jira/browse/KARAF-4278
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 4.0.4
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.5
>
>
> The solution for KARAF-4241 seems to break the clean at least on linux system 
> (I tested on linux only).
> There is a report, that it is also broken on Win7: 
> http://karaf.922171.n3.nabble.com/karaf-4-0-4-clean-not-working-tp4044848.html
> For the linux script:
> The wildcard (don't know why two instead of one is used) is also in the 
> quoted argument, so it is not evaluated by the shell.
> On linux systems "hidden" files (files starting with a dot) are handled 
> separately and not matched by the wildcard at all.
> For Linux systems I would use:
> {noformat}
> rm -Rf "$KARAF_DATA"/{.[^.],.??*,*}
> {noformat}



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

[jira] [Commented] (KARAF-4270) Shell-compat gets NPE trying to give help for combo of local and compat commands

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4270:
---

I found this issue after I implemented the fix myself. ;) I should look at JIRA 
first...

The applied patch fixes the NPE but returns "null" in the getDescription() 
function.
The other branches in that file (that handles other command types) implement 
the getDescription() that it returns getName() if the description is null.
See
* 
https://github.com/bimargulies/karaf/blob/5a00ab7ee204c05df06925f38d196840bf7f0302/shell/console/src/main/java/org/apache/karaf/shell/compat/CommandTracker.java#L88
* 
https://github.com/bimargulies/karaf/blob/5a00ab7ee204c05df06925f38d196840bf7f0302/shell/console/src/main/java/org/apache/karaf/shell/compat/CommandTracker.java#L136

Shouldn't we do here the same to handle it the same way as the other ones?
I would prefer to change that line:
https://github.com/bimargulies/karaf/blob/5a00ab7ee204c05df06925f38d196840bf7f0302/shell/console/src/main/java/org/apache/karaf/shell/compat/CommandTracker.java#L193
to "return getName();"

What do you think?

> Shell-compat gets NPE trying to give help for combo of local and compat 
> commands
> 
>
> Key: KARAF-4270
> URL: https://issues.apache.org/jira/browse/KARAF-4270
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.4
>Reporter: Benson Margulies
>Assignee: Freeman Fang
> Fix For: 4.1.0, 4.0.5
>
>
> {noformat}
> karaf@root>help scr
> pipe: java.lang.NullPointerException
> karaf@root>
> {noformat}



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

[jira] [Commented] (KARAF-4124) feature config installer adds property to config

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4124:
---

Any news?

> feature config installer adds property to config
> 
>
> Key: KARAF-4124
> URL: https://issues.apache.org/jira/browse/KARAF-4124
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.3
>Reporter: Markus Rathgeb
>
> The  element in a feature XML allows a feature to create and/or 
> populate a configuration (identified by a configuration PID).
> The "FeatureConfigInstaller" adds a custom property to the configuration.
> key = "org.apache.karaf.features.configKey"
> value = result of function call "createConfigurationKey(pid[0], pid[1])"
> There are bundles that cannot handle additional properties in the 
> configuration.
> For example:
> * using Aries JPA + Hiberante + h2
> * the configuration is installed by a feature and a realted config entry
> * this will result in a non working setup
> {noformat}
> Caused by: org.h2.jdbc.JdbcSQLException: Unsupported connection setting 
> "ORG.APACHE.KARAF.FEATURES.CONFIGKEY" [90113-172]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> at org.h2.message.DbException.get(DbException.java:169)
> at org.h2.message.DbException.get(DbException.java:146)
> at 
> org.h2.engine.ConnectionInfo.readSettingsFromURL(ConnectionInfo.java:266)
> at org.h2.engine.ConnectionInfo.(ConnectionInfo.java:77)
> at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:90)
> at org.h2.Driver.connect(Driver.java:73)
> at 
> org.h2.jdbcx.JdbcDataSource.getJdbcConnection(JdbcDataSource.java:187)
> at 
> org.h2.jdbcx.JdbcDataSource.getXAConnection(JdbcDataSource.java:323)
> at 
> org.apache.commons.dbcp2.managed.DataSourceXAConnectionFactory.createConnection(DataSourceXAConnectionFactory.java:112)
> at 
> org.apache.commons.dbcp2.managed.PoolableManagedConnectionFactory.makeObject(PoolableManagedConnectionFactory.java:66)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:868)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:435)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
> at 
> org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:127)
> ... 132 more
> {noformat}
> There is a conditional branch in the "findExistingConfiguration" function to 
> filter (find) the configuration using that property instead of the 
> service.pid (this is another conditional branch).
> Is there any reason for using that property?
> I changed the "FeatureConfigInstaller" to not append that property and the 
> above example is working now.



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

[jira] [Commented] (KARAF-4105) karaf-assembly fails when used Maven versions do not match derived OSGi versions

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4105:
---

I am a little bit irritated about the version handling here.
There is a TODO, that version ranges are currently ignored at all 
(https://github.com/apache/karaf/blob/karaf-4.0.4/profile/src/main/java/org/apache/karaf/profile/assembly/Builder.java#L1089).

The PR I created should solve some problems, but I assume that the feature 
resolver handles version correctly already.
Somewhere in the Karaf code versions and version ranges are handled correctly 
(I think so).
Why can't we reuse that version handling instead of implement a new one?

Could you (e.g. [~jbonofre]) point me to that code and how to reuse it 
correctly (as we extend the profile feature we should not create a bunch of 
dependencies, I assume.)

> karaf-assembly fails when used Maven versions do not match derived OSGi 
> versions
> 
>
> Key: KARAF-4105
> URL: https://issues.apache.org/jira/browse/KARAF-4105
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-tooling
>Affects Versions: 4.0.3
>Reporter: Oliver Lietz
>Assignee: Jean-Baptiste Onofré
>
> e.g. {{$\{project.version\}}} {{0.1.1-SNAPSHOT}} and {{0.1.1.SNAPSHOT}} do 
> not match in {{org.apache.karaf.profile.assembly.Builder}}
> See mail thread [\[K4.0.3\] custom distribution and 
> kar|http://mail-archives.apache.org/mod_mbox/karaf-user/201511.mbox/%3c7781910.EKNrsAyV2X@madness%3e]
>  for more.



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

[jira] [Commented] (KARAF-4278) clean not working

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4278:
---

IMHO the above command will work for Linux systems. I would assume it works for 
MAC, too (but cannot test it).
As I am not using Windows, I cannot test / add changes to the batch file.
(That is the reason, why I have not created a PR. Sorry)

> clean not working
> -
>
> Key: KARAF-4278
> URL: https://issues.apache.org/jira/browse/KARAF-4278
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 4.0.4
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.5
>
>
> The solution for KARAF-4241 seems to break the clean at least on linux system 
> (I tested on linux only).
> There is a report, that it is also broken on Win7: 
> http://karaf.922171.n3.nabble.com/karaf-4-0-4-clean-not-working-tp4044848.html
> For the linux script:
> The wildcard (don't know why two instead of one is used) is also in the 
> quoted argument, so it is not evaluated by the shell.
> On linux systems "hidden" files (files starting with a dot) are handled 
> separately and not matched by the wildcard at all.
> For Linux systems I would use:
> {noformat}
> rm -Rf "$KARAF_DATA"/{.[^.],.??*,*}
> {noformat}



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

[jira] [Updated] (KARAF-4278) clean not working

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-4278:
--
Description: 
The solution for KARAF-4241 seems to break the clean at least on linux system 
(I tested on linux only).
There is a report, that it is also broken on Win7: 
http://karaf.922171.n3.nabble.com/karaf-4-0-4-clean-not-working-tp4044848.html

For the linux script:
The wildcard (don't know why two instead of one is used) is also in the quoted 
argument, so it is not evaluated by the shell.
On linux systems "hidden" files (files starting with a dot) are handled 
separately and not matched by the wildcard at all.

For Linux systems I would use:
{noformat}
rm -Rf "$KARAF_DATA"/{.[^.],.??*,*}
{noformat}

  was:
The solution for KARAF-4241 seems to break the clean at least on linux system 
(I tested on linux only).
There is a report, that it is also broken on Win7: 
http://karaf.922171.n3.nabble.com/karaf-4-0-4-clean-not-working-tp4044848.html

For the linux script:
The wildcard (don't know why two instead of one is used) is also in the quoted 
argument, so it is not evaluated by the shell.
On linux systems "hidden" files (files starting with a dot) are handled 
separately and not matched by the wildcard at all.

For Linux systems I would use:
{code:shell}
rm -Rf "$KARAF_DATA"/{.[^.],.??*,*}
{code:shell}


> clean not working
> -
>
> Key: KARAF-4278
> URL: https://issues.apache.org/jira/browse/KARAF-4278
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 4.0.4
>Reporter: Markus Rathgeb
>
> The solution for KARAF-4241 seems to break the clean at least on linux system 
> (I tested on linux only).
> There is a report, that it is also broken on Win7: 
> http://karaf.922171.n3.nabble.com/karaf-4-0-4-clean-not-working-tp4044848.html
> For the linux script:
> The wildcard (don't know why two instead of one is used) is also in the 
> quoted argument, so it is not evaluated by the shell.
> On linux systems "hidden" files (files starting with a dot) are handled 
> separately and not matched by the wildcard at all.
> For Linux systems I would use:
> {noformat}
> rm -Rf "$KARAF_DATA"/{.[^.],.??*,*}
> {noformat}



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

[jira] [Created] (KARAF-4278) clean not working

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4278:
-

 Summary: clean not working
 Key: KARAF-4278
 URL: https://issues.apache.org/jira/browse/KARAF-4278
 Project: Karaf
  Issue Type: Bug
  Components: karaf-core
Affects Versions: 4.0.4
Reporter: Markus Rathgeb


The solution for KARAF-4241 seems to break the clean at least on linux system 
(I tested on linux only).
There is a report, that it is also broken on Win7: 
http://karaf.922171.n3.nabble.com/karaf-4-0-4-clean-not-working-tp4044848.html

For the linux script:
The wildcard (don't know why two instead of one is used) is also in the quoted 
argument, so it is not evaluated by the shell.
On linux systems "hidden" files (files starting with a dot) are handled 
separately and not matched by the wildcard at all.

For Linux systems I would use:
{code:shell}
rm -Rf "$KARAF_DATA"/{.[^.],.??*,*}
{code:shell}



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

[jira] [Commented] (KARAF-4105) karaf-assembly fails when used Maven versions do not match derived OSGi versions

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4105:
---

The versions are compared using string equality function.

{noformat}
private boolean matches(Feature f, Dependency featureRef) {
String version = featureRef.getVersion();
return f.getName().equals(featureRef.getName()) 
&& (version == null || version.equals("0.0.0")|| 
version.startsWith("[") || f.getVersion().equals(version));
}
{noformat}

I would prefer using the comparision that is available in maven themselves.
But I don't now if this will break something others.

So change and test?

> karaf-assembly fails when used Maven versions do not match derived OSGi 
> versions
> 
>
> Key: KARAF-4105
> URL: https://issues.apache.org/jira/browse/KARAF-4105
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-tooling
>Affects Versions: 4.0.3
>Reporter: Oliver Lietz
>
> e.g. {{$\{project.version\}}} {{0.1.1-SNAPSHOT}} and {{0.1.1.SNAPSHOT}} do 
> not match in {{org.apache.karaf.profile.assembly.Builder}}
> See mail thread [\[K4.0.3\] custom distribution and 
> kar|http://mail-archives.apache.org/mod_mbox/karaf-user/201511.mbox/%3c7781910.EKNrsAyV2X@madness%3e]
>  for more.



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

[jira] [Commented] (KARAF-4105) karaf-assembly fails when used Maven versions do not match derived OSGi versions

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4105:
---

We should check the mechanism Karaf uses to compare versions.
IMHO it should be moved (if it is not already used) to 
org.apache.maven.artifact.versioning.ComparableVersion.

https://maven.apache.org/ref/3.0.3/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html

> karaf-assembly fails when used Maven versions do not match derived OSGi 
> versions
> 
>
> Key: KARAF-4105
> URL: https://issues.apache.org/jira/browse/KARAF-4105
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-tooling
>Affects Versions: 4.0.3
>Reporter: Oliver Lietz
>
> e.g. {{$\{project.version\}}} {{0.1.1-SNAPSHOT}} and {{0.1.1.SNAPSHOT}} do 
> not match in {{org.apache.karaf.profile.assembly.Builder}}
> See mail thread [\[K4.0.3\] custom distribution and 
> kar|http://mail-archives.apache.org/mod_mbox/karaf-user/201511.mbox/%3c7781910.EKNrsAyV2X@madness%3e]
>  for more.



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

[jira] [Commented] (KARAF-3982) Be able to change standard files during distribution assembly

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3982:
---

Is it possible that this pull request has broken the build?

{noformat}
[INFO] --- maven-invoker-plugin:2.0.0:run (integration-test) @ 
karaf-maven-plugin ---
[INFO] Building: test-aggregate-features/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (4.4 s)
[INFO] Building: test-basic-generation/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (3.1 s)
[INFO] Building: test-check-dependencies-failure/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (4.2 s)
[INFO] Building: test-check-dependencies/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (4.1 s)
[INFO] Building: test-include-project-artifact/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (3.0 s)
[INFO] Building: test-input-file/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (2.9 s)
[INFO] Building: test-kar-classifier/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (2.1 s)
[INFO] Building: test-kar-multiple-kars/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (2.1 s)
[INFO] Building: test-kar-packaging/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (2.2 s)
[INFO] Building: test-kar-with-pom-packaging/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (2.1 s)
[INFO] Building: test-recursive/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (3.6 s)
[INFO] Building: test-type-classifier/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (2.9 s)
[INFO] Building: test-assembly/pom.xml
[INFO] ..SUCCESS (3.4 s)
[INFO] Building: test-rename-main-feature/pom.xml
[INFO] run script verify.bsh
[INFO] ..SUCCESS (3.2 s)
[INFO] Building: test-assembly-prop-edits/pom.xml
[INFO] ..FAILED (1.8 s)
[INFO]   The build exited with code 1. See 
/home/maggu2810/workspace/projects/karaf/vcs/tooling/karaf-maven-plugin/target/it/test-assembly-prop-edits/build.log
 for details.
[INFO] -
[INFO] Build Summary:
[INFO]   Passed: 14, Failed: 1, Errors: 0, Skipped: 0
[INFO] -
[ERROR] The following builds failed:
[ERROR] *  test-assembly-prop-edits/pom.xml
[INFO] -
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Karaf ... SUCCESS [  1.021 s]
[INFO] Apache Karaf :: JAAS ... SUCCESS [  0.037 s]
[INFO] Apache Karaf :: JAAS :: Boot ... SUCCESS [  1.138 s]
[INFO] Apache Karaf :: Util ... SUCCESS [  0.988 s]
[INFO] Apache Karaf :: Main ... SUCCESS [  0.898 s]
[INFO] Apache Karaf :: Features ... SUCCESS [  0.020 s]
[INFO] Apache Karaf :: Service  SUCCESS [  0.021 s]
[INFO] Apache Karaf :: Service :: Guard ... SUCCESS [  0.756 s]
[INFO] Apache Karaf :: Shell .. SUCCESS [  0.013 s]
[INFO] Apache Karaf :: Shell :: Core .. SUCCESS [  1.239 s]
[INFO] Apache Karaf :: Tooling  SUCCESS [  0.012 s]
[INFO] Apache Karaf :: Tooling :: Maven Karaf Plugin for Services Metadata 
SUCCESS [  2.543 s]
[INFO] Apache Karaf :: Features :: Core ... SUCCESS [  1.862 s]
[INFO] Apache Karaf :: Features :: Command  SUCCESS [  0.961 s]
[INFO] Apache Karaf :: KAR :: Core  SUCCESS [  0.882 s]
[INFO] Apache Karaf :: JAAS :: Config . SUCCESS [  0.287 s]
[INFO] Apache Karaf :: JAAS :: Modules  SUCCESS [  2.731 s]
[INFO] Apache Karaf :: Bundle . SUCCESS [  0.011 s]
[INFO] Apache Karaf :: Bundle :: Core . SUCCESS [  1.004 s]
[INFO] Apache Karaf :: Bundle :: BlueprintStateService  SUCCESS [  0.165 s]
[INFO] Apache Karaf :: Bundle :: SpringStateService ... SUCCESS [  0.264 s]
[INFO] Apache Karaf :: ConfigAdmin :: Core  SUCCESS [  0.490 s]
[INFO] Apache Karaf :: Tooling :: Utils ... SUCCESS [  0.504 s]
[INFO] Apache Karaf :: Deployer ... SUCCESS [  0.064 s]
[INFO] Apache Karaf :: Deployer :: Blueprint .. SUCCESS [  0.280 s]
[INFO] Apache Karaf :: Deployer :: Spring . SUCCESS [  0.265 s]
[INFO] Apache Karaf :: Demos :: Profiles :: Registry .. SUCCESS [  0.060 s]
[INFO] Apache Karaf :: Profile :: Core  SUCCESS [  1.646 s]
[INFO] Apache Karaf :: Instance :: Core ... SUCCESS [  1.117 s]
[INFO] Apache Karaf :: Package :: Core  SUCCESS [  0.428 s]
[INFO] Apache Karaf :: HTTP :: Core ... SUCCESS [  0.359 s]
[INFO] Ap

[jira] [Updated] (KARAF-3982) Be able to change standard files during distribution assembly

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-3982:
--
Attachment: build.log

The build log file

> Be able to change standard files during distribution assembly
> -
>
> Key: KARAF-3982
> URL: https://issues.apache.org/jira/browse/KARAF-3982
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-tooling
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.0.4
>
> Attachments: build.log
>
>
> The Karaf Maven plugin generates files (etc/org.apache.karaf.features.cfg, 
> etc). It would be great to mimic pax-exam to be able to change these 
> generated files (like put/append instructions).



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

[jira] [Created] (KARAF-4145) KAR is created with defect maven metadata

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4145:
-

 Summary: KAR is created with defect maven metadata
 Key: KARAF-4145
 URL: https://issues.apache.org/jira/browse/KARAF-4145
 Project: Karaf
  Issue Type: Bug
  Components: karaf-tooling
Affects Versions: 4.0.3
Reporter: Markus Rathgeb


Problem description:
* use the kmp to generate a kar that contains snapshot version
* use the kmp to generate a custom distribution that fills the local repository 
of the distribution with the content of that kar
* try to install the snapshot artifact (not using any other repository then the 
system directory
* if your snapshots has been timestamped and a maven metadata XML does not 
exist on KAR creation the installation of the artifact will fail

The KAR Mojo contains a workaround to use the base version of a snapshot
instead of a timestamped one because it does not work in
startup.properties.
The metadata that is used for a snapshot artifact is generated (if not
present) using the timestamped version. Also if there exists already a
metadata, we can not use them without further checking for the
version...
Let's move the version fix in front of the metadata generation and
generate the metadata for every snapshot.



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

[jira] [Commented] (KARAF-4124) feature config installer adds property to config

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-4124:
---

I want to switch easy between different database drivers.

So I need to change:
* the dialect for hibernate
* the data source configuration
* the respective used feature

But the following mechanism is much better because all is configured in one 
file / feature:

* feature for MariaDB

{noformat}

http://karaf.apache.org/xmlns/features/v1.3.0";>

${project.description}
pax-jdbc-mariadb

hibernate.dialect=org.hibernate.dialect.MySQL5Dialect
hibernate.hbm2ddl.auto=create-drop


osgi.jdbc.driver.name=mariadb
user=foo
password=bar
url=jdbc:mariadb://127.0.0.1:3306/test
dataSourceName=testdb



{noformat}

* feature for H2 in memory

{noformat}

http://karaf.apache.org/xmlns/features/v1.3.0";>

${project.description}
pax-jdbc-h2

hibernate.dialect=org.hibernate.dialect.H2Dialect
hibernate.hbm2ddl.auto=create-drop


osgi.jdbc.driver.name=H2-pool-xa
url=jdbc:h2:mem:test
dataSourceName=testdb



{noformat}


One note: configfile is working as expected, but this means 3 files (2x config, 
1x feature).


> feature config installer adds property to config
> 
>
> Key: KARAF-4124
> URL: https://issues.apache.org/jira/browse/KARAF-4124
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.3
>Reporter: Markus Rathgeb
>
> The  element in a feature XML allows a feature to create and/or 
> populate a configuration (identified by a configuration PID).
> The "FeatureConfigInstaller" adds a custom property to the configuration.
> key = "org.apache.karaf.features.configKey"
> value = result of function call "createConfigurationKey(pid[0], pid[1])"
> There are bundles that cannot handle additional properties in the 
> configuration.
> For example:
> * using Aries JPA + Hiberante + h2
> * the configuration is installed by a feature and a realted config entry
> * this will result in a non working setup
> {noformat}
> Caused by: org.h2.jdbc.JdbcSQLException: Unsupported connection setting 
> "ORG.APACHE.KARAF.FEATURES.CONFIGKEY" [90113-172]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> at org.h2.message.DbException.get(DbException.java:169)
> at org.h2.message.DbException.get(DbException.java:146)
> at 
> org.h2.engine.ConnectionInfo.readSettingsFromURL(ConnectionInfo.java:266)
> at org.h2.engine.ConnectionInfo.(ConnectionInfo.java:77)
> at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:90)
> at org.h2.Driver.connect(Driver.java:73)
> at 
> org.h2.jdbcx.JdbcDataSource.getJdbcConnection(JdbcDataSource.java:187)
> at 
> org.h2.jdbcx.JdbcDataSource.getXAConnection(JdbcDataSource.java:323)
> at 
> org.apache.commons.dbcp2.managed.DataSourceXAConnectionFactory.createConnection(DataSourceXAConnectionFactory.java:112)
> at 
> org.apache.commons.dbcp2.managed.PoolableManagedConnectionFactory.makeObject(PoolableManagedConnectionFactory.java:66)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:868)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:435)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
> at 
> org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:127)
> ... 132 more
> {noformat}
> There is a conditional branch in the "findExistingConfiguration" function to 
> filter (find) the configuration using that property instead of the 
> service.pid (this is another conditional branch).
> Is there any reason for using that property?
> I changed the "FeatureConfigInstaller" to not append that property and the 
> above example is working now.



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

[jira] [Updated] (KARAF-4124) feature config installer adds property to config

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-4124:
--
Description: 
The  element in a feature XML allows a feature to create and/or 
populate a configuration (identified by a configuration PID).

The "FeatureConfigInstaller" adds a custom property to the configuration.
key = "org.apache.karaf.features.configKey"
value = result of function call "createConfigurationKey(pid[0], pid[1])"

There are bundles that cannot handle additional properties in the configuration.

For example:
* using Aries JPA + Hiberante + h2
* the configuration is installed by a feature and a realted config entry
* this will result in a non working setup

{noformat}
Caused by: org.h2.jdbc.JdbcSQLException: Unsupported connection setting 
"ORG.APACHE.KARAF.FEATURES.CONFIGKEY" [90113-172]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at 
org.h2.engine.ConnectionInfo.readSettingsFromURL(ConnectionInfo.java:266)
at org.h2.engine.ConnectionInfo.(ConnectionInfo.java:77)
at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:90)
at org.h2.Driver.connect(Driver.java:73)
at 
org.h2.jdbcx.JdbcDataSource.getJdbcConnection(JdbcDataSource.java:187)
at org.h2.jdbcx.JdbcDataSource.getXAConnection(JdbcDataSource.java:323)
at 
org.apache.commons.dbcp2.managed.DataSourceXAConnectionFactory.createConnection(DataSourceXAConnectionFactory.java:112)
at 
org.apache.commons.dbcp2.managed.PoolableManagedConnectionFactory.makeObject(PoolableManagedConnectionFactory.java:66)
at 
org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:868)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:435)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
at 
org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:127)
... 132 more
{noformat}

There is a conditional branch in the "findExistingConfiguration" function to 
filter (find) the configuration using that property instead of the service.pid 
(this is another conditional branch).

Is there any reason for using that property?

I changed the "FeatureConfigInstaller" to not append that property and the 
above example is working now.

  was:
The  element in a feature XML allows a feature to create and/or 
populate a configuration (identified by a configuration PID).

The "FeatureConfigInstaller" adds a custom property to the configuration.
key = "org.apache.karaf.features.configKey"
value = result of function call "createConfigurationKey(pid[0], pid[1])"

There are bundles that cannot handle additional properties in the configuration.

For example:
* using Aries JPA + Hiberante + h2
* the configuration is installed by a feature and a realted config entry
* this will result in a non working setup

Caused by: org.h2.jdbc.JdbcSQLException: Unsupported connection setting 
"ORG.APACHE.KARAF.FEATURES.CONFIGKEY" [90113-172]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at 
org.h2.engine.ConnectionInfo.readSettingsFromURL(ConnectionInfo.java:266)
at org.h2.engine.ConnectionInfo.(ConnectionInfo.java:77)
at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:90)
at org.h2.Driver.connect(Driver.java:73)
at 
org.h2.jdbcx.JdbcDataSource.getJdbcConnection(JdbcDataSource.java:187)
at org.h2.jdbcx.JdbcDataSource.getXAConnection(JdbcDataSource.java:323)
at 
org.apache.commons.dbcp2.managed.DataSourceXAConnectionFactory.createConnection(DataSourceXAConnectionFactory.java:112)
at 
org.apache.commons.dbcp2.managed.PoolableManagedConnectionFactory.makeObject(PoolableManagedConnectionFactory.java:66)
at 
org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:868)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:435)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
at 
org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:127)
... 132 more


There is a conditional branch in the "findExistingConfiguration" function to 
filter (find) the configuration using that property instead of the service.pid 
(this is another conditional branch).

Is there any reason for using that property?

I changed the "FeatureConfigInstaller" to not append that property and the 
above example is working now.


> feature co

[jira] [Created] (KARAF-4124) feature config installer adds property to config

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4124:
-

 Summary: feature config installer adds property to config
 Key: KARAF-4124
 URL: https://issues.apache.org/jira/browse/KARAF-4124
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Affects Versions: 4.0.3
Reporter: Markus Rathgeb


The  element in a feature XML allows a feature to create and/or 
populate a configuration (identified by a configuration PID).

The "FeatureConfigInstaller" adds a custom property to the configuration.
key = "org.apache.karaf.features.configKey"
value = result of function call "createConfigurationKey(pid[0], pid[1])"

There are bundles that cannot handle additional properties in the configuration.

For example:
* using Aries JPA + Hiberante + h2
* the configuration is installed by a feature and a realted config entry
* this will result in a non working setup

Caused by: org.h2.jdbc.JdbcSQLException: Unsupported connection setting 
"ORG.APACHE.KARAF.FEATURES.CONFIGKEY" [90113-172]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at 
org.h2.engine.ConnectionInfo.readSettingsFromURL(ConnectionInfo.java:266)
at org.h2.engine.ConnectionInfo.(ConnectionInfo.java:77)
at org.h2.jdbc.JdbcConnection.(JdbcConnection.java:90)
at org.h2.Driver.connect(Driver.java:73)
at 
org.h2.jdbcx.JdbcDataSource.getJdbcConnection(JdbcDataSource.java:187)
at org.h2.jdbcx.JdbcDataSource.getXAConnection(JdbcDataSource.java:323)
at 
org.apache.commons.dbcp2.managed.DataSourceXAConnectionFactory.createConnection(DataSourceXAConnectionFactory.java:112)
at 
org.apache.commons.dbcp2.managed.PoolableManagedConnectionFactory.makeObject(PoolableManagedConnectionFactory.java:66)
at 
org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:868)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:435)
at 
org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)
at 
org.apache.commons.dbcp2.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:127)
... 132 more


There is a conditional branch in the "findExistingConfiguration" function to 
filter (find) the configuration using that property instead of the service.pid 
(this is another conditional branch).

Is there any reason for using that property?

I changed the "FeatureConfigInstaller" to not append that property and the 
above example is working now.



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

[jira] [Commented] (KARAF-3597) features-generate-descriptor ignoring runtime dependencies

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3597:
---

Should we use the "reply" mechanism or adding a new comment (so the watchers 
get notified correctly)?

Added a reply above:
https://issues.apache.org/jira/browse/KARAF-3597?focusedCommentId=14996406&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14996406

> features-generate-descriptor ignoring runtime dependencies
> --
>
> Key: KARAF-3597
> URL: https://issues.apache.org/jira/browse/KARAF-3597
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-tooling
>Affects Versions: 3.0.3
> Environment: Apache Maven 3.2.5 
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T17:29:23+00:00)
> Maven home: /usr/local/Cellar/maven/3.2.5/libexec
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.2", arch: "x86_64", family: "mac"
>Reporter: Damian ONeill
>Assignee: Jean-Baptiste Onofré
>  Labels: features-generate-descriptor
> Attachments: pom.xml
>
>
> When running the following command 
> $ mvn -U karaf:features-generate-descriptor
> The generated feature.xml file does not contain any bundle definitions for 
> dependencies defined with scope runtime.
> For e.g. 
>  
> 
> javax.xml.bind
> jaxb-api
> 
> 
> com.sun.xml.bind
> jaxb-impl
> runtime
> 
> 
> org.jvnet.jaxb2_commons
> jaxb2-basics-runtime
> 
> 
> results in 
> 
> http://karaf.apache.org/xmlns/features/v1.2.1"; 
> name="resourcesModel">
>  description="resourcesModel">
> 9001 is the proNX brand name for the EMS Core.
> wrap:mvn:javax.xml.bind/jaxb-api/2.1
> wrap:mvn:javax.xml.stream/stax-api/1.0-2
> wrap:mvn:javax.activation/activation/1.1
> 
> mvn:org.jvnet.jaxb2_commons/jaxb2-basics-runtime/0.6.4
> 
> 
> Note no bundle definition for jaxb-impl defined with runtime scope above.



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

[jira] [Commented] (KARAF-3597) features-generate-descriptor ignoring runtime dependencies

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3597:
---

Has this been reproduced? I build a working example to reproduce this issue, 
too.
For karaf-maven-plugin 4.0.2 the Dependency31Helper (same for 
Dependency30Helper with different line numbers) builds the dependency tree 
using the getDependencyTree function (line 106ff).
The ScopeDependencySelector2 function (used through ScopeDependencySelector1 -- 
see function comment) filters the test and runtime scopes.

So, why do we filter runtime scope?

Let's consider the following example:
An artifact contains a configuration file that contains e.g. some class name 
that should be used for a given functionality. That configured value is read at 
runtime and used. So, the referenced class and the artifact that contains that 
class is only needed at runtime.
Is this not a very "normal" use case for Spring / JSP where you configure 
classes in XML files?
Sure, we could configure the dependency with scope compile instead of runtime 
to get the karaf-maven-plugin working, but that would be just a workaround. We 
could also configure that dependency in the feature file themselves, but IMHO 
then I does not need the feature-generation is I have to do such thing manually.

For "provided" and "test" the filtering is clear to me.

Why have you decided to filter the runtime scope out?

> features-generate-descriptor ignoring runtime dependencies
> --
>
> Key: KARAF-3597
> URL: https://issues.apache.org/jira/browse/KARAF-3597
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-tooling
>Affects Versions: 3.0.3
> Environment: Apache Maven 3.2.5 
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T17:29:23+00:00)
> Maven home: /usr/local/Cellar/maven/3.2.5/libexec
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.2", arch: "x86_64", family: "mac"
>Reporter: Damian ONeill
>Assignee: Jean-Baptiste Onofré
>  Labels: features-generate-descriptor
> Attachments: pom.xml
>
>
> When running the following command 
> $ mvn -U karaf:features-generate-descriptor
> The generated feature.xml file does not contain any bundle definitions for 
> dependencies defined with scope runtime.
> For e.g. 
>  
> 
> javax.xml.bind
> jaxb-api
> 
> 
> com.sun.xml.bind
> jaxb-impl
> runtime
> 
> 
> org.jvnet.jaxb2_commons
> jaxb2-basics-runtime
> 
> 
> results in 
> 
> http://karaf.apache.org/xmlns/features/v1.2.1"; 
> name="resourcesModel">
>  description="resourcesModel">
> 9001 is the proNX brand name for the EMS Core.
> wrap:mvn:javax.xml.bind/jaxb-api/2.1
> wrap:mvn:javax.xml.stream/stax-api/1.0-2
> wrap:mvn:javax.activation/activation/1.1
> 
> mvn:org.jvnet.jaxb2_commons/jaxb2-basics-runtime/0.6.4
> 
> 
> Note no bundle definition for jaxb-impl defined with runtime scope above.



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

[jira] [Updated] (KARAF-4055) karaf-maven-plugin: feature XML with a @ character

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb updated KARAF-4055:
--
Description: 
The feature XML generation fails if the source feature XML contains a @ (e.g. 
in the comment).
This is very annoying if your project is using the a maven license plugin and 
the license contains an email address of your company.

The current mechanism does replace ${...} and @...@ in the XML.
IMHO we should drop the @...@ support, so we could use email addresses in 
comments (e.g. licenses).

The problem could be reproduced using the "normal" output of the feature 
archetype.
Add a @ to the license header of the "src/main/feature/feature.xml" and run a 
"mvn clean install".

The result looks like:


http://karaf.apache.org/xmlns/features/v1.3.0"; 
name="${project.artifactId}-${project.version}">

${project.description}




  was:
The feature XML generation fails if the source feature XML contains a @ (e.g. 
in the comment).
This is very annoying if your project is using the a maven license plugin and 
the license contains an email address of your company.

The current mechanism does replace ${...} and @...@ in the XML.
IMHO we should drop the @...@ support, so we could use email addresses in 
comments (e.g. licenses).

The problem could be reproduced using the "normal" output of the feature 
archetype.
Add a @ to the license header of the "src/main/feature/feature.xml" and run a 
"mvn clean install".

The result looks like:

http://karaf.apache.org/xmlns/features/v1.3.0"; 
name="${project.artifactId}-${project.version}">

${project.description}





> karaf-maven-plugin: feature XML with a @ character
> --
>
> Key: KARAF-4055
> URL: https://issues.apache.org/jira/browse/KARAF-4055
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-tooling
>Affects Versions: 4.0.0, 4.0.1
>Reporter: Markus Rathgeb
>
> The feature XML generation fails if the source feature XML contains a @ (e.g. 
> in the comment).
> This is very annoying if your project is using the a maven license plugin and 
> the license contains an email address of your company.
> The current mechanism does replace ${...} and @...@ in the XML.
> IMHO we should drop the @...@ support, so we could use email addresses in 
> comments (e.g. licenses).
> The problem could be reproduced using the "normal" output of the feature 
> archetype.
> Add a @ to the license header of the "src/main/feature/feature.xml" and run a 
> "mvn clean install".
> The result looks like:
> 
> 
> http://karaf.apache.org/xmlns/features/v1.3.0"; 
> name="${project.artifactId}-${project.version}">
>  version="0.0.0.__project_version_">
> ${project.description}
> 
> 
> 



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

[jira] [Created] (KARAF-4055) karaf-maven-plugin: feature XML with a @ character

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4055:
-

 Summary: karaf-maven-plugin: feature XML with a @ character
 Key: KARAF-4055
 URL: https://issues.apache.org/jira/browse/KARAF-4055
 Project: Karaf
  Issue Type: Bug
  Components: karaf-tooling
Affects Versions: 4.0.1, 4.0.0
Reporter: Markus Rathgeb


The feature XML generation fails if the source feature XML contains a @ (e.g. 
in the comment).
This is very annoying if your project is using the a maven license plugin and 
the license contains an email address of your company.

The current mechanism does replace ${...} and @...@ in the XML.
IMHO we should drop the @...@ support, so we could use email addresses in 
comments (e.g. licenses).

The problem could be reproduced using the "normal" output of the feature 
archetype.
Add a @ to the license header of the "src/main/feature/feature.xml" and run a 
"mvn clean install".

The result looks like:

http://karaf.apache.org/xmlns/features/v1.3.0"; 
name="${project.artifactId}-${project.version}">

${project.description}






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

[jira] [Comment Edited] (KARAF-3858) Add systemd support in the wrapper

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb edited comment on KARAF-3858 at 10/6/15 1:05 PM:


IMHO we should respect the maintainer of systemd and not call it SystemD.

https://wiki.freedesktop.org/www/Software/systemd/
Yes, it is written systemd, not system D or System D, or even SystemD. And it 
isn't system d either.


was (Author: maggu2810):
IMHO we should respect the maintainer of systemd and not call is SystemD.

https://wiki.freedesktop.org/www/Software/systemd/
Yes, it is written systemd, not system D or System D, or even SystemD. And it 
isn't system d either.

> Add systemd support in the wrapper
> --
>
> Key: KARAF-3858
> URL: https://issues.apache.org/jira/browse/KARAF-3858
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-os-integration
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 3.0.5, 4.0.2
>
>




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

[jira] [Commented] (KARAF-3858) Add systemd support in the wrapper

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3858:
---

IMHO we should respect the maintainer of systemd and not call is SystemD.

https://wiki.freedesktop.org/www/Software/systemd/
Yes, it is written systemd, not system D or System D, or even SystemD. And it 
isn't system d either.

> Add systemd support in the wrapper
> --
>
> Key: KARAF-3858
> URL: https://issues.apache.org/jira/browse/KARAF-3858
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-os-integration
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 3.0.5, 4.0.2
>
>




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

[jira] [Commented] (KARAF-3262) Being able to use ${karaf.etc} in feature element

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3262:
---

Hi, could have a look at this change, please:
https://github.com/apache/karaf/compare/master...maggu2810:feature-config-path?expand=1

> Being able to use ${karaf.etc} in feature  element
> ---
>
> Key: KARAF-3262
> URL: https://issues.apache.org/jira/browse/KARAF-3262
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-feature
>Reporter: Jean-Baptiste Onofré
>
> The  element in a feature accepts a finalname attribute to 
> define where the configfile has to be copied.
> However, finalname is relative to ${karaf.base}, whereas it should be able to 
> use ${karaf.etc} (and so relative to ${karaf.etc}).
> In order to be backward compatible, if finalname starts with /etc/ it will be 
> relative to ${karaf.base}, else it will be related to ${karaf.etc}.



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

[jira] [Commented] (KARAF-3982) Be able to change standard files during distribution assembly

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3982:
---

Just an question about the mechanism at all.

Is this executed before the maven-resources-plugin processes the resources 
(copy it)?
Can I change the content of a file placed in my own resources?
I think we will not edit a file that are placed by our self, just want to know 
the sequence.

> Be able to change standard files during distribution assembly
> -
>
> Key: KARAF-3982
> URL: https://issues.apache.org/jira/browse/KARAF-3982
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-tooling
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>
> The Karaf Maven plugin generates files (etc/org.apache.karaf.features.cfg, 
> etc). It would be great to mimic pax-exam to be able to change these 
> generated files (like put/append instructions).



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

[jira] [Created] (KARAF-4005) Different locations for KARAF_HOME and KARAF_BASE

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-4005:
-

 Summary: Different locations for KARAF_HOME and KARAF_BASE
 Key: KARAF-4005
 URL: https://issues.apache.org/jira/browse/KARAF-4005
 Project: Karaf
  Issue Type: Bug
  Components: karaf-core, karaf-instance
Affects Versions: 4.0.1
Reporter: Markus Rathgeb


I would like to change the directories for KARAF_BASE, KARAF_HOME, KARAF_DATE 
and KARAF_ETC.

Using separate directories for KARAF_BASE and KARAF_HOME result in error 
messages on start and stop of the Karaf container (I shortened the path):
* Unable to update instance pid: Child instance started but no root
registered in /home/maggu2810/.../karaf/home/instances/instance.properties
* Unable to update instance pid: Child instance stopped but no root
registered in /home/maggu2810/.../karaf/home/instances/instance.properties

The class org.apache.karaf.main.InstanceHelper is using:
final boolean isRoot = karafHome.equals(karafBase);
If the properties are empty and isRoot is false, this error message and an 
IllegalStateException is thrown.

So, IMHO the intention of that variables is to support using different 
directories. But this seems to be broken (do not run in a problem at runtime 
after a short test, but the code throw the exception).

[http://karaf.922171.n3.nabble.com/Custom-distribution-change-directory-layout-tp4042677p4042691.html]
"The purpose of the current variables is more to be able to adapt to your 
machine/administrator constraint: put KARAF_ETC in /etc/karaf, put KARAF_BASE 
in /var/karaf and KARAF_HOME in /home/karaf for instance (by moving the 
directories)."

I checked in an example, so you could easily reproduce it: 
repo: g...@github.com:maggu2810/karaf-custom-distribution.git 
branch: dir-layout
Build it and test the custom artifact.



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

[jira] [Commented] (KARAF-3982) Be able to change standard files during distribution assembly

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3982:
---

Would be great if this could be integrated soon.

> Be able to change standard files during distribution assembly
> -
>
> Key: KARAF-3982
> URL: https://issues.apache.org/jira/browse/KARAF-3982
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-tooling
>Reporter: Jean-Baptiste Onofré
>
> The Karaf Maven plugin generates files (etc/org.apache.karaf.features.cfg, 
> etc). It would be great to mimic pax-exam to be able to change these 
> generated files (like put/append instructions).



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

[jira] [Commented] (KARAF-3982) Be able to change standard files during distribution assembly

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3982:
---

What do you think about add a flag to the extend operation to control if we do 
an append or a pretend?
If we would add another maven repository URL, it would make a significant 
difference if it is prepend or append.

> Be able to change standard files during distribution assembly
> -
>
> Key: KARAF-3982
> URL: https://issues.apache.org/jira/browse/KARAF-3982
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-tooling
>Reporter: Jean-Baptiste Onofré
>
> The Karaf Maven plugin generates files (etc/org.apache.karaf.features.cfg, 
> etc). It would be great to mimic pax-exam to be able to change these 
> generated files (like put/append instructions).



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

[jira] [Resolved] (KARAF-3762) feature resolver for system.bundle (equinox) faulty

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb resolved KARAF-3762.
---
   Resolution: Fixed
Fix Version/s: 4.0.1

> feature resolver for system.bundle (equinox) faulty
> ---
>
> Key: KARAF-3762
> URL: https://issues.apache.org/jira/browse/KARAF-3762
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature, karaf-kar
>Affects Versions: 4.0.0.M2
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.0.1
>
>
> I want to create a feature, that contains a jar (third party one). 
> The manifest of that bundle contains: 
> Require-Bundle: system.bundle 
> If I am using "karaf.framework=felix" all seems to be working. 
> If I am using "karaf.framework=equinox" and install the kar / feature that 
> contains that bundle I get the following message: 
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=karaf-oh2-feature; type=karaf.feature; 
> version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=karaf-oh2-feature)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
>  [caused by: Unable to resolve karaf-oh2-feature/1.0.0.SNAPSHOT: missing 
> requirement [karaf-oh2-feature/1.0.0.SNAPSHOT] osgi.identity; 
> osgi.identity=javax.activation; type=osgi.bundle; 
> version="[1.1.0.v201211130549,1.1.0.v201211130549]"; resolution:=mandatory 
> [caused by: Unable to resolve javax.activation/1.1.0.v201211130549: missing 
> requirement [javax.activation/1.1.0.v201211130549] osgi.wiring.bundle; 
> osgi.wiring.bundle=system.bundle; 
> filter:="(osgi.wiring.bundle=system.bundle)"]] 
> I can install that bundle using "bundle:install".
> If I retry to install the feature, I can install it now. 
> Here you could find a kar that demonstrate the problem: 
> https://drive.google.com/file/d/0Bx99QXY8p6gvY3BoMXlZeXRIOWs/view?usp=sharing
> kar:install should write the above error message in your log. 
> Installing the feature should trigger the error, too. 
> You can extract the jar (javax.activation) of that kar and will see, that you 
> are able to install it using bundle:install. 



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

[jira] [Commented] (KARAF-3762) feature resolver for system.bundle (equinox) faulty

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3762:
---

This is fixed at least with 4.0.1 (do not remember, but IMHO it was fixed with 
4.0.0).

> feature resolver for system.bundle (equinox) faulty
> ---
>
> Key: KARAF-3762
> URL: https://issues.apache.org/jira/browse/KARAF-3762
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature, karaf-kar
>Affects Versions: 4.0.0.M2
>Reporter: Markus Rathgeb
>Assignee: Jean-Baptiste Onofré
>
> I want to create a feature, that contains a jar (third party one). 
> The manifest of that bundle contains: 
> Require-Bundle: system.bundle 
> If I am using "karaf.framework=felix" all seems to be working. 
> If I am using "karaf.framework=equinox" and install the kar / feature that 
> contains that bundle I get the following message: 
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=karaf-oh2-feature; type=karaf.feature; 
> version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=karaf-oh2-feature)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
>  [caused by: Unable to resolve karaf-oh2-feature/1.0.0.SNAPSHOT: missing 
> requirement [karaf-oh2-feature/1.0.0.SNAPSHOT] osgi.identity; 
> osgi.identity=javax.activation; type=osgi.bundle; 
> version="[1.1.0.v201211130549,1.1.0.v201211130549]"; resolution:=mandatory 
> [caused by: Unable to resolve javax.activation/1.1.0.v201211130549: missing 
> requirement [javax.activation/1.1.0.v201211130549] osgi.wiring.bundle; 
> osgi.wiring.bundle=system.bundle; 
> filter:="(osgi.wiring.bundle=system.bundle)"]] 
> I can install that bundle using "bundle:install".
> If I retry to install the feature, I can install it now. 
> Here you could find a kar that demonstrate the problem: 
> https://drive.google.com/file/d/0Bx99QXY8p6gvY3BoMXlZeXRIOWs/view?usp=sharing
> kar:install should write the above error message in your log. 
> Installing the feature should trigger the error, too. 
> You can extract the jar (javax.activation) of that kar and will see, that you 
> are able to install it using bundle:install. 



--
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

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-2742:
---

Which one? Could you link the other Jira?
Will this also be fixed in 4.0.0.M3 or 4.0.0?

> 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: 3.0.4
>
> 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)

[jira] [Commented] (KARAF-3762) feature resolver for system.bundle (equinox) faulty

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3762:
---

This issue is realted to: 
http://karaf.922171.n3.nabble.com/4-0-0-M2-feature-install-system-bundle-td4040561.html

> feature resolver for system.bundle (equinox) faulty
> ---
>
> Key: KARAF-3762
> URL: https://issues.apache.org/jira/browse/KARAF-3762
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature, karaf-kar
>Affects Versions: 4.0.0.M2
>Reporter: Markus Rathgeb
>
> I want to create a feature, that contains a jar (third party one). 
> The manifest of that bundle contains: 
> Require-Bundle: system.bundle 
> If I am using "karaf.framework=felix" all seems to be working. 
> If I am using "karaf.framework=equinox" and install the kar / feature that 
> contains that bundle I get the following message: 
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=karaf-oh2-feature; type=karaf.feature; 
> version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=karaf-oh2-feature)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
>  [caused by: Unable to resolve karaf-oh2-feature/1.0.0.SNAPSHOT: missing 
> requirement [karaf-oh2-feature/1.0.0.SNAPSHOT] osgi.identity; 
> osgi.identity=javax.activation; type=osgi.bundle; 
> version="[1.1.0.v201211130549,1.1.0.v201211130549]"; resolution:=mandatory 
> [caused by: Unable to resolve javax.activation/1.1.0.v201211130549: missing 
> requirement [javax.activation/1.1.0.v201211130549] osgi.wiring.bundle; 
> osgi.wiring.bundle=system.bundle; 
> filter:="(osgi.wiring.bundle=system.bundle)"]] 
> I can install that bundle using "bundle:install".
> If I retry to install the feature, I can install it now. 
> Here you could find a kar that demonstrate the problem: 
> https://drive.google.com/file/d/0Bx99QXY8p6gvY3BoMXlZeXRIOWs/view?usp=sharing
> kar:install should write the above error message in your log. 
> Installing the feature should trigger the error, too. 
> You can extract the jar (javax.activation) of that kar and will see, that you 
> are able to install it using bundle:install. 



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

[jira] [Created] (KARAF-3762) feature resolver for system.bundle (equinox) faulty

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-3762:
-

 Summary: feature resolver for system.bundle (equinox) faulty
 Key: KARAF-3762
 URL: https://issues.apache.org/jira/browse/KARAF-3762
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature, karaf-kar
Affects Versions: 4.0.0.M2
Reporter: Markus Rathgeb


I want to create a feature, that contains a jar (third party one). 
The manifest of that bundle contains: 
Require-Bundle: system.bundle 

If I am using "karaf.framework=felix" all seems to be working. 


If I am using "karaf.framework=equinox" and install the kar / feature that 
contains that bundle I get the following message: 

Error executing command: Unable to resolve root: missing requirement [root] 
osgi.identity; osgi.identity=karaf-oh2-feature; type=karaf.feature; 
version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
filter:="(&(osgi.identity=karaf-oh2-feature)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
 [caused by: Unable to resolve karaf-oh2-feature/1.0.0.SNAPSHOT: missing 
requirement [karaf-oh2-feature/1.0.0.SNAPSHOT] osgi.identity; 
osgi.identity=javax.activation; type=osgi.bundle; 
version="[1.1.0.v201211130549,1.1.0.v201211130549]"; resolution:=mandatory 
[caused by: Unable to resolve javax.activation/1.1.0.v201211130549: missing 
requirement [javax.activation/1.1.0.v201211130549] osgi.wiring.bundle; 
osgi.wiring.bundle=system.bundle; 
filter:="(osgi.wiring.bundle=system.bundle)"]] 

I can install that bundle using "bundle:install".
If I retry to install the feature, I can install it now. 

Here you could find a kar that demonstrate the problem: 
https://drive.google.com/file/d/0Bx99QXY8p6gvY3BoMXlZeXRIOWs/view?usp=sharing

kar:install should write the above error message in your log. 
Installing the feature should trigger the error, too. 

You can extract the jar (javax.activation) of that kar and will see, that you 
are able to install it using bundle:install. 



--
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

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-2742:
---

Does this issue cover multiple issues?
The topic is "karaf-maven-plugin can not include filtered resources in a custom 
distribution" but it seems to me that the problem of overwriting configuration 
files in the etc directory of karaf is covered, too.

IMHO my problem is already described here 
http://karaf.922171.n3.nabble.com/karaf-assembly-and-config-files-td4032040.html
 and also covered by this topic.

I want to use a customized version of "etc/custom.properties"

Tested with karaf-maven-plugin-4.0.0-SNAPSHOT.

* Using the lines of the documentation and the custom.properties is stored at 
src/main/resources/etc, the archives (zip, tgz) contains custom.properties of 
Karaf.
* Using the lines above of "Mariusz Dubielecki" and the custom.properties is 
stored at src/main/resources/etc, the archives (zip, tgz) contains 
custom.properties of Karaf.
* Using the lines above of "Mariusz Dubielecki" and the custom.properties is 
stored at src/main/filtered-resources/etc, the archives (zip, tgz) contains 
custom.properties of mine.


> 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: 3.0.2, 4.0.0.M3
>
> 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)

[jira] [Comment Edited] (KARAF-3186) Upgrade to Equinox 3.10.0-v20140606-1445

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb edited comment on KARAF-3186 at 3/10/15 2:04 PM:


This is already solved:
{noformat}commit 2288055077711d6c7b2f12f18f0e848a743b3672
Author: Guillaume Nodet 
Date:   Mon Feb 16 15:04:07 2015 +0100

[KARAF-3481] Upgrade to OSGi r6{noformat}


was (Author: maggu2810):
This perhaps solved in current master:
commit 2288055077711d6c7b2f12f18f0e848a743b3672
Author: Guillaume Nodet 
Date:   Mon Feb 16 15:04:07 2015 +0100

[KARAF-3481] Upgrade to OSGi r6

> Upgrade to Equinox 3.10.0-v20140606-1445
> 
>
> Key: KARAF-3186
> URL: https://issues.apache.org/jira/browse/KARAF-3186
> Project: Karaf
>  Issue Type: Dependency upgrade
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.0.0
>
>




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

[jira] [Commented] (KARAF-3186) Upgrade to Equinox 3.10.0-v20140606-1445

[Markus Rathgeb (JIRA)]

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

Markus Rathgeb commented on KARAF-3186:
---

This perhaps solved in current master:
commit 2288055077711d6c7b2f12f18f0e848a743b3672
Author: Guillaume Nodet 
Date:   Mon Feb 16 15:04:07 2015 +0100

[KARAF-3481] Upgrade to OSGi r6

> Upgrade to Equinox 3.10.0-v20140606-1445
> 
>
> Key: KARAF-3186
> URL: https://issues.apache.org/jira/browse/KARAF-3186
> Project: Karaf
>  Issue Type: Dependency upgrade
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.0.0
>
>




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

[jira] [Created] (KARAF-3582) command extension: if one class failed inspection is stopped

[Markus Rathgeb (JIRA)]

Markus Rathgeb created KARAF-3582:
-

 Summary: command extension: if one class failed inspection is 
stopped
 Key: KARAF-3582
 URL: https://issues.apache.org/jira/browse/KARAF-3582
 Project: Karaf
  Issue Type: Bug
  Components: karaf-shell
Affects Versions: 4.0.0.M2
Reporter: Markus Rathgeb


Using a bundle with classes that could not be processed (e.g. a class could not 
be inspected cuased by a NoClassDefFound exception), will result in not loading 
other classes with command extensions.
We should skip classes that thrown an error, but proceed the other ones.
For example is a DS is optional (using optional requirements) and that one 
could not be loaded, we should be able to use command extensions that could be 
loaded.
Two possible fixes:
- handle ClassNotFoundException and NoClassDefFoundError only: 
https://github.com/maggu2810/karaf/commit/c95b90f2d1a8b09b2f3e048943bd93ea0e7b2077
- catch all exception for the current class: 
https://github.com/maggu2810/karaf/commit/4de92e86316e577af48b8ebcfd1ac8fb8195a04a



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