Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Markus Rathgeb]

Hi,

> - ignore requirement/capability (no resolver)

did I get it right that this breaks the dependency=true feature that
installs bundles / features only if a requirement is not fullfilled yet?

Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
patriquelega...@gmail.com>:

> Same here,
>
> This is behaviour that has been expected for some time now, reversing it
> could cause damage to systems that upgrade to the latest Karaf. I would
> make it something that users opt into vs having to opt-out of.
>
> On Fri, 8 Jan 2021 at 08:42, Daniel Las 
> wrote:
>
> > Hi,
> >
> > It looks like some kind of backward incompatible change introduced within
> > patch version change. I personally would like to keep auto refresh "on"
> by
> > default as this is expected/desired behavior for me.
> >
> > Regards
> >
> > pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre 
> napisał(a):
> >
> > > Hi everyone,
> > >
> > > We got several user feedback, complaining about unexpected and cascaded
> > > (unrelated) refresh while installing features.
> > >
> > > As reminder, a refresh can happen when:
> > > - bundle A imports package foo:1 and a bundle provides newer foo
> package
> > > version. In that case, the features service will refresh A to use the
> > > newest package version.
> > > - bundle A has an optional import to package foo and a bundle provides
> > > this package. In that case, the features service will refresh A to
> > actually
> > > use the import as it’s a "resolved" optional.
> > > - bundle A is wired to bundle B (from a package perspective or
> > > requirement) and B is refreshed. In that case, the features service
> will
> > > refresh A as B is itself refreshed (for the previous reasons for
> > instance).
> > > This can cause "cascading" refresh.
> > >
> > > A refresh means that a bundle can be restarted (if the bundle contains
> an
> > > activator or similar (DS component, blueprint bundle)).
> > >
> > > In this PR https://github.com/apache/karaf/pull/1287, I propose to
> > > introduce a new property autoRefresh in
> etc/org.apache.karaf.features.cfg
> > > to disable the auto refresh by the features service (and let the user
> > > decides when he wants to trigger refresh with bundle:refresh command
> for
> > > instance).
> > > I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
> on
> > > 4.3.x.
> > >
> > > Thoughts ?
> > >
> > > On the other hand (and to prepare the "path" to Karaf5), I have
> created a
> > > new "simple features service" (PR will be open soon) that:
> > >
> > > - just take the features definition in order (ignoring start level)
> > > - ignore requirement/capability (no resolver)
> > > - no auto refresh
> > >
> > > Basically, if you have the following feature definition:
> > >
> > > 
> > >   bar
> > >  A
> > >  B
> > > 
> > >
> > > The features service will fully install/start bar feature first, then
> > > bundle A, then bundle B.
> > > To use this "simple features services, you just have to replace
> > > org.apache.karaf.features.core by org.apache.karaf.features.simple
> bundle
> > > in etc/startup.properties (or custom distribution).
> > >
> > > It’s similar to the Karaf 5 extension behavior (I will share complete
> > > details about Karaf 5 and its concepts (module, extension, …) very
> soon,
> > > but that’s another thread ;)).
> > >
> > > The big advantages of this approach is:
> > > - predictable/deterministic provisioning (if it works fine, it works
> > again)
> > > - faster deployment (I estimated the gain to about 70%)
> > >
> > > Thoughts ?
> > >
> > > If you agree, I will move forward on both tasks.
> > >
> > > Thanks,
> > > Regards
> > > JB
> > >
> >
> >
> > --
> > Daniel Łaś
> > CTO at Empirica S.A.
> > +48 695 616181
> >
>
>
> --
> *Patrique Legault*
>

Re: [HEADS UP] Releases plan: Decanter 2.3.0 and Karaf 4.2.9/4.3.0

[Markus Rathgeb]

Hi,

thank you for your.
Is there any change to get the c'n'p error (caused by jline) fixed for
4.2.9?

Best regards,
Markus

Grzegorz Grzybek  schrieb am Do., 19. März 2020,
06:36:

> Hello
>
> I can say only about Karaf 4.3.0. I'm indeed working on Pax Web 8 (I'm
> finally at the stage where I can actually push some (almost) atomic
> changes. Initially it was just 100+ files changed at once). Current state
> can be checked in master-improvements branch
> .
>
> I found just too many places in Pax Web 7 that were just too much against
> R6 specification and I needed ... more changes than I planned. Even if I've
> not reviewed yet pax-web-extender-war, I've rebuilt the foundation so
> seriously with both WAR and Whiteboard extenders in mind that it should be
> easier to progress now.
>
> The most important change in Pax Web 8 now is that there's clear
> distinction between "OSGi Context Model" and "Servlet Context Model". Here
> are some requirements that stem directly from specification and I've
> already implemented them:
>
>- "Servlet Context Model" is in 1:1 relation with actual servlet context
>(or single, unique "context path" like "/c1")
>- "OSGi Context Model" is in 1:1 relation with HttpContext (from Http
>Service spec) or ServletContextHelper (from Whiteboard Service spec).
> Such
>"OSGi context" "points to" single "Servlet Context"
>- *but* there may be many "OSGi Context Models" pointing to single
>"Servlet Context Model"
>- *also*, single Whiteboard-registered servlet may be associated with
>many "OSGi Context Models"
>
> The implications are sometimes amazing:
>
>- a servlet may be registered to many "OSGi Context Models", which point
>to different "Servlet Context Models" - this means servlet /s may be
>available under /c1/s and /c2/s
>- a servlet may be registered to many "OSGi Context Models", which point
>to *the same* "Servlet Context Models" - this means servlet /s may be
>available under /c/s but handleSecurity() is taken from "OSGi Context
>Model" with highest ranking - Pax Web 7 didn't do that at all
>- a filter may be mapped to /* and be associated with many "OSGi Context
>Models", but should be added to filter chain ONLY if the chain ends
> with a
>servlet associated with matching "OSGi Context Model"
>- a servlet associated wtih "OSGi Context Model" point to, say, /c1
>"Servlet Context" is available at, say, /c1/s. But when service
>registration properties for the associated ServletContextHelper (1:1
> with
>"OSGi Context Model") change, servlet has to "switch" from /c1/s to,
> say,
>/c2/s (or even /s when given "OSGi Context Model" starts being
> associated
>with the default "Servlet Context Model"
>
> So, you see (I hope) that Pax Web 8 is not going to be an easy release ;)
> But I really try hard now...
>
> regards
> Grzegorz Grzybek
>
> czw., 19 mar 2020 o 05:35 Jean-Baptiste Onofre 
> napisał(a):
>
> > Hi everyone,
> >
> > First of all, I’m sorry for the ones who are on Slack, I have some
> > connection issues since yesterday morning. It should be fixed by the end
> of
> > today max.
> >
> > Anyway, I would like to move forward about the releases.
> >
> > For this week, I would like to submit to vote:
> >
> > - Decanter 2.3.0: it’s a major (very major ;)) release bringing new
> > features (new alerting service with much better condition, time series,
> > Prometheus appender, new collectors, …), updates (Elasticsearch 7
> support,
> > …) and fixes. I’m rebasing and polishing branches, I hope to submit
> > Decanter release to vote during the week end.
> > - Karaf 4.2.9, even if it doesn’t contain as much as 4.2.8, I would like
> > to submit this release to vote as it contains the fix about HTTPs access
> to
> > Maven Central. As for Decanter, I plan the start the vote during the week
> > end or early next week.
> > - Karaf 4.3.0. We released 4.3.0.RC1 some weeks ago. Unfortunately we
> > didn’t get lot of feedback. So, even if Pax Web is not fully ready for
> OSGi
> > R7 (thanks again to Greg for working hard on this), I propose to move
> > forward on 4.3.0 "as it is". Thoughts ?
> >
> > Regards
> > JB
>

Re: [VOTE] Apache Karaf Runtime 4.2.8 release (take #2)

[Markus Rathgeb]

+1 (non-binding)

Thanks!

Am Mo., 20. Jan. 2020 um 13:27 Uhr schrieb Fabian Lange
:
>
> +1 (non-binding)
>
> findings:
> * pax-logging + knoplerfish issue resolved
> * wrap + logging dependency/ordering issue resolved
> * https://issues.apache.org/jira/browse/KARAF-2925 - IMHO this should
> be fixed. Karaf now ships a 10 year old unmaintained early access jar
> with no source or licensing info on the boot classpath
> (https://github.com/apache/karaf/commit/364a98078cb007500af9718a9a443eb4745b)
>
> tested with java 8 on mac only.
>
> Fabian
>
> On Mon, Jan 20, 2020 at 8:19 AM Francois Papon
>  wrote:
> >
> > +1 (binding)
> >
> > regards,
> >
> > François
> > fpa...@apache.org
> >
> > Le 19/01/2020 à 22:49, Jean-Baptiste Onofré a écrit :
> > > Hi all,
> > >
> > > I submit Apache Karaf runtime 4.2.8 to your vote. This is a
> > > maintenance release on the 4.2.x series, bringing updates, improvements
> > > and fixes.
> > >
> > > Release Notes:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12346100
> > >
> > > Staging Repository:
> > > https://repository.apache.org/content/repositories/orgapachekaraf-1138
> > >
> > > Staging Dist:
> > > https://dist.apache.org/repos/dist/dev/karaf/4.2.8/
> > >
> > > Git Tag:
> > > karaf-4.2.8
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Don't approve the release (please provide specific comments)
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > Thanks,
> > > Regards
> > > JB

Re: [VOTE] Apache Karaf runtime 4.2.8 release

[Markus Rathgeb]

+1

I suggest that the non working multi part handling should be added to
a known issue for 4.2.7 and 4.2.8. So it is at least visible for
everyone who looks for known issues in front of migration.
I worked around the problem in my custom distributions.

Am Mi., 15. Jan. 2020 um 05:41 Uhr schrieb Jean-Baptiste Onofré
:
>
> IMHO, it's not 4.2.8 blocker. I can always do 4.2.9 very fast if needed.
>
> Regards
> JB
>
> On 14/01/2020 21:27, Markus Rathgeb wrote:
> > Hm, for me it depends if the multi part stuff that has been broken on
> > 4.2.7 is working again (so depends on the findings of the respective
> > thread on the user mailing list).
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Apache Karaf runtime 4.2.8 release

[Markus Rathgeb]

Hm, for me it depends if the multi part stuff that has been broken on
4.2.7 is working again (so depends on the findings of the respective
thread on the user mailing list).

Re: R7 Configurator Spec. 1.0: start level

[Markus Rathgeb]

Hi,

> The system bundles start level depends of the bundles in
> etc/startup.properties and boot features. It's not really Karaf related
> (only for the Karaf inner features).

Sure, start level itself are not Karaf related at all, but the
question has been more about "how are the start level chosen that are
used by the (official) Karaf features".

> So, concretely, I would do SPI Fly 30, Johnzon Core 31 and Configurator
> 31 for the start level.

Shouldn't the configurator started "as soon as possible"?
All services should act correctly if configuration changes, but if the
configuration is applied before services starts the first time, we
could reduce the re-start of services because the configuration
changes.
So, I assume it will reduce the load and the time of being fully up
(with correct configuration) on every restart if the configuator and
the bundles providing configuration are started as soon as possible.

IIRC SPI Fly does not depend on any other bundle (except the core
framework), so it could make sense to start it earlier (e.g. 20)

> In Karaf 4.3.x, you will have Configurator as part of the config feature.

I don't know which JSON-P implementation you are choosing, because I
cannot find the config feature using the configurator in the master
branch, but Johnzon Core also just depend on the API bundle.

The question for me has been if it would make sense to use e.g. 25 for
the configurator, so user provided configuration (custom distribution)
can choose a startlevel between 26 (inclusive) and 29 (inclusive) to
inject a configuration before the other "Karaf inner features" are
started (so the configuration is already used).

Best regards,
Markus

R7 Configurator Spec. 1.0: start level

[Markus Rathgeb]

Hi,

after starting to use the configurator
(https://osgi.org/specification/osgi.cmpn/7.0.0/service.configurator.html)
I created a Karaf feature, so I can use my bundles in Karaf, too.

Here is just a snapshot of a working one:
https://github.com/maggu2810/playground-osgi/blob/5a7629e/features/runtime/src/main/feature/feature.xml

org.apache.felix/org.apache.felix.configurator/1.0.10 needs an
JSON-P_1.1 (JSR-353) implementation.
This is provided e.g. by johnzon-core.

The implementation is accessed by the service loader (SPI), so I used
org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2.3

The JSON-P implementation needs to be provided by the service loader
as soon as the configurator is started.
What's your intention (I assume you will add such a feature to Karaf
4.3) about the start-levels?

Is there an official guideline about the choose (e.g. 5, 20, 30, ...)
of start-level and how Karaf defines it in its official features?

SPI Fly uses 30 in the official Karaf features.
We could use > 30 for the configurator and ensure Johnzon Core also
uses =30 or what's your suggestion?

Thanks in advance,
Markus

Karaf 4.2.5 + Equinox + SCR: error

[Markus Rathgeb]

Hi,

is it already known that using Equinox on Karaf 4.2.5 will result into
an exception if the "scr" feature is installed?

* Unpack official distribution (tar xzf apache-karaf-4.2.5.tar.gz)
* Edit "etc/custom.properties" and add the line "karaf.framework = equinox"
* start Karaf
* install SCR feature (feature:install scr)
* identify an error

===
karaf@root()> feature:install scr
org.apache.karaf.features.internal.util.MultiException: Error
restarting bundles:
Exception in org.apache.felix.scr.impl.Activator.start() of
bundle org.apache.felix.scr.
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1005)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1058)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:994)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: org.osgi.framework.BundleException: Exception in
org.apache.felix.scr.impl.Activator.start() of bundle
org.apache.felix.scr.
at
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:836)
at
org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:765)
at
org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
at
org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357)
at org.eclipse.osgi.container.Module.doStart(Module.java:589)
at org.eclipse.osgi.container.Module.start(Module.java:457)
at
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:431)
at
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:450)
at
org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:161)
at
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1149)
at
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:997)
... 6 more
Caused by: java.lang.AbstractMethodError:
org.ops4j.pax.logging.log4j2.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.getLogger(Ljava/lang/String;Ljava/lang/Class;)Lorg/osgi/service/log/Logger;
at
org.apache.felix.scr.impl.logger.R7LogServiceLogger.(R7LogServiceLogger.java:35)
at
org.apache.felix.scr.impl.logger.LogServiceSupport.getLogger(LogServiceSupport.java:69)
at
org.apache.felix.scr.impl.logger.LogServiceEnabledLogger.getLogger(LogServiceEnabledLogger.java:106)
at
org.apache.felix.scr.impl.logger.AbstractLogger.isLogEnabled(AbstractLogger.java:71)
at
org.apache.felix.scr.impl.logger.AbstractLogger.log(AbstractLogger.java:90)
at
org.apache.felix.scr.impl.Activator.restart(Activator.java:137)
at
org.apache.felix.scr.impl.config.ScrConfigurationImpl.configure(ScrConfigurationImpl.java:217)
at
org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:120)
at org.apache.felix.scr.impl.Activator.start(Activator.java:100)
at
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:815)
at
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:808)
... 16 more
Error executing command: Error restarting bundles:
Exception in org.apache.felix.scr.impl.Activator.start() of
bundle org.apache.felix.scr.
===

Best regards,
Markus

Re: Apache karaf with osgi 7

[Markus Rathgeb]

Hi,

just want to know what's the current state.

The download page still states an ETA of "2 Mar 19".
Can you update the ETA for the RC1?


Am Sa., 23. März 2019 um 08:05 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi,
>
> I said previously on the mailing list, OSGi R7 support is planned for
> Karaf 4.3.x.
>
> A first 4.3.0.RC1 will be released soon, R7 updates are already on the
> way as PR (new framework, etc).
>
> Regards
> JB
>
> On 23/03/2019 07:40, amwangi4 wrote:
> > Hi guys, is there a way we could have apache karaf with the latest osgi 
> > specs
> > i.e osgi R7.
> >
> >
> >
> >
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf: Java detection on Karaf

[Markus Rathgeb]

Thanks!

Am Fr., 8. März 2019 um 06:29 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> for the tracking:
>
> https://issues.apache.org/jira/browse/KARAF-6189
>
> Regards
> JB
>
> On 07/03/2019 10:57, Markus Rathgeb wrote:
> > Hi JBO,
> >
> > any news about your findings?
> >
> > Best regards,
> > Markus
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf: Java detection on Karaf

[Markus Rathgeb]

Hi JBO,

any news about your findings?

Best regards,
Markus

Re: Karaf: Java detection on Karaf

[Markus Rathgeb]

I assume you just need to create a file "/etc/gentoo-release" and mark
it readable for your user.

Am Di., 5. März 2019 um 16:49 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> you are right: I'm on Debian but not with java provided package.
>
> On my system, I manually installed java in /opt/java and define
> JAVA_HOME in /etc/profile.
>
> It seems in your case that JAVA_HOME is not considered. Let me try to
> reproduce playing with the env variables.
>
> Regards
> JB
>
> On 05/03/2019 16:35, Markus Rathgeb wrote:
> > Hi JBO,
> >
> >> I don't think java-config is used if you have JAVA_HOME defined right ?
> >> (it's what I have on my systems).
> >
> > You are using Gentoo / have a readable file "/etc/gentoo-release" and
> > you also did not install the system wide java support?
> > What a remarkable coincidence.
> >
> > I wonder why it is working on your system.
> > My reading of the scripts indicates the problem should exist in this
> > constellation.
> >
> > Please have a look at the output following information:
> >
> >
> > Here my current JAVA_HOME:
> > ===
> > $ echo $JAVA_HOME
> > /home/rathgeb/bin/pkgs/java/jdk/8/current
> > ===
> >
> > As you can see java is part of the PATH
> > ===
> > $ command -v java
> > /home/rathgeb/bin/pkgs/java/jdk/8/current/bin/java
> > ===
> >
> > The current java version is
> > ===
> > $ java -version
> > java version "1.8.0_202"
> > Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
> > Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)
> > ===
> >
> > Now let's start Karaf
> > ===
> > $ bin/karaf
> > /home/rathgeb/workspace/projects-oss/karaf/bin/apache-karaf-4.3.0-SNAPSHOT/bin/inc:
> > line 198: java-config: command not found
> > karaf: JAVA_HOME not set; results may vary
> > karaf: Enabling Java debug options:
> > -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
> > Listening for transport dt_socket at address: 5005
> > __ __  
> >/ //_/ __ _/ __/
> >   / ,<  / __ `/ ___/ __ `/ /_
> >  / /| |/ /_/ / /  / /_/ / __/
> > /_/ |_|\__,_/_/   \__,_/_/
> >
> >   Apache Karaf (4.3.0-SNAPSHOT)
> >
> > Hit '' for a list of available commands
> > and '[cmd] --help' for help on a specific command.
> > Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> >
> > karaf@root()>
> > ===
> >
> > You see the message
> > ===
> > /home/rathgeb/workspace/projects-oss/karaf/bin/apache-karaf-4.3.0-SNAPSHOT/bin/inc:
> > line 198: java-config: command not found
> > ===
> >
> > So, please have a look at:
> > https://github.com/apache/karaf/blob/8c3dda1/assemblies/features/base/src/main/filtered-resources/resources/bin/inc#L187-L217
> >
> > ===
> > if [ "x${JAVA}" = "x" ] && [ -r /etc/gentoo-release ] ; then
> > JAVA_HOME=$(java-config --jre-home)
> > fi
> > ===
> >
> > If the environment JAVA is not set (AFAIK this is not a commonly used
> > one) and there is a readable "/etc/gentoo-release" file, JAVA_HOME is
> > set by using "java-config" -- regardless if the tool is present.
> >
> > The "locateJava" method is called by e.g. the init method of Karaf.
> >
> >
> >
> >> but you can define JAVA_HOME in bin/inc right ?
> >
> > Sure, I can modify "bin/inc" all the time I unpack the official 
> > distribution.
> > But is this what you would like to tell users?
> > e.g. "If you unpack the official distribution and use Gentoo without
> > "java-config" present, please edit the "bin/inc" file in front of
> > starting karaf."
> > I don't think this is nice if we could modify the script so no
> > interaction is necessary.
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf: Java detection on Karaf

[Markus Rathgeb]

Hi JBO,

> I don't think java-config is used if you have JAVA_HOME defined right ?
> (it's what I have on my systems).

You are using Gentoo / have a readable file "/etc/gentoo-release" and
you also did not install the system wide java support?
What a remarkable coincidence.

I wonder why it is working on your system.
My reading of the scripts indicates the problem should exist in this
constellation.

Please have a look at the output following information:


Here my current JAVA_HOME:
===
$ echo $JAVA_HOME
/home/rathgeb/bin/pkgs/java/jdk/8/current
===

As you can see java is part of the PATH
===
$ command -v java
/home/rathgeb/bin/pkgs/java/jdk/8/current/bin/java
===

The current java version is
===
$ java -version
java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)
===

Now let's start Karaf
===
$ bin/karaf
/home/rathgeb/workspace/projects-oss/karaf/bin/apache-karaf-4.3.0-SNAPSHOT/bin/inc:
line 198: java-config: command not found
karaf: JAVA_HOME not set; results may vary
karaf: Enabling Java debug options:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
Listening for transport dt_socket at address: 5005
__ __  
   / //_/ __ _/ __/
  / ,<  / __ `/ ___/ __ `/ /_
 / /| |/ /_/ / /  / /_/ / __/
/_/ |_|\__,_/_/   \__,_/_/

  Apache Karaf (4.3.0-SNAPSHOT)

Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.

karaf@root()>
===

You see the message
===
/home/rathgeb/workspace/projects-oss/karaf/bin/apache-karaf-4.3.0-SNAPSHOT/bin/inc:
line 198: java-config: command not found
===

So, please have a look at:
https://github.com/apache/karaf/blob/8c3dda1/assemblies/features/base/src/main/filtered-resources/resources/bin/inc#L187-L217

===
if [ "x${JAVA}" = "x" ] && [ -r /etc/gentoo-release ] ; then
JAVA_HOME=$(java-config --jre-home)
fi
===

If the environment JAVA is not set (AFAIK this is not a commonly used
one) and there is a readable "/etc/gentoo-release" file, JAVA_HOME is
set by using "java-config" -- regardless if the tool is present.

The "locateJava" method is called by e.g. the init method of Karaf.



> but you can define JAVA_HOME in bin/inc right ?

Sure, I can modify "bin/inc" all the time I unpack the official distribution.
But is this what you would like to tell users?
e.g. "If you unpack the official distribution and use Gentoo without
"java-config" present, please edit the "bin/inc" file in front of
starting karaf."
I don't think this is nice if we could modify the script so no
interaction is necessary.

Karaf: Java detection on Karaf

[Markus Rathgeb]

Hi,

I recently decided to remove my system wide Java installation from my
Gentoo machine.
I don't need it system wide.

I am the only user of that system that needs Java -- to be more
precise I am the only user of the system at all.

Additionally I switch between different Java versions and dstributions
for testing purposes.

I ensure that a java is present in a directory that is part of the
PATH environment variable.
Additionally I set JAVA_HOME to the desired location.

All tools still work as expected.

BUT: I realized that Karaf does not work as expected anymore.

It is caused by the function "locateJava" in
"./assemblies/features/base/src/main/filtered-resources/resources/bin/inc".
If the environment JAVA is not set and the file "/etc/gentoo-release"
is readable, JAVA_HOME is set to the output of "java-config
--jre-home".
"java-config" does not exist on my system at all.
It is only present if you install global Java support on the Gentoo
machine, so it is optional.

I also wonder why JAVA_HOME is not, if it is already set?

There are several options:
* If JAVA_HOME is set, keep it as it is.
* If JAVA / JAVA_HOME is not set /etc/gentoo-release is present AND
java-config is executable, execute it.
* ...

WDYT?
Why is there a requirement for "java-config" on Gentoo?
Why is "java-config" used if I already set JAVA_HOME to a specific
Java location?

Best regards,
Markus

Re: [VOTE] Apache Karaf (runtime) 4.2.2 release

[Markus Rathgeb]

+1 (non-binding)

Re: [VOTE] Apache Karaf "Container" 4.2.1 release

[Markus Rathgeb]

+1 (non-binding)

K420: pax-jetty-http2 Crash and ResolutionException

[Markus Rathgeb]

Hi,

it seems that the feature "pax-jetty-http2" does not work.

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

Start Karaf:
===
apache-karaf-4.2.0/bin/karaf
===



Reproduce ResolutionException


Install feature:
===
feature:install pax-jetty-http2
===

Error message:
===
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)))"
===



Reproduce Crash


Install whiteboard feature
===
karaf@root()> feature:install pax-http-whiteboard
===

Install http2 feature
===
karaf@root()> feature:install pax-jetty-http2
===

Crash of Karaf (KAraf is terminated after the message):
===
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.eclipse.equinox.internal.region.BundleIdBasedRegion.installBundleAtLocation(BundleIdBasedRegion.java:97)
at 
org.apache.karaf.features.internal.service.BundleInstallSupportImpl.installBundle(BundleInstallSupportImpl.java:135)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.installBundle(FeaturesServiceImpl.java:1101)
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:870)
at 

Re: [VOTE] Apache Karaf (Container) 4.2.0 release (take 2)

[Markus Rathgeb]

+1 (non-binding)

2018-04-05 8:15 GMT+02:00 Grzegorz Grzybek :
> Hello, I just built the *new* 4.2.0 tag and I'm performing my tests.
>
> regards
> Grzegorz Grzybek
>
> 2018-04-05 8:03 GMT+02:00 Jean-Baptiste Onofré :
>
>> Hi all,
>>
>> I submit Karaf (Container) 4.2.0 release to your vote.
>>
>> This is the first GA on the 4.2.x series, following M1 and M2.
>>
>> NB: I preferred to postpone the merge of the new examples as it needs a
>> little
>> polish. The PR is already available and it will be included in 4.2.1 (that
>> we
>> can expect beginning of May depending of 4.2.0 feedbacks):
>> https://github.com/apache/karaf/pull/484
>>
>> NB: This is take 2, including KARAF-5688 fix
>>
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12311140=12342076
>>
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-/
>>
>> Git Tag:
>> karaf-4.2.0
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>>
>> This vote will be open for at least 72 hours.
>>
>> Thanks,
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>

Re: [VOTE] Apache Karaf (Container) 4.2.0 release

[Markus Rathgeb]

I need to further inspect this error, but got this one using a custom
distribution with some third party bundles:

11:01:57.410 INFO [features-3-thread-1] Pax Web started
11:01:57.446 INFO [features-3-thread-1]   org.apache.aries.jmx.whiteboard/1.2.0
11:01:57.534 ERROR [paxweb-config-1-thread-1] Unable to start pax web
server: Duplicate method name
"$$FCCL$$java#util#ServiceLoader$load$java#lang#Class" with signature
"(Ljava.lang.Class;)V" in class file
org/eclipse/jetty/http/PreEncodedHttpField
java.lang.ClassFormatError: Duplicate method name
"$$FCCL$$java#util#ServiceLoader$load$java#lang#Class" with signature
"(Ljava.lang.Class;)V" in class file
org/eclipse/jetty/http/PreEncodedHttpField
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1414)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1660)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1590)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerImpl.(JettyServerImpl.java:97)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.JettyFactoryImpl.createServer(JettyFactoryImpl.java:90)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl$Stopped.start(ServerControllerImpl.java:443)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.start(ServerControllerImpl.java:81)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerFactoryImpl$1.start(ServerControllerFactoryImpl.java:164)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl$Unconfigured.configure(ServerControllerImpl.java:788)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.configure(ServerControllerImpl.java:97)
~[?:?]
at 
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:347)
~[?:?]
at 
org.ops4j.pax.web.service.internal.Activator.lambda$scheduleUpdateFactory$2(Activator.java:291)
~[?:?]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
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) [?:?]


2018-04-04 9:22 GMT+02:00 Christian Schneider :
> I found two issues until now:
>
> - When you start karaf on windows, then stop with Ctrl-D the java process
> does not end.
> - There is org.osgi.core-6.0.0.jar in the boot dir. I doubt it should be
> part of the deployment.
>
> Christian
>
> 2018-04-03 10:25 GMT+02:00 Jean-Baptiste Onofré :
>
>> Hi all,
>>
>> I submit Karaf (Container) 4.2.0 release to your vote.
>>
>> This is the first GA on the 4.2.x series, following M1 and M2.
>>
>> NB: I preferred to postpone the merge of the new examples as it needs a
>> little
>> polish. The PR is already available and it will be included in 4.2.1 (that
>> we
>> can expect beginning of May depending of 4.2.0 feedbacks):
>> https://github.com/apache/karaf/pull/484
>>
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12311140=12342076
>>
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-1110/
>>
>> Git Tag:
>> karaf-4.2.0
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>>
>> This vote will be open for at least 72 hours.
>>
>> Thanks,
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - 

Re: [heads up - long] "Features Processor" that replaces overrides and blacklisting (and more)

[Markus Rathgeb]

Hi Grzegorz,

I just read your mails what you implement and IMHO it is a big improvement.
If I find some time I will try to test some of your changes.
But I see forward to see that features upstream and will be happy to
use them in my custom distributions.

Thanks a lot for your work.

Re: [VOTE] Apache Karaf (Container) 4.1.1 release

[Markus Rathgeb]

Has someone tested the Spring MVC feature / bundles?

I have a bundle that is using the Spring MVC and worked before.
In K4.1.1 staging I receive an error while bundle start

===
2017-03-30 11:37:56,973 | ERROR | ender-1-thread-1 | DispatcherServlet
   | 132 - org.apache.servicemix.bundles.spring-webmvc -
4.3.5.RELEASE_1 | Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter':
Instantiation of bean failed; nested exception is
org.springframework.beans.BeanInstantiationException: Failed to
instantiate 
[org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter]:
Constructor threw exception; nested exception is
java.lang.NoClassDefFoundError:
com/fasterxml/jackson/core/util/DefaultIndenter
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1116)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1060)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:513)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:759)
~[125:org.apache.servicemix.bundles.spring-beans:4.3.5.RELEASE_1]
at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:866)
~[126:org.apache.servicemix.bundles.spring-context:4.3.5.RELEASE_1]
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:542)
~[126:org.apache.servicemix.bundles.spring-context:4.3.5.RELEASE_1]
at 
org.springframework.web.servlet.FrameworkServlet.configureAndRefreshWebApplicationContext(FrameworkServlet.java:668)
~[132:org.apache.servicemix.bundles.spring-webmvc:4.3.5.RELEASE_1]
at 
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:634)
~[132:org.apache.servicemix.bundles.spring-webmvc:4.3.5.RELEASE_1]
at 
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:682)
~[132:org.apache.servicemix.bundles.spring-webmvc:4.3.5.RELEASE_1]
at 
org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:553)
~[132:org.apache.servicemix.bundles.spring-webmvc:4.3.5.RELEASE_1]
at 
org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:494)
~[132:org.apache.servicemix.bundles.spring-webmvc:4.3.5.RELEASE_1]
at 
org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
~[132:org.apache.servicemix.bundles.spring-webmvc:4.3.5.RELEASE_1]
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
~[52:javax.servlet-api:3.1.0]
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:640)
~[155:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:419)
~[155:org.eclipse.jetty.servlet:9.3.14.v20161028]
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:892)
~[155:org.eclipse.jetty.servlet:9.3.14.v20161028]
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:349)
~[155:org.eclipse.jetty.servlet:9.3.14.v20161028]
at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.startContext(HttpServiceContext.java:432)
~[265:org.ops4j.pax.web.pax-web-jetty:6.0.3]
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:778)
~[154:org.eclipse.jetty.server:9.3.14.v20161028]
at 

Re: [VOTE] Apache Karaf (Container) 4.1.0 release, RC#2

[Markus Rathgeb]

+1 (non-binding)

Re: [VOTE] Apache Karaf (Container) 4.0.8 release

[Markus Rathgeb]

Hi,

+1 (non-binding)

I tested K408 staging on a Raspberry Pi 2 Model B, too and it seems to
be working (KARAF-4714).

Best regards,
Markus

Re: [HEADS UP] Next releases

[Markus Rathgeb]

Hi,

> Karaf 4.0.8 is plan for the end of this week and next week. Unfortunately,
> it seems that the ARM/Solaris issue with jansi is not fully fixed. I have to
> find a way to reproduce and fix it.

when I am on the way, without access to my ARM devices, I am using
qemu to emulate a ARM machine.
I am using this script to setup my qemu Arch Linux ARM VMs:
https://github.com/maggu2810/qemu-utils

Best regards,
Markus

Re: [HEADS UP] Next releases

[Markus Rathgeb]

> -- Container 4.0.8: the ARM/Solaris issue should be fixed now (that was an
> important regression in 4.0.6 & 4.0.7). Other fixes and upgrades are coming
> too.

I tested the recent snapshot, but this does not work for me.
See JIRA

Re: [VOTE] Apache Karaf (Container) 4.0.7 release

[Markus Rathgeb]

Hi Svetoslav,

I assume the same as JB already stated to me
"https://lists.apache.org/thread.html/d19fda54132fbe9f16ee1caf621122c8e3a8feea1d2bc501d725a9ff@%3Cdev.karaf.apache.org%3E;
fits here.
"As said during 4.0.6 vote, 4.0.7 is first to upgrade Pax Web and fix
the  service enforcement and include some other bug fixes."

I am fine to stay on 4.0.5 and wait for 4.0.8 that hopefully contains
that fixes.
But if 4.0.7 targets to fix only specific 4.0.6 bugs (+upgrades) I
don't think the release should be cancelled.

Re: [VOTE] Apache Karaf (Container) 4.0.7 release

[Markus Rathgeb]

Hi JB,

isn't the missing support of the ARM architecture for the Karaf Shell
a blocker for a release?
I have not tested K407 but I assume it has not been fixed as the Jira
is still open: https://issues.apache.org/jira/browse/KARAF-4714
It is okay for myself, I can still using K405 but it would be great if
new releases don't break the support of a whole processor
architecture.

Best regards,
Markus

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

> I propose:
> - don't cancel this vote as it's an expected behavior
> - fix the service capability in Pax Web

> Thoughts ?

One remaining question:
The Pax Web version and so the Pax Web features that are shipped with
Karaf 4.0.6 will contain the service capability or do not have the
capability?

Re: [DISCUSS] Service capabilities (was: [VOTE] Apache Karaf (Container) 4.0.6 release)

[Markus Rathgeb]

Hi,

let me give you a short summary of the background / the situation I
run into the problem:

There is an Eclipse project "Eclipse SmartHome" (ESH) that provides a
framework / a collection of bundles that could be used to create a
smarthome system (open source, commercial, whatever / doesn't matter).
The project is using (AFAIK common for Eclipse projects) the Manifest
first approach.
So, no tool that creates the manifest, but handwritten (with Eclipse
PDE support) manifests.
The OSGi version that is choosen by the project is OSGi R4.2.

There is no "Provide-Capability" used ATM and I don't think any
developer will maintain this one.
I am a committer of that project, but I don't think I am able to
change the manifest first approach.

I have created Karaf feature some time ago for the Eclipse SmartHome
project that could be consumed by products / custom distributions,
because I like Karaf and would like to support the usage of Karaf and
Eclipse SmartHome.
* 
https://github.com/eclipse/smarthome/blob/master/features/karaf/src/main/feature/feature.xml
* 
https://github.com/eclipse/smarthome/blob/master/features/karaf-tp/src/main/feature/feature.xml

As written above, the bundles are missing the Provide-Capability
entries in their manifest.

The project is under development and there are a lot of changes all the time.
The developers will not add (IMHO) this entries to the manifest.
I have no time to check every commit and add / remove / change
"Capability" nodes in the ESH Feature XML all the time.

The products that are using Karaf and the ESH features provides
bundles and features itself.
Some of that bundles are created using the maven-bundle-plugin, the
bnd-maven-plugin, Bndtools, ...
That bundles have a Require-Capability entry in their manifest.

The products create features for their bundles / functions and depend
on the Eclipse SmartHome feature.

As the ESH Karaf Features are using "dependency" attributes in their
XML they need to use >= v1.3.0.

The problem is, that the feature verification (regardless if it is
used by the karaf-maven-plugin or at runtime on feature installation)
fails with K406 but works with K405.

I already learned that it has been a bug that the feature verification
has been working using XML NS1.4.0. It fails with 1.3.0 only but
should fail with >= 1.3.0.
So, it has been working, but it shouldn't. I understand

> 

That is something I already posted as an idea today on IRC.
Perhaps that would be possible.

I hope you understand the situation I want to describe above.

Have you some tips how what we could do?
I assume the best solution would be if the ESH bundles' manifest have
an "Provide-Capability" entry.
I assume the next best solution would be if the ESH features have an
"Capability" entry.
But what could be done if that "third party" stuff will not be changed?

I don't like to remove the ESH Karaf features from the ESH repo and
drop the support of Karaf features completely.
But I cannot maintain the features and bundles for all the other
developers and I am pretty sure the project will not add this stuff to
their guidelines.

Any tips and help is welcome.

Best regards and thanks for your time,
Markus Rathgeb

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

So, is there a way to use 1.3.0 (IIRC prerequisite and dependency has
been added there) or newer without adding the capability instruction
to every feature using a bundle without that information in the
manifest?
I see there is a configuration for the runtime, but is there one for
the plugin to control the verification?

I have to use a dozen of third party bundles that miss that
information and that change frequently, adding the capability to the
feature is a too time consuming effort.

2016-08-25 16:12 GMT+02:00 Guillaume Nodet <gno...@apache.org>:
> Agreed, so the problem was caused by a custom feature ?
> I thought it was directly the pax-web feature.
>
> In that case, I agree, that's exactly the behavior we wanted I think.
>
> On a side note, if pax-web does not expose the service capability, it
> should also be fixed ;-)
>
> Guillaume
>
> 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>
>> After digging a bit, I don't think it's actually a bug.
>>
>> Let me explain and see we all agree ;)
>>
>> Previously to the commit, the service enforcement was "enabled" only for
>> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
>> enforcement also for xmlns 1.4.0 (which makes sense).
>>
>> In Markus' use case, he said he tried xmlns 1.2.0 and it failed. However,
>> as he's using Karaf Maven plugin to generate the descriptor, by default,
>> even if the "source" features XML contains xmlns 1.2.0, the generated one
>> is using xmlns 1.4.0.
>>
>> That's why it worked before and not after the commit.
>>
>> Due to that, I don't think we have to consider it as a bug:
>> 1. If we don't want service enforcement, than, we have to use a feature
>> with xmlns 1.2.0
>> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
>> features including services enforcement.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 08/25/2016 03:41 PM, Jean-Baptiste Onofré wrote:
>>
>>> It looks like the commit in cause is the following:
>>>
>>> -
>>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
>>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
>>> Author: Guillaume Nodet <gno...@apache.org>
>>> Date:   Fri Jul 22 12:33:17 2016 +0200
>>>
>>> [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema
>>>
>>> :04 04 d038cf82d490d3cd0c7df97376575e323ef2382f
>>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M  features
>>> --
>>>
>>> I'm testing a revert.
>>>
>>> Regards
>>> JB
>>>
>>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofré wrote:
>>>
>>>> No, I don't think it's related as it's not a change in 4.0.6.
>>>>
>>>> I think it's a combination between the features resolver and the
>>>> karaf-maven-plugin.
>>>>
>>>> I'm pretty close in the bisect now ;)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>>>>
>>>>> I found this one:
>>>>>
>>>>> # By default, the feature resolver checks the service
>>>>> requirements/capabilities of
>>>>> # bundles for new features (xml schema >= 1.3.0) in order to
>>>>> automatically installs
>>>>> # the required bundles.
>>>>> # The following flag can have those values:
>>>>> #   - disable: service requirements are completely ignored
>>>>> #   - default: service requirements are ignored for old features
>>>>> #   - enforce: service requirements are always verified
>>>>> #
>>>>> #serviceRequirements=default
>>>>>
>>>>> Do you think this one could be related?
>>>>>
>>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>>>>> successful verification.
>>>>>
>>>>> -http://karaf.apache.org/xmlns/features/v1.4.0;
>>>>> name="${project.artifactId}-${project.version}">
>>>>> +http://karaf.apache.org/xmlns/features/v1.2.0;
>>>>> name="${project.artifactId}-${project.version}">
>>>>>
>>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>>>>>
>>>>>> Hi Guillaume,
>>>>>>
>>>>>> I'm on gi

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

https://issues.apache.org/jira/browse/KARAF-3520

2016-08-25 10:46 GMT+02:00 Markus Rathgeb <maggu2...@gmail.com>:
> I found this one:
>
> # By default, the feature resolver checks the service
> requirements/capabilities of
> # bundles for new features (xml schema >= 1.3.0) in order to
> automatically installs
> # the required bundles.
> # The following flag can have those values:
> #   - disable: service requirements are completely ignored
> #   - default: service requirements are ignored for old features
> #   - enforce: service requirements are always verified
> #
> #serviceRequirements=default
>
> Do you think this one could be related?
>
> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
> successful verification.
>
> -http://karaf.apache.org/xmlns/features/v1.4.0;
> name="${project.artifactId}-${project.version}">
> +http://karaf.apache.org/xmlns/features/v1.2.0;
> name="${project.artifactId}-${project.version}">
>
> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>> Hi Guillaume,
>>
>> I'm on git biset to identify the guilty ;)
>>
>> And yes, I will recut a release.
>>
>> Regards
>> JB
>>
>>
>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>
>>> Yeah, if it breaks compatibility, we should recut a release ?
>>> Has anyone identified the culprit commit yet ?
>>>
>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>>>
>>>> I think it's a change in the karaf-maven-plugin.
>>>>
>>>> And yes, I reproduce Markus' issue as well.
>>>>
>>>> Do we consider as release blocker ?
>>>>
>>>> If so, I will fix it today and submit a new vote.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I was able to reproduce the issue Markus described with his test.
>>>>> One thing that crosses my mind, did we change something with the feature
>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>> contain
>>>>> a provide-capability for the WebContainer Service.
>>>>>
>>>>> regards, Achim
>>>>>
>>>>>
>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <krzys.sobkow...@gmail.com
>>>>>>
>>>>>> :
>>>>>
>>>>>
>>>>> +1 (non-binding)
>>>>>>
>>>>>>
>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>
>>>>>> Regards
>>>>>> Krzysztof
>>>>>>
>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>
>>>>>>> Release Notes:
>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>
>>>>>> projectId=12311140=12335477
>>>>>>
>>>>>>>
>>>>>>> Staging Repository:
>>>>>>>
>>>>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>>>>
>>>>>>> Git Tag:
>>>>>>> karaf-4.0.6
>>>>>>>
>>>>>>> Please vote to approve this release:
>>>>>>>
>>>>>>> [ ] +1 Approve the release
>>>>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>>>>
>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>
>>>>>> JEE & OSS Architect, Integration Architect
>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>> (http://servicemix.apache.org/)
>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>> (http://www.capgeminisoftware.
>>>>>> pl/)
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbono...@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

I found this one:

# By default, the feature resolver checks the service
requirements/capabilities of
# bundles for new features (xml schema >= 1.3.0) in order to
automatically installs
# the required bundles.
# The following flag can have those values:
#   - disable: service requirements are completely ignored
#   - default: service requirements are ignored for old features
#   - enforce: service requirements are always verified
#
#serviceRequirements=default

Do you think this one could be related?

Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
successful verification.

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

2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré :
> Hi Guillaume,
>
> I'm on git biset to identify the guilty ;)
>
> And yes, I will recut a release.
>
> Regards
> JB
>
>
> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>
>> Yeah, if it breaks compatibility, we should recut a release ?
>> Has anyone identified the culprit commit yet ?
>>
>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré :
>>
>>> I think it's a change in the karaf-maven-plugin.
>>>
>>> And yes, I reproduce Markus' issue as well.
>>>
>>> Do we consider as release blocker ?
>>>
>>> If so, I will fix it today and submit a new vote.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>
 Hi,

 I was able to reproduce the issue Markus described with his test.
 One thing that crosses my mind, did we change something with the feature
 resolver? Cause I can't remember that the pax-web-api did actually
 contain
 a provide-capability for the WebContainer Service.

 regards, Achim


 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak 
> :


 +1 (non-binding)
>
>
> ServiceMix 7.x tests ok. Thanks!!!
>
> Regards
> Krzysztof
>
> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>
>> Hi all,
>>
>> I submit Karaf (Container) 4.0.6 release to your vote.
>>
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>
> projectId=12311140=12335477
>
>>
>> Staging Repository:
>>
>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>
>> Git Tag:
>> karaf-4.0.6
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>>
>> This vote will be open for at least 72 hours.
>>
>> Thanks,
>> Regards
>> JB
>>
>
> --
> Krzysztof Sobkowiak (@ksobkowiak)
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member
> (http://servicemix.apache.org/)
> Senior Solution Architect @ Capgemini SSC
> (http://www.capgeminisoftware.
> pl/)
>
>



>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

Hi Achim,

> @Markus, you should consider to have a specialized Jenkins to verify your
> applications with recent snapshots so we can find those things earlier ;)

You are right.
I will setup one!

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

The Eclipse SmartHome project is not using Provide-Capability in the
manifest of their bundles (IIRC this does not exist for OSGI R4.2).

Using Karaf K405 all my custom distributions are working as expected.
Using Karaf K406 my custom distributions does not start anymore.

Because the feature resolver complains about missing osgi.services

===
2016-08-25 09:54:02,528 | ERROR | pool-7-thread-1  |
BootFeaturesInstaller| 8 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=dummy;
type=karaf.feature; version="[1.1.0.SNAPSHOT,1.1.0.SNAPSHOT]";
filter:="(&(osgi.identity=dummy)(type=karaf.feature)(version>=1.1.0.SNAPSHOT)(version<=1.1.0.SNAPSHOT))"
[caused by: Unable to resolve dummy/1.1.0.SNAPSHOT: missing
requirement [dummy/1.1.0.SNAPSHOT] osgi.identity; osgi.identity=foo;
type=osgi.bundle; version="[1.1.0.201608240913,1.1.0.201608240913]";
resolution:=mandatory [caused by: Unable to resolve
foo/1.1.0.201608240913: missing requirement [foo/1.1.0.201608240913]
osgi.service; 
filter:="(objectClass=org.eclipse.smarthome.core.items.ItemRegistry)";
effective:=active]]
at 
org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[8:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[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_102]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_102]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_102]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_102]
===

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

Hi,

>> I was able to reproduce the issue Markus described with his test.
>> One thing that crosses my mind, did we change something with the feature
>> resolver? Cause I can't remember that the pax-web-api did actually contain
>> a provide-capability for the WebContainer Service.

The feature that should be verified is using the pax-http-whiteboard
and the http feature as dependency.
See: 
https://github.com/maggu2810/k406-staging/blob/94794b8/feature/src/main/feature/feature.xml#L10

So at least one bundle in that features should contain the
WebContainer service, shouldn't it?
The feature will introduce a lot more Pax Web bundles (not only the
API), so the WebContainer implementation should be available.

>> Do we consider as release blocker ?

If the verification of features is broken (and not only related to my
features) I assume we should fix it for a release. Shouldn't we?

Best regards,
Markus

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

Hello,

I see this error about missing "osgi.service"
(filter:="(objectClass=...)";effective:=active) for a lot of features
at verification now.

I assume it fails for all features that contains a bundle that
"Require-Capability" contains this requirement, but the bundle
containing this service does not provide it by the
"Provide-Capability" information.

The Require-Capability and Provide-Capability information in the
manifest is added by Bnd (e.g. using maven-bundle-plugin) but there
are other bundles (for me third party ones) not using Bnd and this
information is missing.

Do you know if it is possible to instruct the feature resolver to
satisfy a osgi.service required capability if a implementation of the
class is present or looking also at the DS files, too?

2016-08-24 10:22 GMT+02:00 Markus Rathgeb <maggu2...@gmail.com>:
> Hello,
>
> I use a component that imports the Pax Web WebContainer class and
> depends on a service reference.
>
> ===
> import org.ops4j.pax.web.service.WebContainer;
> ...
>
> @Component(immediate = true)
> public class Web {
>
> @Reference
> private WebContainer webContainer;
> ...
> ===
>
> My feature looks like this one:
>
> ===
>   
>mvn:.../.../${project.version}
> scr
> shell
> http
> pax-http-whiteboard
>   
> ===
>
> The verification works using K405.
> The verification fails using K406 staging
>
> (IIRC)
> K405 is using Pax Web 4.2.6
> K406 is using Pax Web 4.2.8
>
> The error on feature verification is:
> missing requirement [...] osgi.service;
> filter:="(objectClass=org.ops4j.pax.web.service.WebContainer)";
> effective:=active]]
>
> So, why is the WebContainer service not satisfied anymore?
> Is this a change in the Pax Web features (but pax-http and
> pax-http-whiteboard should satisfy the WebContainer, shouldn't it) or
> in the feature verification?
>
> Thanks in advance,
> Markus

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

[Markus Rathgeb]

Hello,

I use a component that imports the Pax Web WebContainer class and
depends on a service reference.

===
import org.ops4j.pax.web.service.WebContainer;
...

@Component(immediate = true)
public class Web {

@Reference
private WebContainer webContainer;
...
===

My feature looks like this one:

===
  
   mvn:.../.../${project.version}
scr
shell
http
pax-http-whiteboard
  
===

The verification works using K405.
The verification fails using K406 staging

(IIRC)
K405 is using Pax Web 4.2.6
K406 is using Pax Web 4.2.8

The error on feature verification is:
missing requirement [...] osgi.service;
filter:="(objectClass=org.ops4j.pax.web.service.WebContainer)";
effective:=active]]

So, why is the WebContainer service not satisfied anymore?
Is this a change in the Pax Web features (but pax-http and
pax-http-whiteboard should satisfy the WebContainer, shouldn't it) or
in the feature verification?

Thanks in advance,
Markus

Re: [UPDATE] Releases schedule

[Markus Rathgeb]

Hi Oliver,

> any chance to get KARAF-4105 and KARAF-4346 fixed for 4.0.6?

Have you had a change to review my changes / PR for KARAF-4105?

Best regards,
Markus

Re: Edit config.properties from karaf-maven-plugin

[Markus Rathgeb]

Hi,
you can have a look at
https://issues.apache.org/jira/browse/KARAF-3982 and the implemented
feature.

I am using assembly-property-edits.xml to modify property files in my
custom distribution and it is working as expected.

Best regards,
Markus

Re: [VOTE] Apache Karaf 4.0.5 release (take 3)

[Markus Rathgeb]

+1 (non-binding)

Re: [VOTE] Apache Karaf 4.0.5 release (take 2)

[Markus Rathgeb]

+1 for option 2

2016-04-06 8:48 GMT+02:00 Sobkowiak Krzysztof :
> I prefer the option 2 as well
>
> Regards
> Krzysztof
>
> On 06.04.2016 08:39, Jean-Baptiste Onofré wrote:
>> Hi Cristiano,
>>
>> I don't think it's related, as the issue in about blueprint-ext namespace 
>> (not even define). The problem is located in Aries Blueprint.
>>
>> I gonna deal with Guillaume.
>>
>> We can:
>> 0. leave Karaf 4.0.5 as it is, but I think it's not acceptable: blueprint is 
>> used by lot of users, and we can't allow a release without a working 
>> blueprint layer.
>> 1. downgrade Karaf to Aries Blueprint 1.5.x: unfortunately, we won't benefit 
>> about some improvements implemented in blueprint
>> 2. revert or fix the change in Aries: it means we would need a new Aries 
>> Blueprint core release, so 3 days vote, meaning that we won't be able to 
>> release Karaf before roughly 6 days.
>>
>> My preference is on 2 even if it delays Karaf 4.0.5 release.
>>
>> Thoughts ?
>>
>> I will add an Integration Test on blueprint to avoid such problem in the 
>> future.
>>
>> Regards
>> JB
>>
>> On 04/06/2016 08:14 AM, Cristiano Costantini wrote:
>>> Hi JB and Krzysztof,
>>>
>>> I don't know if this can be have any impact on the problem you have
>>> reported, but about 1 month ago I got into an issue with camel XSD schemas
>>> for Camel namespaces, and the issue is that the URL of the latest XSD,
>>> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
>>> is not from latest version 2.16.2, but it is from version 2.15.0
>>>
>>> While upgrading to ServiceMix 7, I had to change manually the XML to
>>> xsi:schemaLocation="http://camel.apache.org/schema/spring http://camel
>>> .apache.org/schema/spring/camel-spring-2.16.1.xsd" in order to make it work
>>> (note also that SMX 7 is based on camel 2.16.2, but this XSD is not
>>> available)
>>>
>>> But in fact the only problem I had was that Eclipse validation and
>>> autocompletion of the XML files was not working properly.
>>>
>>> if this is not relevant, please ignore this message ;-)
>>>
>>> Cristiano
>>>
>>>
>>>
>>>
>>> Il giorno mar 5 apr 2016 alle ore 22:19 Jean-Baptiste Onofré <
>>> j...@nanthrax.net> ha scritto:
>>>
 I tried with Camel 2.16.2, camel-blueprint, and simple route in
 blueprint: it works fine.

 I tried with your XML, and actually I have the same problem.

 It sounds like a Aries Blueprint bug. Let me try if I downgrade to
 blueprint 1.5.x and check the change in aries blueprint (I know
 Guillaume did some enhancements & changes).

 Honestly, I would consider as a blocker for the release, so, I will
 probably revert my vote to -1. I just want to make more tests.

 Regards
 JB

 On 04/05/2016 09:46 PM, Krzysztof Sobkowiak wrote:
> Hi
>
> I tried to upgrade ServiceMix to the new version and have several
 problems with blueprint.
>
> 2016-04-05 21:42:05,485 | INFO  | pool-46-thread-1 |
 FeaturesServiceImpl  | 9 - org.apache.karaf.features.core -
 4.0.5 |   cxf-wsn-receive/7.0.0.SNAPSHOT
> 2016-04-05 21:42:05,567 | ERROR | pool-46-thread-1 |
 BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
 1.6.0 | Unable to start blueprint container for bundle
 cxf-wsn-receive/7.0.0.SNAPSHOT
> org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
 http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0', of an
  element information item must be identical to the targetNamespace
 attribute, 'http://camel.apache.org/schema/blueprint', of the imported
 document.
>   at
 org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
 Source)[:]
>   at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
 Source)[:]
>   at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
 Source)[:]
>   at
 org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
 Source)[:]
>   at
 org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown
 Source)[:]
>   at
 org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
 Source)[:]
>   at
 org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown
 Source)[:]
>   at
 org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown
 Source)[:]
>
> or
>
>
> 2016-04-05 21:31:36,969 | ERROR | pool-42-thread-1 |
 BlueprintContainerImpl   | 28 - org.apache.aries.blueprint.core -
 1.6.0 | Unable to start blueprint container for bundle
 drools-camel-cxf-server/7.0.0.SNAPSHOT
> org.xml.sax.SAXParseException: src-import.3.1: The namespace attribute, '
 http://cxf.apache.org/configuration/beans', of an  element
 information item must be identical to the targetNamespace attribute, '
 

Re: [VOTE] Apache Karaf 4.0.5 release (take 2)

[Markus Rathgeb]

+1 (non-binding)

2016-04-05 5:52 GMT+02:00 Jamie G. :
> +1 (binding)
>
> On Mon, Apr 4, 2016 at 6:40 PM, Fabian Lange
>  wrote:
>> verified, no runtime downloads, everything as I like it, so
>>
>> +1 (non-binding)
>>
>> Fabian
>>
>> On Mon, Apr 4, 2016 at 10:38 PM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Hi all,
>>>
>>> I submit Karaf Container 4.0.5 release to your vote.
>>>
>>> Release Note:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12334629
>>>
>>> Staging Repository:
>>> https://repository.apache.org/content/repositories/orgapachekaraf-1060/
>>>
>>> Git tag:
>>> karaf-4.0.5
>>>
>>> Please vote to approve this release:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>
>>> This vote will be open for at least 72 hours.
>>>
>>> Thanks,
>>> Regards
>>> JB
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>

Re: [VOTE] Apache Karaf 4.0.5 release

[Markus Rathgeb]

I will not vote -1.
Now I know that I cannot use the karaf-maven-plugin to create a custom
distribution that is able to start without an internet connection.

If it is okay for you to release K405 with this "bug" /
changed-behaviour / missing feature, it is okay for me, too.
But I assume I am not the only one, that wants to create such offline
distributions and there will be additional reports after release, too.

So, I accept your decision and will not update to K405 and use K406 after K404.

Re: [VOTE] Apache Karaf 4.0.5 release

[Markus Rathgeb]

Hi,

I am using Karaf to create custom distributions. That distributions
are running on embedded devices that does not grant to have internet
access. So the custom distribution must be able to start without
access to a public maven repository.
Using the staged K405 this is broken.

If I am using the karaf-maven-plugin 4.0.4 and the karaf features
4.0.5 it is working as expected.
But using different Karaf versions (of plugin and features) to create
the custom distribution feels a little bit wired.

If I will ever find a bug, then I have to report to mix different
Karaf versions.
Is this an expected use case?

I do not like to vote a "-1" here, but can't give a +1, too.

Re: [VOTE] Apache Karaf 4.0.5 release

[Markus Rathgeb]

Hi,

> Nope, the 4.0.5 plugin will not put them in the systems folder because it
> evaluates the conditional correctly.
> but at runtime even though the conditional is false, they are downloaded.

This sound like a breakage of offline distributions that intention is
that all content is bundles at build time and nothing is downloaded at
runtime.

Re: bnd files in Decanter Project

[Markus Rathgeb]

I think this was just a copy'n'paste failure, but if you set inherited
and extensions in the parent POM, there is no need to set it in each
project, too.

Re: bnd files in Decanter Project

[Markus Rathgeb]

Hello,

some related questions:

You are talking about the bnd-maven-plugin (e.g. Neil Bartlett). I
recently read this pages:
* https://github.com/bndtools/bnd/issues/629
* https://github.com/bndtools/bndtools/wiki/Maven-Integration-Requirements
So, I would assume I should not move my projects to use that plugin.
Correct?

Could we collect pro and cons of he bnd.bnd files at some place?
The only pro I have read is loosing some lines.
This could also be done using a pre-configured maven-bundle-plugin in
the parent POM and using properties to change that stuff (see e.g.
https://github.com/ops4j/org.ops4j.pax.tipi/blob/master/tipi-master/pom.xml).
Or I am wrong?

Best regards,
Markus

Re: bnd files in Decanter Project

[Markus Rathgeb]

Hi Christian,
thank you for your answer.

I want to state, that there are no feelings from my side what is better.
I want to collect the technical details for further decisions on the
projects I maintain.

So, let's assume I do not use the configuration in a parent project
(just add maven-bundle-plugin to the used plugins and set
extensions=true) and also not use properties, the bnd.bnd file will
result in less lines in the pom if I want to change the default
configuration of the plugin.

Are there other pros?

Best regards,
Markus

Re: bnd files in Decanter Project

[Markus Rathgeb]

Hi,

> - You typically do not need a plugin definition at all in each module pom.
> So the definition just in the bnd file is much more concise.

I set the plugin with "<_dsannotations>*" and set
extensions in the parent POM and so no child pom that is using the
defaults does need to contain the maven-bundle-plugin section at all.

> So I think the extraction is best for users of eclipse and bndtools and less
> valuable for other IDEs. To be honest though editing the bnd files is not
> really a big deal.

> I typically only use Import-Package, Export-Package, Private-Package and
> Bundle-Activator and these four I can type without completion.

Thank you again for your explanations.

I (!) see no real pro and no real cons.
So IMHO it is just a personal decision if someone want to use bnd.bnd
files or not and perhaps the IDE that is used to configure stuff and
work with.

Best regards,
Markus

Re: karaf-maven-plugin 4.0.4-SNAPSHOT

[Markus Rathgeb]

Will check if it is related to my commit (KARAF-4145) first.

2015-12-17 10:57 GMT+01:00 Markus Rathgeb <maggu2...@gmail.com>:
> Just a note if you plan a release next week.
> I believe there is something broken with the maven-metadata-local.xml
> creation of the karaf-maven-plugin in the 4.0.4-SNAPHOST.
> The files are empty on my system.
> Using "mvn clean install -X" I see a lot of messages (sure, it depends
> on the stuff that is packed to your "system" directory in the custom
> distribution).
>
> [DEBUG] File 'maven-metadata-local.xml' is not a features file.
> org.xml.sax.SAXParseException; systemId:
> file://maven-metadata-local.xml; lineNumber: 1; columnNumber:
> 1; Premature end of file.
>
> The size of the maven-metadata-local.xml file is 0 bytes.
>
> I will try to further inspect this.

karaf-maven-plugin 4.0.4-SNAPSHOT

[Markus Rathgeb]

Just a note if you plan a release next week.
I believe there is something broken with the maven-metadata-local.xml
creation of the karaf-maven-plugin in the 4.0.4-SNAPHOST.
The files are empty on my system.
Using "mvn clean install -X" I see a lot of messages (sure, it depends
on the stuff that is packed to your "system" directory in the custom
distribution).

[DEBUG] File 'maven-metadata-local.xml' is not a features file.
org.xml.sax.SAXParseException; systemId:
file://maven-metadata-local.xml; lineNumber: 1; columnNumber:
1; Premature end of file.

The size of the maven-metadata-local.xml file is 0 bytes.

I will try to further inspect this.

Re: [PROPOSAL] Karaf 4.0.3 end of this week

[Markus Rathgeb]

Hello Jean-Baptiste ,

the vote is ongoing, so KARAF-3982 is not included. Is this correct?

2015-11-03 10:20 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> Hi Markus,
>
> it will try to include KARAF-3982 on 4.0.3.
>
> Regards
> JB
>
>
> On 11/03/2015 09:19 AM, Markus Rathgeb wrote:
>>
>> Hello JBO,
>>
>> do you know which version will include
>> https://issues.apache.org/jira/browse/KARAF-3982
>> Does this implementation need further testing?
>>
>> Best regards,
>> Markus
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [PROPOSAL] Karaf 4.0.3 end of this week

[Markus Rathgeb]

Hello JBO,

do you know which version will include
https://issues.apache.org/jira/browse/KARAF-3982
Does this implementation need further testing?

Best regards,
Markus

Re: [VOTE] Apache Karaf 4.0.2 release

[Markus Rathgeb]

+1, non-binding

Thanks a lot to all for the great work.

2015-10-10 0:07 GMT+02:00 Jean-Baptiste Onofré :
> Hi all,
>
> I submit Apache Karaf 4.0.2 to your vote:
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12333259=Text=12311140
>
> Git tag:
> karaf-4.0.2
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1048/
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [HEADS UP] Karaf 4.0.2 on vote today

[Markus Rathgeb]

I am currently using only the one root instance and does not see any
impact but the two messages (the one at start and the one at stop).
So it is nothing high prio.
For the end user, it is a little bit irritating.

Don't work to hard :)


2015-10-08 9:51 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
> Hi Markus,
>
> rethinking about KARAF-4005, let me set the target as 4.0.2 and try to
> include it. All depends if I can move fast on that ;)
>
> I keep you posted.
>
> Regards
> JB
>
> On 10/08/2015 09:31 AM, Markus Rathgeb wrote:
>>
>> Hi,
>>
>> any change for KARAF-4005?
>> I don't think I get it fixed myself for 4.0.2 as it needs a good
>> knowledge of the infrastructure.
>>
>> Regards,
>> Markus
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [HEADS UP] Karaf 4.0.2 on vote today

[Markus Rathgeb]

Hi,

any change for KARAF-4005?
I don't think I get it fixed myself for 4.0.2 as it needs a good
knowledge of the infrastructure.

Regards,
Markus

Karaf console extension: Support for Equinox commands

[Markus Rathgeb]

Hello,

sometimes I have to use org.eclipse.equinox.ds instead of
org.apache.felix.scr (SCR feature).
So I am missing the scr command extension to get a list and state of
the declarative services.

To be able to access the Eclipse Equinox command extensions for the
Eclipse Equinox OSGi framework I have written a translation module.
This module prefix the Eclipse command extensions and add them to as
Karaf command extensions at runtime.

I think this is a nice addition for everyone that have to use the
Equinox OSGi framework inside Karaf.

Could you have a look at und give me some feedback?
Would you have interest to include this in Karaf mainline (after your review)?

Best regards,
Markus