Re: Karaf version with Jdk 21

[Eric Lilja]

For what it's worth, I could successfully run all my Pax Exam tests using
Karaf 4.4.4/4.4.5 with Java 21. Source/target, however, was still set to
Java 17. But I use declarative services, I was under the impression that
Blueprint is legacy.

- Eric L

On Tue, Jan 16, 2024 at 10:27 AM Jean-Baptiste Onofré 
wrote:

> Hi,
>
> As you can see the problem comes from Aries Blueprint and it should be
> better as I did a new Aries Proxy and Blueprint feature with updated
> JDK version.
>
> Regards
> JB
>
> On Thu, Jan 11, 2024 at 9:50 PM yunji@toshibagcs.com
>  wrote:
> >
> > Hi good day,
> >
> > I was able to fix that by adding SCR feature.
> > But I'm facing two other issues 
> > I'm using java21 and karaf 4.4.4.
> > I'm not sure if 4.4.5 version will fix this problem.
> >
> >
> > Apache Karaf :: Shell :: Core (220)
> > ---
> > Status: Failure
> > Blueprint
> > 1/11/24, 12:08 PM
> > Exception:
> > java.lang.IllegalArgumentException: Invalid Java version 65
> > org.osgi.service.blueprint.container.ComponentDefinitionException:
> java.lang.IllegalArgumentException: Invalid Java version 65
> > at
> org.apache.aries.blueprint.container.ReferenceRecipe.internalCreate(ReferenceRecipe.java:141)
> > at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:81)
> > at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> > at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:90)
> > at
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:810)
> > at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:784)
> > at
> org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:765)
> > at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:699)
> > at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:666)
> > at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:81)
> > at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> > at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:90)
> > at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:360)
> > at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:190)
> > at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:737)
> > at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:433)
> > at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:298)
> > at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:335)
> > at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:288)
> > at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:284)
> > at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:274)
> > at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> > at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> > at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> > at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> > at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> > at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1384)
> > at
> org.apache.felix.framework.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:730)
> > at
> org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:485)
> > at
> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4847)
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2363)
> > at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
> > at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:992)
> > at
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.startBundle(BundleInstallSupportImpl.java:165)
> > at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1160)
> > at
> 

Re: Karaf version with Jdk 21

[Eric Lilja]

JB, since, as you mentioned, Karaf will move to Jakarta (which if, of
course, has to at some point to not fade into irrelevancy), does that mean
one will no longer be able to use the Pax Exam framework to test Karaf (if
Karaf version >= 4.5)? Pax Exam is seemingly abandoned...

- Eric L

On Sat, Jan 6, 2024 at 4:47 PM Jean-Baptiste Onofré  wrote:

> Hi
>
> 4.4.5 will be in vote today with better support of JDK21 (we build and
> test using JDK20, I will setup JDK21).
>
> Regarding 4.5.0 (including Jakarta EE namespace), I plan to work on it
> in the coming days. I hope to submit 4.5.0 to vote in a couple of
> weeks.
>
> Do you have specific test cases with JDK21 ? I would like to check
> with Karaf 4.4.5.
>
> Regards
> JB
>
> On Fri, Jan 5, 2024 at 9:12 PM yunji@toshibagcs.com
>  wrote:
> >
> > Hi Jean,
> >
> > Thank you for providing the information.
> >
> > I'm currently in the process of migrating from Karaf 4.2 to 4.4 due to
> our migration from Java 8 to Java 21.
> > However, I've encountered some errors while running Karaf, seemingly
> related to the OSGi component (likely associated with the SCR feature).
> > Could you please provide information on the scheduled release date for
> Karaf 4.5?
> >
> > Thanks again for your assistance.
> >
> > Best regards,
> >
> > Yunji Lee
> >
> >
> >
> > 
> > From: Jean-Baptiste Onofré 
> > Sent: Wednesday, December 13, 2023 8:36 AM
> > To: user@karaf.apache.org 
> > Subject: Re: Karaf version with Jdk 21
> >
> > CAUTION:  This email originated from outside our organization. Do not
> click links or open attachments unless you validate the sender.
> >
> >
> >
> > Hi Yunji
> >
> > I'm preparing 4.4.5 right now, but a better JDK 21 support (but not
> > yet complete due to third parties like Aries *).
> >
> > About Karaf 4.5.0, I plan to submit it to release just after Christmas.
> >
> > Regards
> > JB
> >
> > On Mon, Dec 11, 2023 at 5:03 PM yunji@toshibagcs.com
> >  wrote:
> > >
> > > Hello good day,
> > >
> > > I hope this email finds you well.
> > > I was trying to compile and run karaf 4.4.4 on jdk21.
> > >
> > > And I came across information in the mailing list that there will be a
> Karaf 4.5.x version with full JDK 21 support.
> > > I'm interested to know when this release is scheduled.
> > >
> > > Thank you for your time and assistance.
> > >
> > > Best regards,
> > > Yunji Lee
>

Re: How to change the karaf.log log level in a pax exam karaf test?

[Eric Lilja]

A Pax Exam test that is using a Karaf container (which is a forked
container), often has two log configurations. One for the test itself (for
me that would be a log4j2-test.xml), and one for the container. You can use
KarafDistributionOption.replaceConfigurationFile() to provision a
org.ops4j.pax.logging.cfg-file (so here I use a properties-style file, not
xml) with your desired settings. If you do, make sure to also call
doNotModifyLogConfiguration() on the same class (KarafDistributionOption)

- Eric L


On Mon, Nov 20, 2023 at 10:27 PM Steinar Bang  wrote:

> I wanted to switch the log leven from INFO to FINE in a pax exam karaf
> test.
>
> So I took the org.ops4j.pax.logging.cfg file from a karaf 4.4.4 etc
> directory and changed the rootlogger, i.e.
>
> log4j2.rootLogger.level = FINE
>
> And then I dumped the resulting file into src/test/resources/etc of the
> pax exam test project.
>
> But the karaf.log file was still filled with INFO messages so that
> wasn't the right way?
>
> Is there a way?
>
> Thanks!
>
>

Re: Debugging karaf feature pax exam test in eclipse, possible?

[Eric Lilja]

It's part of the provisioning of the
container, org.ops4j.pax.exam.CoreOptions.vmOption

Eclipse can do it, too, obviously, but I don't know how. It was
extremely simple in Intellij

- Eric L

On Sat, Nov 11, 2023 at 6:25 PM Steinar Bang  wrote:

> (hm... I never responded to this one, looks like...? Sorry about that!)
>
> >>>>> Eric Lilja :
>
> > Yeah, as JB mentioned, Karaf mode in Pax Exam is forked so the classpath
> > from the test bootstrap itself does not spill over into the container
> (for
> > native pax exam, you can choose between forked mode or not).
>
> > Anyway, remote debugging seems to be a bit easier in Intellij (I stopped
> > using Eclipse several years ago). Remote debugging is turned on by adding
> > the following VM option (regardless of IDE, obviously):
>
> > vmOption("-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005")
>
> I think this is why I didn't respond: I couldn't figure out where this
> vmOption was to be added, and thought "postpone figuring this out for
> later!"... and then forgot...:-)
>
> Is this vmOption added to whatever VM runs the pax exam test?
>
> And what happens then is that the test is hanging until a debugger
> attaches itself to port 5005?
>
> > Then when the test is launched in debug mode, Intellij emits:
> > Listening for transport dt_socket at address: 5005
>
> Right! Looks like that is the case.
>
> > And next to that log statement, there is something akin to a button that
> > says "Attach debugger", which I can just click to be able to debug the
> > container (it takes a few seconds to attach).
>
> Hm... wonder if eclipse can do that?
>
> (I use IntelliJ at work, but I've never really warmed to it.)
>
> > No need to create a special debug configuration
>
> > However, I did notice that all log output from then on doesn't seem to
> > appear anywhere, which is a bit annoying, but I'm sure that can be
> > resolved. Inspecting all objects etc, which is the important stuff, works
> > fine, however.
>
> Sounds promising! Thanks!
>
> (I'll try to figure out where the vmOption goes and then if eclipse can
> attach to a hanging test)
>
>

Re: Debugging karaf feature pax exam test in eclipse, possible?

[Eric Lilja]

Yeah, as JB mentioned, Karaf mode in Pax Exam is forked so the classpath
from the test bootstrap itself does not spill over into the container (for
native pax exam, you can choose between forked mode or not).

Anyway, remote debugging seems to be a bit easier in Intellij (I stopped
using Eclipse several years ago). Remote debugging is turned on by adding
the following VM option (regardless of IDE, obviously):

vmOption("-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005")

Then when the test is launched in debug mode, Intellij emits:
Listening for transport dt_socket at address: 5005

And next to that log statement, there is something akin to a button that
says "Attach debugger", which I can just click to be able to debug the
container (it takes a few seconds to attach).

No need to create a special debug configuration

However, I did notice that all log output from then on doesn't seem to
appear anywhere, which is a bit annoying, but I'm sure that can be
resolved. Inspecting all objects etc, which is the important stuff, works
fine, however.

- Eric L


On Tue, Jun 6, 2023 at 7:27 PM Steinar Bang  wrote:

> > Jean-Baptiste Onofré :
>
> > As pax-exam can fork the JVM to start Karaf, you need remote debugger.
>
> Hm... but does it fork the JUnit test also?
>
> That's where I'm trying to debug...?
>
> Ah, but you're right! To be able to run the way it does, i.e. access
> OSGi services created in karaf as Java objects, the JUnit test has to be
> in the same JVM as karaf is running.
>
> > Is it what you are doing ?
>
> No, I think that would be hard here.
>
> I use the remote debugger all the time with karaf proper, where it works
> perfectly, I might add.
>
> But in a pax exam karaf test I have time to set up remote debugging,
> from the time the test starts and it ends.
>
> I had hoped there was an eclipse run configuration that could be used,
> maybe...?
>
> I googled "pax exam eclipse run configuration" and found these two:
>  https://stackoverflow.com/a/43149241
>
> https://confluence.i2cat.net/m/mobile.action#page/17567089#HowtomakeanintegrationtestwithPaxExam-Debuggingyourtest
>
> I'll dig deeper into these two.
>
> Thanks!
>
>

Re: How to add jackson runtime to a pax exam integration test?

[Eric Lilja]

You have databind twice there, I believe you will be needing annotations,
core, and databind. I often use a particular service in my PaxExam tests,
and its feature provisions those three Jackson artifacts, since the service
uses Jackson internally. Skip gson..

You can also provision using mavenBundle()-API in Pax Exam

- Eric L

On Sat, Jun 3, 2023 at 5:03 PM Steinar Bang  wrote:

> > Steinar Bang :
>
> [snip!]
> > I have added the following compile scope dependencies to the integration
> > test project itself.
>
> > I have also added these dependencies to the project containing the test
> > feature loaded by the integration test, causing the jackson bundles to
> > be added to that feature.
>
> Forgot to add the dependencies, but here they are (I've added the same
> compile scope depdencies in both places):
> 
> 
> com.fasterxml.jackson.core
> jackson-core
> 2.15.2
> 
> 
> com.fasterxml.jackson.core
> jackson-databind
> 2.15.2
> 
> 
> com.fasterxml.jackson.core
> jackson-databind
> 2.15.2
> 
>
>

Re: Is it possible to have multiple tests in a KarafTestSupport test class, all using the same service?

[Eric Lilja]

The reactor strategy decides if a new container should be spawned per
method or per class. If I have a bunch of different tests in the same
class, I would not want to spawn the container more than once, if I could
avoid it, since it's expensive. The provisioned bundles etc are typically
defined in the @Configuration-method, so the set of provisioned bundles is
shared by all tests, regardless of reactor strategy. It sounds like you
want to re-use the container for the tests in a given test class but tweak
the provisioning between tests, meaning you cannot rely on the
shared @Configuration-method, but have to also provision stuff in the test
themselves. I have never written a Pax Exam test that works like that, not
sure how robust it's going to be.

- Eric L

On Fri, Mar 24, 2023 at 8:02 PM Steinar Bang  wrote:

> > Jean-Baptiste Onofré :
>
> > Like this one:
>
> >
> https://github.com/apache/karaf/blob/main/itests/test/src/test/java/org/apache/karaf/itests/DiagnosticTest.java
>
> > For example, in this class we have several tests using a single Karaf
> > instance (depending of the @ExamReactorStrategy(PerClass.class)
> > annotation, PerClass meaning a single Karaf instance for all test
> > methods in the class).
>
> Nice! Can I add a feature repo and an extra feature to load easily on a
> class basis?
>
> I could do it with command line commands, I guess?
>
> I.e. add
> executeCommand("feature:repo-add
> mvn:no.priv.bang.modeling.modelstore/modelstore.backend/LATEST/xml/features");
> executeCommand("feature:install modelstore.backend");
> to all test methods?
>
> (it shouldn't matter much if I did in each test...? It should be a no-op
> if the feature is already loaded...?)
>
>

Re: jsoup 1.14.2 requires javax.annotation version between 3.0 and 4.0

[Eric Lilja]

When a dependency has provided scope, it is available at build time, but
not at runtime. It is also not contributed to the runtime classpath when
another module is depending on the module which has a declared provided
dependency. This choice by the Jsoup authors indicate it's build time only

Also, those annotations (NotNull, Nullable etc) are meant for an IDE, that
can detect certain API-misusage at source level (build level), like
explicit passing a null object (the IDE can figure out the object is always
null at that point) as a parameter, when the API is annotated @NotNull.

Anyway, I tried embedding the dependency in a service, and I removed the
problematic import and then I let the service do JSoup.connect() and get
the title of a webpage. My service was still satisfied and JSoup was able
to do what I requested. So instead of embedding you can simply do a re-pack
and remove the unwanted import.

Guava is another example, it has all these code analysis dependencies that
OSGi often wants to be provisioned, but can be omitted.

- Eric L



On Wed, Aug 25, 2021 at 6:37 PM Steinar Bang  wrote:

> > Steinar Bang :
>
> >> Is there a workaround, other than re-bundling jsoup?
>
> > One workaround would be to load version 3.0 (or so) of the glassfish
> > packaged javax.annotation...?
>
> > Since the packages are versioned it shouldn't conflict with the felix
> > version...?
>
> > (but it just feels so hacky...)
>
> FWIW what I've done, for now, is to put a compile
> dependency to the findbugs jar in the pom files that have the
> compile dependency to jsoup.
>
> Again, FWIW, this seems to work.
>
> The one package that also exist in the felix runtime (javax.annotation),
> have a different version, and a version matching jsoup, so they
> shouldn't conflict...?
>
>
>

Re: jsoup 1.14.2 requires javax.annotation version between 3.0 and 4.0

[Eric Lilja]

Is the findbugs dependency really a runtime requirement for jsoup to
function? It has provided in the pom file for jsoup

- Eric L

On Wed, Aug 25, 2021 at 10:58 AM Jean-Baptiste Onofré 
wrote:

> IMHO, a possible solution is that I create a SMX Spec bundle merging
> both jakarta annotation and findbugs/jsr305.
>
> Thoughts ?
>
> Regards
> JB
>
> On 24/08/2021 21:53, Steinar Bang wrote:
> >> Steinar Bang :
> >
> >> Steinar Bang :
> >>> (I'll also open a ticket on jsoup and try to have them fix it
> >>> upstream. Since upstream is an OSGi bundle, it seems a pity to have it
> >>> be a broken OSGi bundle...)
> >
> >> jsoup issue on the problem: https://github.com/jhy/jsoup/issues/1616
> >
> > I've created a PR that fixes the issue, by removing the version
> > requirements from the javax.annotation imports:
> >   https://github.com/jhy/jsoup/pull/1617
> >
> > But the problem is still not fixed, because jsoup also requires
> > javax.annotation.meta, which karaf does not provide.
> >
> > The "culprit" is a provded dependency to
> mvn:com.google.code.findbugs/jsr305/3.0.5
> >
> > See https://github.com/jhy/jsoup/issues/1616#issuecomment-904906532 for
> details.
> >
>

Re: instance:list causes warning

[Eric Lilja]

I tried this with a vanilla Karaf 4.2.11 under Windows 10, using Cygwin as
shell. I've simply unpacked the zip file to the root of my main drive.

I started Karaf with the "karaf" shell script (not the .bat-file).

instance:list produced no warning in console itself or in the karaf.log
file under data/log

Unrelated, but FYI JB: However, I did see a weird warning when starting
karaf using the shell script, see below:

$ ./karaf
: integer expression expected <---
__ __  
   / //_/ __ _/ __/
  / ,<  / __ `/ ___/ __ `/ /_
 / /| |/ /_/ / /  / /_/ / __/
/_/ |_|\__,_/_/   \__,_/_/

  Apache Karaf (4.2.11)

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

- Eric L


On Wed, May 12, 2021 at 7:05 PM JB Onofré  wrote:

> Hi
>
> Forgot to check, sorry about that. I will keep you posted.
>
> Regards
> JB
>
> Le 12 mai 2021 à 19:01, Steven Huypens  a
> écrit :
>
> 
> Hi Jean-Baptiste,
>
> Did you manage to reproduce this ?
>
> Kind regards,
> Steven
>
> On Tue, May 4, 2021 at 2:10 PM Jean-Baptiste Onofre 
> wrote:
>
>> Hi
>>
>> Thanks for the update. Let me try to reproduce it. I keep you posted.
>>
>> Regards
>> JB
>>
>> Le 4 mai 2021 à 14:07, Steven Huypens  a écrit
>> :
>>
>> Hi,
>>
>> - etc/org.apache.karaf.shell.cfg is the default Karaf file
>> - In etc/users.properties I had replaced the default Karaf user by my own
>> 'admin' with encrypted password. After reverting to the default
>> users.properties, and disabling encryption in org.apache.karaf.jaas.cfg,
>> the logline still appeared.
>>
>> Best regards,
>> Steven
>>
>> On Tue, May 4, 2021 at 1:43 PM Jean-Baptiste Onofre 
>> wrote:
>>
>>> Hi,
>>>
>>> What do you have in etc/org.apache.karaf.shell.cfg or
>>> etc/users.properties ?
>>>
>>> Regards
>>> JB
>>>
>>> Le 4 mai 2021 à 12:18, Steven Huypens  a
>>> écrit :
>>>
>>> Hi,
>>>
>>> When executing the command "instance:list" on our custom Karaf 4.2.11
>>> distro (based on 'standard'), we see the following warning in the logfile.
>>>
>>> *2021-05-04 12:07:12,138 -
>>> [o.a.s.s.s.ServerSessionImpl][sshd-SshServer[44db67ef](port=8101)-nio2-thread-2]
>>> WARN  -
>>> exceptionCaught(ServerSessionImpl[null@/127.0.0.1:54060])[state=Opened]
>>> IOException: De software op uw hostcomputer heeft een verbinding verbroken*
>>>
>>> It looks like an shh-connection is being made with username 'null',
>>> which obviously fails.
>>>
>>> This WARN is also logged when accessing the InstancesMBean, for instance
>>> by the decanter-collector-jmx.This means we see the WARN regularly in our
>>> logs.
>>>
>>> I would like to prevent this WARN-logline from being logged, but didn't
>>> find a way to configure the default username, nor to disable the Mbean.
>>>
>>> Any suggestions ?
>>>
>>> Kind regards,
>>> Steven
>>>
>>>
>>>
>>

Re: Update apache-httpclient to 4.15.3 to address CVE-2020-13956

[Eric Lilja]

Ah, great, thanks JB!

- Eric L

On Fri, Oct 23, 2020 at 6:29 AM Jean-Baptiste Onofre 
wrote:

> Hi Eric,
>
> Yup: https://issues.apache.org/jira/browse/KARAF-6890
>
> Regards
> JB
>
> Le 23 oct. 2020 à 03:19, Eric Lilja  a écrit :
>
> Nice! Great to see! But is there a Jira for this issue for the upcoming
> 4.2.11?
>
> - Eric L
>
> On Thu, Oct 22, 2020 at 7:17 AM Jean-Baptiste Onofre 
> wrote:
>
>> The update has been already merged ;)
>>
>> Thanks
>> Regards
>> JB
>>
>> > Le 21 oct. 2020 à 11:04, Pattan, Sachin  a
>> écrit :
>> >
>> > Dear Colleagues,
>> >
>> > As per https://bugzilla.redhat.com/show_bug.cgi?id=1886587 <
>> https://bugzilla.redhat.com/show_bug.cgi?id=1886587>, http.client
>> librarires below version 4.5.13 have the vulnerability CVE-2020-13956 (
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13956 <
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13956>).
>> >
>> > As Karaf 4.2.x rebundles http.client (4.5.6) classes as seen at
>> https://github.com/apache/karaf/blob/karaf-4.2.10/jaas/modules/pom.xml#L180
>> <
>> https://github.com/apache/karaf/blob/karaf-4.2.10/jaas/modules/pom.xml#L180>.
>> This makes it vulnerable and hence our security scans are detecting it as a
>> vulnerable library. I created the the PR
>> https://github.com/apache/karaf/pull/1243 <
>> https://github.com/apache/karaf/pull/1243> to update httpclient.version
>> to 4.5.13. Please take a look at it whenever it is possible and include it
>> in the upcoming release of Karaf 4.2.x if it fits good.
>> >
>> > Kind regards,
>> >
>> >
>> >
>> > Sachin Pattan
>> > The Tools Team
>> > WDF07  X1.65
>>
>>
>

Re: Update apache-httpclient to 4.15.3 to address CVE-2020-13956

[Eric Lilja]

Nice! Great to see! But is there a Jira for this issue for the upcoming
4.2.11?

- Eric L

On Thu, Oct 22, 2020 at 7:17 AM Jean-Baptiste Onofre 
wrote:

> The update has been already merged ;)
>
> Thanks
> Regards
> JB
>
> > Le 21 oct. 2020 à 11:04, Pattan, Sachin  a écrit
> :
> >
> > Dear Colleagues,
> >
> > As per https://bugzilla.redhat.com/show_bug.cgi?id=1886587 <
> https://bugzilla.redhat.com/show_bug.cgi?id=1886587>, http.client
> librarires below version 4.5.13 have the vulnerability CVE-2020-13956 (
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13956 <
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13956>).
> >
> > As Karaf 4.2.x rebundles http.client (4.5.6) classes as seen at
> https://github.com/apache/karaf/blob/karaf-4.2.10/jaas/modules/pom.xml#L180
> <
> https://github.com/apache/karaf/blob/karaf-4.2.10/jaas/modules/pom.xml#L180>.
> This makes it vulnerable and hence our security scans are detecting it as a
> vulnerable library. I created the the PR
> https://github.com/apache/karaf/pull/1243 <
> https://github.com/apache/karaf/pull/1243> to update httpclient.version
> to 4.5.13. Please take a look at it whenever it is possible and include it
> in the upcoming release of Karaf 4.2.x if it fits good.
> >
> > Kind regards,
> >
> >
> >
> > Sachin Pattan
> > The Tools Team
> > WDF07  X1.65
>
>

Re: paste broken on client console

[Eric Lilja]

Hi!

Is there any time to squeeze in an update of hibernate-validator (to
version 6.1.5.Final) in the 4.2.9 release?

Looking forward to 4.2.9, highly anticipated by many users, I suspect!

- Eric L

On Sun, May 17, 2020 at 8:09 AM Jean-Baptiste Onofre 
wrote:

> Hi,
>
> So I started the 4.2.9 release preparation. I will submit to vote today.
>
> Regards
> JB
>
> > Le 16 mai 2020 à 08:51, Markus Rathgeb  a écrit :
> >
> > Hi JB,
> > any news about the broken paste and help for the shell?
> > Karaf 4.2.9 is not released yet.
> > I need to introduce other developers to our codes and this two issues
> > are very annoying (command help does not work and you need to use
> > screen to have a working copy and paste).
> >
> > Has there been a jline release that is fixed?
> > Will it work on 4.2.8 custom distributions (I assume I can use a
> > feature / bundle override to use another jline version)?
> >
> > Best regards,
> > Markus
> >
> >
> > Am Di., 3. März 2020 um 14:44 Uhr schrieb Jean-Baptiste Onofre
> > :
> >>
> >> Catcha ;)
> >>
> >> I will a full pass on jline then ;)
> >>
> >> Regards
> >> JB
> >>
> >> Le 3 mars 2020 à 14:43, Alex Soto  a écrit :
> >>
> >> I know, trying to capitalize the moment :)
> >> On a different thread, I was seeking help trying to read a single
> character to implement pagination in one of my commands.
> >> It is s simple change since the impl class already has the method, it
> would help me.
> >>
> >> Best regards,
> >> Alex soto
> >>
> >>
> >>
> >>
> >> On Mar 3, 2020, at 8:33 AM, Jean-Baptiste Onofre 
> wrote:
> >>
> >> Hi Alex,
> >>
> >> You mean generally speaking for user usage ?
> >>
> >> Because, the two issues we are talking about here are not related to
> that ;)
> >>
> >> Regards
> >> JB
> >>
> >> Le 3 mars 2020 à 14:28, Alex Soto  a écrit :
> >>
> >> JB,
> >>
> >> Maybe you can expose method  readCharacter() in
> org.jline.reader.LineReader interface?
> >>
> >>
> >> Best regards,
> >> Alex soto
> >>
> >>
> >>
> >>
> >> On Mar 2, 2020, at 9:55 AM, Jean-Baptiste Onofre 
> wrote:
> >>
> >> By the way, about the InvocationTargetException, I will have to cut a
> new Felix Gogo release (updating for the jline breaking change).
> >>
> >> Regards
> >> JB
> >>
> >> Le 2 mars 2020 à 15:26, Markus Rathgeb  a écrit :
> >>
> >> Hi,
> >>
> >> it seems there has been  anew jline3 release three days ago (3.14.0).
> >> Is this correct?
> >>
> >> Does it contain the fix that's necessary to fix the Karaf shell?
> >>
> >> On Feb 10, 2020, at 2:59 PM, Jean-Baptiste Onofré 
> wrote:
> >>
> >> Hi
> >>
> >> I already have a fix and I?m looking for a workaround. Anyway a new
> jline release is required.
> >>
> >> Regards
> >> JB
> >>
> >> Le lun. 10 f?vr. 2020 ? 20:17, Oleg Cohen 
> a ?crit :
> >>
> >>
> >> Hi JB,
> >>
> >> Sorry to bug on this :-) Is there any idea when you might fix this
> issue?
> >>
> >> Thank you!
> >> Oleg
> >>
> >> On Feb 3, 2020, at 12:23 AM, Jean-Baptiste Onofr? 
> wrote:
> >>
> >> Hi,
> >>
> >> I found the commit causing issue in jline:
> >>
> >> commit fea903cc9e78da64d66422f07db1b7890cf18b89
> >> Author: Guillaume Nodet 
> >> Date: Mon Nov 25 20:45:30 2019 +0100
> >>
> >> Improve performances when pasting huge strings, fixes #479
> >>
> >> I will fix that and cut a new jline release.
> >>
> >> Regards
> >> JB
> >>
> >> On 02/02/2020 11:24, Markus Rathgeb wrote:
> >>
> >> Hi JB,
> >>
> >> thanks for keeping us up to date.
> >> I subscribed to the jline release notification, so I can update my
> >> custom distributions to jline 3.13.4 if released.
> >>
> >> Thanks!
> >>
> >> Best regards,
> >> Markus
> >>
> >>
> >> --
> >> Jean-Baptiste Onofr?
> >> jbono...@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
>

Re: Merry Christmas & releases on the way

[Eric Lilja]

Thanks for the update, JB!

Will KARAF-6480 [1] and KARAF-6514 [2] make it into 4.2.8?

[1] https://issues.apache.org/jira/browse/KARAF-6480
[2] https://issues.apache.org/jira/browse/KARAF-6514

- Eric L

On Wed, Dec 25, 2019 at 10:13 AM Jean-Baptiste Onofré 
wrote:

> Hi guys,
>
> on behalf of the Karaf team, I wish a Merry Christmas to the whole Karaf
> community.
>
> Let me use this mail to give you an update about releases:
> - Karaf 4.2.8 is planned before the end of this year (this week or early
> beginning of next week).
> - I do my best to cut 4.3.0.RC1 next week, but it's possible that I will
> cut the release first week of January (depending how fast I can be on
> 4.2.8 preparation).
> - Decanter 2.3.0 preparation moved well, but I have to release Karaf
> 4.2.8 first (as I have dependency to KarafTestSupport 4.2.8 for Decanter
> itests).
>
> I keep you posted !
>
> Again, Merry Christmas and enjoy time with family and friends.
>
> Regards
> JB
>
> On 11/10/2019 07:31, Jean-Baptiste Onofré wrote:
> > Hi guys,
> >
> > I've almost finished the refactoring of Cave for Cave 4.2.0 release:
> >
> > https://github.com/jbonofre/karaf-cave/tree/REFACTORING
> >
> > I'm polishing a bit this morning and merge to master later today.
> > I will prepare the Cave 4.2.0 during the week end.
> >
> > On the other hand, I moved forward on Karaf master heading to 4.3.0.RC1.
> > I should be able to push a first RC (RC1) beginning on next week.
> >
> > Meantime, I also moved forward on Decanter 2.3.0 preparation with new
> > improvements, fixes, etc.
> > The target is to submit this release in couple of weeks.
> >
> > Stay tuned !
> >
> > Regards
> > JB
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: session issues after Karaf 4.1.4->4.2.3 upgrade

[Eric Lilja]

Great, thanks JB!

On Tue, May 14, 2019 at 1:50 PM Jean-Baptiste Onofré 
wrote:

> Hi Eric,
>
> I'm working on the 4.2.6 preparation. My plan is to submit to vote
> during the week end.
>
> Regards
> JB
>
> On 14/05/2019 13:30, Eric Lilja wrote:
> > I saw that KARAF-6279 is now fixed, yay! Awesome! Are we ready for a
> > vote of 4.2.6 then or any other blocker/must-have remain? I see 39
> > issues remain open against this 4.2.6, but I assume most if not all will
> > be postponed till a later release)? Would be nice to see the release by
> > this weekend!
> >
> > - Eric L
> >
> > [1] https://issues.apache.org/jira/browse/KARAF-6279
> >
> >
> > On Sun, May 5, 2019 at 6:31 AM Jean-Baptiste Onofré  > <mailto:j...@nanthrax.net>> wrote:
> >
> > Agree, that's the plan.
> >
> > Regards
> > JB
> >
> > On 04/05/2019 20:34, Eric Lilja wrote:
> >  > I believe the session issue is a serious one, and it makes sense
> to
> >  > release Karaf 4.2.6 as soon as a fixed Pax-Web is available
> > (which I'm
> >  > hoping is soon). After that, I feel we have a solid and polished
> > Karaf
> >  > on our hands. Assuming the parameter passing issue on WIndows is
> > indeed
> >  > resolved, I don't know of any other major problems. They've been
> > dealt
> >  > with in the previous patch versions of Karaf 4.2.x
> >  >
> >  > - Eric L
> >  >
> >  > On Sat, May 4, 2019 at 10:25 AM Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>
> >  > <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>> wrote:
> >  >
> >  > Hi Brock,
> >  >
> >  > sorry I missed your message.
> >  >
> >  > I'm think it's related to the dual session listener
> > registration. It's
> >  > an issue in Pax Web. I think there's two session handlers.
> >  >
> >  > I'm already working on a fix in Pax Web, I will add a test
> > related to
> >  > your use case.
> >  >
> >  > Regards
> >  > JB
> >  >
> >  > On 29/04/2019 21:25, Brock Samson wrote:
> >  > > i have a Karaf-based app that contains a camel route with
> > multiple
> >  > >  instances that look something like this:
> >  > >
> >  > >
> >  > > * >  > >  continuationTimeout="4320"
> >  > >
> >  > serviceClass="com.teamcenter.esb.service.WebService"
> >  > >
> > address="http://0.0.0.0:8080/myapp/Endpoint1;>
> >  > > 
> >  > >  > class="com.foo.blah.MyAuthInterceptor"/>
> >  > > 
> >  > > 
> >  > >
> >  > >  >  > >  continuationTimeout="4320"
> >  > >
> >  > serviceClass="com.teamcenter.esb.service.WebService"
> >  > >
> > address="http://0.0.0.0:8080/myapp/Endpoint2;>
> >  > > 
> >  > >  > class="com.foo.blah.MyAuthInterceptor"/>
> >  > > 
> >  > > *
> >  > >
> >  > >
> >  > >
> >  > > while on Karaf 4.1.4, i was able to make all sorts of calls
> > to both
> >  > > endpoints while still on the same session, regardless of
> which
> >  > endpoint the
> >  > > session was created on. but now the only endpoint i am able
> to
> >  > access is the
> >  > > one where the session was created. any idea what is causing
> > this?
> >  > camel and
> >  > > cxf went from 2.20->2.23 and 3.2.1->3.2.7, respectively, so
> > that
> >  > was not
> >  > > much of a change. jetty on the other had did have a major
> > 9.3->9.4
> >  > move.
> >  > > thanks!
> >  > >
> >  > >
> >  > >
> >  > > --
> >  > > Sent from:
> > http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >  > >
> >  >
> >  > --
> >  > Jean-Baptiste Onofré
> >  > jbono...@apache.org <mailto:jbono...@apache.org>
> > <mailto:jbono...@apache.org <mailto:jbono...@apache.org>>
> >  > http://blog.nanthrax.net
> >  > Talend - http://www.talend.com
> >  >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org <mailto:jbono...@apache.org>
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>

Re: session issues after Karaf 4.1.4->4.2.3 upgrade

[Eric Lilja]

I saw that KARAF-6279 is now fixed, yay! Awesome! Are we ready for a vote
of 4.2.6 then or any other blocker/must-have remain? I see 39 issues remain
open against this 4.2.6, but I assume most if not all will be postponed
till a later release)? Would be nice to see the release by this weekend!

- Eric L

[1] https://issues.apache.org/jira/browse/KARAF-6279


On Sun, May 5, 2019 at 6:31 AM Jean-Baptiste Onofré  wrote:

> Agree, that's the plan.
>
> Regards
> JB
>
> On 04/05/2019 20:34, Eric Lilja wrote:
> > I believe the session issue is a serious one, and it makes sense to
> > release Karaf 4.2.6 as soon as a fixed Pax-Web is available (which I'm
> > hoping is soon). After that, I feel we have a solid and polished Karaf
> > on our hands. Assuming the parameter passing issue on WIndows is indeed
> > resolved, I don't know of any other major problems. They've been dealt
> > with in the previous patch versions of Karaf 4.2.x
> >
> > - Eric L
> >
> > On Sat, May 4, 2019 at 10:25 AM Jean-Baptiste Onofré  > <mailto:j...@nanthrax.net>> wrote:
> >
> > Hi Brock,
> >
> > sorry I missed your message.
> >
> > I'm think it's related to the dual session listener registration.
> It's
> > an issue in Pax Web. I think there's two session handlers.
> >
> > I'm already working on a fix in Pax Web, I will add a test related to
> > your use case.
> >
> > Regards
> > JB
> >
> > On 29/04/2019 21:25, Brock Samson wrote:
> > > i have a Karaf-based app that contains a camel route with multiple
> > >  instances that look something like this:
> > >
> > >
> > > * > >  continuationTimeout="4320"
> > >
> > serviceClass="com.teamcenter.esb.service.WebService"
> > >  address="http://0.0.0.0:8080/myapp/Endpoint1
> ">
> > > 
> > > 
> > > 
> > > 
> > >
> > >  > >  continuationTimeout="4320"
> > >
> > serviceClass="com.teamcenter.esb.service.WebService"
> > >  address="http://0.0.0.0:8080/myapp/Endpoint2
> ">
> > > 
> > > 
> > > 
> > > *
> > >
> > >
> > >
> > > while on Karaf 4.1.4, i was able to make all sorts of calls to both
> > > endpoints while still on the same session, regardless of which
> > endpoint the
> > > session was created on. but now the only endpoint i am able to
> > access is the
> > > one where the session was created. any idea what is causing this?
> > camel and
> > > cxf went from 2.20->2.23 and 3.2.1->3.2.7, respectively, so that
> > was not
> > > much of a change. jetty on the other had did have a major 9.3->9.4
> > move.
> > > thanks!
> > >
> > >
> > >
> > > --
> > > Sent from:
> http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org <mailto: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: session issues after Karaf 4.1.4->4.2.3 upgrade

[Eric Lilja]

I believe the session issue is a serious one, and it makes sense to release
Karaf 4.2.6 as soon as a fixed Pax-Web is available (which I'm hoping is
soon). After that, I feel we have a solid and polished Karaf on our hands.
Assuming the parameter passing issue on WIndows is indeed resolved, I don't
know of any other major problems. They've been dealt with in the previous
patch versions of Karaf 4.2.x

- Eric L

On Sat, May 4, 2019 at 10:25 AM Jean-Baptiste Onofré 
wrote:

> Hi Brock,
>
> sorry I missed your message.
>
> I'm think it's related to the dual session listener registration. It's
> an issue in Pax Web. I think there's two session handlers.
>
> I'm already working on a fix in Pax Web, I will add a test related to
> your use case.
>
> Regards
> JB
>
> On 29/04/2019 21:25, Brock Samson wrote:
> > i have a Karaf-based app that contains a camel route with multiple
> >  instances that look something like this:
> >
> >
> > * >  continuationTimeout="4320"
> >  serviceClass="com.teamcenter.esb.service.WebService"
> >  address="http://0.0.0.0:8080/myapp/Endpoint1;>
> > 
> > 
> > 
> > 
> >
> >  >  continuationTimeout="4320"
> >  serviceClass="com.teamcenter.esb.service.WebService"
> >  address="http://0.0.0.0:8080/myapp/Endpoint2;>
> > 
> > 
> > 
> > *
> >
> >
> >
> > while on Karaf 4.1.4, i was able to make all sorts of calls to both
> > endpoints while still on the same session, regardless of which endpoint
> the
> > session was created on. but now the only endpoint i am able to access is
> the
> > one where the session was created. any idea what is causing this? camel
> and
> > cxf went from 2.20->2.23 and 3.2.1->3.2.7, respectively, so that was not
> > much of a change. jetty on the other had did have a major 9.3->9.4 move.
> > thanks!
> >
> >
> >
> > --
> > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Karaf-4.2.4 - Unexpected SCR behavior

[Eric Lilja]

Ah, great news, thank you, JB!

- Eric L

On Thu, Apr 11, 2019 at 3:51 PM Jean-Baptiste Onofré 
wrote:

> Yes, I'm testing the upgrade to Hibernate 5.4.2.Final (Hibernate 5.2.x
> will be part of enterprise-legacy feature).
>
> The PR should be ready today.
>
> Regards
> JB
>
> On 11/04/2019 15:41, Eric Lilja wrote:
> > How's it looking for KARAF-6199 - Upgrade Hibernate feature to work with
> > Java 11, will it also be part of 4.2.5 as Jira currently claims?
> >
> > - Eric L
> >
> > On Thu, Apr 11, 2019 at 10:24 AM Jean-Baptiste Onofré  > <mailto:j...@nanthrax.net>> wrote:
> >
> > Hi,
> >
> > I'm on KARAF-6229, it will be included in 4.2.5.
> >
> > For Pax Web, I will take a look, but I will release 4.2.5 with
> current
> > Pax Web version, and I will do a new 4.2.x with Pax Web updated.
> >
> > Regards
> > JB
> >
> > On 11/04/2019 09:57, Eric Lilja wrote:
> > > I guess we also need a new pax-web with a fix for the
> SessionListener
> > > being registered twice (not sure it has a Jira?) and a fix for
> > > KARAF-6229 (karaf-maven-plugin deploy/install zip twice) before
> 4.2.5
> > > can be released?
> > >
> > > - Eric L
> > >
> > > On Mon, Apr 8, 2019 at 2:17 PM Eric Lilja  > <mailto:mindcoo...@gmail.com>
> > > <mailto:mindcoo...@gmail.com <mailto:mindcoo...@gmail.com>>>
> wrote:
> > >
> > > Thanks for the update, JB!
> > >
> > > On Mon, Apr 8, 2019 at 1:32 PM Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>
> > > <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>> wrote:
> > >
> > > Hi,
> > >
> > > As said last week, I have some other issues on the way.
> > >
> > > My plan is to submit 4.2.5 to vote by the end of this week.
> > >
> > > Regards
> > > JB
> > >
> > > On 08/04/2019 11:36, Eric Lilja wrote:
> > > > I saw on Jira that this issue has been fixed (yay!), how
> far
> > > are we now
> > > > from a vote on Karaf 4.2.5, i.e., what other fixes need
> > to go
> > > into the
> > > > release? Any chance for Karaf 4.2.5 to be out before the
> > > weekend? Just
> > > > asking, since we're starting a new project on Friday,
> and I
> > > intend to
> > > > use Karaf in it.
> > > >
> > > > - Eric L
> > > >
> > > > On Thu, Apr 4, 2019 at 3:27 PM Erwin Hogeweg
> > > mailto:erwin.hoge...@me.com>
> > <mailto:erwin.hoge...@me.com <mailto:erwin.hoge...@me.com>>
> > > > <mailto:erwin.hoge...@me.com
> > <mailto:erwin.hoge...@me.com> <mailto:erwin.hoge...@me.com
> > <mailto:erwin.hoge...@me.com>>>>
> > > wrote:
> > > >
> > > > Thanks JB.
> > > >
> > > > Erwin
> > > >
> > > >
> > > > > On Apr 4, 2019, at 02:27, Jean-Baptiste Onofré
> > > mailto:j...@nanthrax.net>
> > <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>
> > > > <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>
> > <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>>> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I found the cause of this change: Felix SCR doesn't
> > > "embed" the
> > > > > ComponentCommandsConverter anymore, it uses a
> service
> > > reference.
> > > > > The Converter is expected to be provided by gogo
> > > runtime/karaf shell,
> > > > > but it's not.
> > > > >
> > > > > I'm fixing that, PR will follow.
> > > > >
> > > > > I have som

Re: Karaf-4.2.4 - Unexpected SCR behavior

[Eric Lilja]

How's it looking for KARAF-6199 - Upgrade Hibernate feature to work with
Java 11, will it also be part of 4.2.5 as Jira currently claims?

- Eric L

On Thu, Apr 11, 2019 at 10:24 AM Jean-Baptiste Onofré 
wrote:

> Hi,
>
> I'm on KARAF-6229, it will be included in 4.2.5.
>
> For Pax Web, I will take a look, but I will release 4.2.5 with current
> Pax Web version, and I will do a new 4.2.x with Pax Web updated.
>
> Regards
> JB
>
> On 11/04/2019 09:57, Eric Lilja wrote:
> > I guess we also need a new pax-web with a fix for the SessionListener
> > being registered twice (not sure it has a Jira?) and a fix for
> > KARAF-6229 (karaf-maven-plugin deploy/install zip twice) before 4.2.5
> > can be released?
> >
> > - Eric L
> >
> > On Mon, Apr 8, 2019 at 2:17 PM Eric Lilja  > <mailto:mindcoo...@gmail.com>> wrote:
> >
> > Thanks for the update, JB!
> >
> > On Mon, Apr 8, 2019 at 1:32 PM Jean-Baptiste Onofré  > <mailto:j...@nanthrax.net>> wrote:
> >
> > Hi,
> >
> > As said last week, I have some other issues on the way.
> >
> > My plan is to submit 4.2.5 to vote by the end of this week.
> >
> > Regards
> > JB
> >
> > On 08/04/2019 11:36, Eric Lilja wrote:
> > > I saw on Jira that this issue has been fixed (yay!), how far
> > are we now
> > > from a vote on Karaf 4.2.5, i.e., what other fixes need to go
> > into the
> > > release? Any chance for Karaf 4.2.5 to be out before the
> > weekend? Just
> > > asking, since we're starting a new project on Friday, and I
> > intend to
> > > use Karaf in it.
> > >
> > > - Eric L
> > >
> > > On Thu, Apr 4, 2019 at 3:27 PM Erwin Hogeweg
> > mailto:erwin.hoge...@me.com>
> > > <mailto:erwin.hoge...@me.com <mailto:erwin.hoge...@me.com>>>
> > wrote:
> > >
> > > Thanks JB.
> > >
> > > Erwin
> > >
> > >
> > > > On Apr 4, 2019, at 02:27, Jean-Baptiste Onofré
> > mailto:j...@nanthrax.net>
> > > <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I found the cause of this change: Felix SCR doesn't
> > "embed" the
> > > > ComponentCommandsConverter anymore, it uses a service
> > reference.
> > > > The Converter is expected to be provided by gogo
> > runtime/karaf shell,
> > > > but it's not.
> > > >
> > > > I'm fixing that, PR will follow.
> > > >
> > > > I have some other fixes on the way, we can expect Karaf
> > 4.2.5 for
> > > next week.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On 24/03/2019 15:52, Erwin Hogeweg wrote:
> > > >> Hi,
> > > >>
> > > >> I upgraded a project to Karaf-4.2.4, which went very
> > smooth. Kudos to
> > > >> the Karaf team.
> > > >>
> > > >> The only issue I am struggling with is the behavior of
> > the scr
> > > command.
> > > >> scr:list used to give a clear list with installed
> > components, now it
> > > >> returns a hard to read JSON string. Also scr:info 
> > used to
> > > show the
> > > >> details of a component, now it throws an error. See
> below.
> > > >>
> > > >> Am I missing something?
> > > >>
> > > >> Kind Regards,
> > > >>
> > > >> Erwin
> > > >>
> > > >>
> > > >>
> > > >> *karaf*@root()> feature:installscr
> > > >> *karaf*@root()> scr:list
> > > >&g

Re: Karaf-4.2.4 - Unexpected SCR behavior

[Eric Lilja]

I guess we also need a new pax-web with a fix for the SessionListener being
registered twice (not sure it has a Jira?) and a fix for KARAF-6229
(karaf-maven-plugin deploy/install zip twice) before 4.2.5 can be released?

- Eric L

On Mon, Apr 8, 2019 at 2:17 PM Eric Lilja  wrote:

> Thanks for the update, JB!
>
> On Mon, Apr 8, 2019 at 1:32 PM Jean-Baptiste Onofré 
> wrote:
>
>> Hi,
>>
>> As said last week, I have some other issues on the way.
>>
>> My plan is to submit 4.2.5 to vote by the end of this week.
>>
>> Regards
>> JB
>>
>> On 08/04/2019 11:36, Eric Lilja wrote:
>> > I saw on Jira that this issue has been fixed (yay!), how far are we now
>> > from a vote on Karaf 4.2.5, i.e., what other fixes need to go into the
>> > release? Any chance for Karaf 4.2.5 to be out before the weekend? Just
>> > asking, since we're starting a new project on Friday, and I intend to
>> > use Karaf in it.
>> >
>> > - Eric L
>> >
>> > On Thu, Apr 4, 2019 at 3:27 PM Erwin Hogeweg > > <mailto:erwin.hoge...@me.com>> wrote:
>> >
>> > Thanks JB.
>> >
>> > Erwin
>> >
>> >
>> > > On Apr 4, 2019, at 02:27, Jean-Baptiste Onofré > > <mailto:j...@nanthrax.net>> wrote:
>> > >
>> > > Hi,
>> > >
>> > > I found the cause of this change: Felix SCR doesn't "embed" the
>> > > ComponentCommandsConverter anymore, it uses a service reference.
>> > > The Converter is expected to be provided by gogo runtime/karaf
>> shell,
>> > > but it's not.
>> > >
>> > > I'm fixing that, PR will follow.
>> > >
>> > > I have some other fixes on the way, we can expect Karaf 4.2.5 for
>> > next week.
>> > >
>> > > Regards
>> > > JB
>> > >
>> > > On 24/03/2019 15:52, Erwin Hogeweg wrote:
>> > >> Hi,
>> > >>
>> > >> I upgraded a project to Karaf-4.2.4, which went very smooth.
>> Kudos to
>> > >> the Karaf team.
>> > >>
>> > >> The only issue I am struggling with is the behavior of the scr
>> > command.
>> > >> scr:list used to give a clear list with installed components,
>> now it
>> > >> returns a hard to read JSON string. Also scr:info  used to
>> > show the
>> > >> details of a component, now it throws an error. See below.
>> > >>
>> > >> Am I missing something?
>> > >>
>> > >> Kind Regards,
>> > >>
>> > >> Erwin
>> > >>
>> > >>
>> > >>
>> > >> *karaf*@root()> feature:installscr
>> > >> *karaf*@root()> scr:list
>> > >> {"name":"ServiceCo...timeMBean", "bundle":{"id":46,
>> > >> "lastModified":1553439020606, "state":32,
>> > >> "symbolicName":"org.apach...anagement", "version":"4.2.4"},
>> > >> "factory":null, "scope":"singleton",
>> > >> "implementationClass":"org.apach...MBeanImpl",
>> "defaultEnabled":true,
>> > >> "immediate":true, "serviceInterfaces":["org.apach...timeMBean"],
>> > >> "properties":{"hidden.component":"true"},
>> > >> "references":[{"name":"ScrService",
>> > >> "interfaceName":"org.osgintRuntime", "cardinality":"1..1",
>> > >> "policy":"static", "policyOption":"reluctant", "target":null,
>> > >> "bind":"setScrService", "unbind":"unsetScrService",
>> "updated":null,
>> > >> "field":null, "fieldOption":null, "scope":"bundle",
>> "parameter":null,
>> > >> "collectionType":null},{"name":"mBeanServer",
>> > >> "interfaceName":"javax.man...eanServer", "cardinality":"1..1",
>> > >> "policy":"static", "policyOption":"reluctant", "target":null,
>> > >> "bind":"setmBeanServer", "unbind":"unsetmBeanServer",
>> "updated":null,
>> > >> "field":null, "fieldOption":null, "scope":"bundle",
>> "parameter":null,
>> > >> "collectionType":null}], "activate":"activate",
>> > >> "deactivate":"deactivate", "modified":null,
>> > >> "configurationPolicy":"optional",
>> > >> "configurationPid":["ServiceCo...timeMBean"],
>> > "factoryProperties":null,
>> > >> "activationFields":[], "init":0}
>> > >>
>> > >>
>> > >> *karaf*@root()> scr:info0
>> > >> 10:18:38.884 [Karaf local console user karaf] ERROR
>> > >> org.apache.karaf.shell.support.ShellUtil - Exception caught while
>> > >> executing command
>> > >> java.lang.IllegalArgumentException: No component description
>> > matching "0".
>> > >>
>> > >> *karaf*@root()> la|grep-i scr
>> > >> 46 │ Active   │  30 │ 4.2.4  │ Apache Karaf ::
>> *SCR*::
>> > >> Management MBeans
>> > >> 47 │ Active   │  30 │ 4.2.4  │ Apache Karaf ::
>> *SCR*::
>> > >> Bundle State
>> > >>
>> > >
>> > > --
>> > > Jean-Baptiste Onofré
>> > > jbono...@apache.org <mailto: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: Karaf-4.2.4 - Unexpected SCR behavior

[Eric Lilja]

Thanks for the update, JB!

On Mon, Apr 8, 2019 at 1:32 PM Jean-Baptiste Onofré  wrote:

> Hi,
>
> As said last week, I have some other issues on the way.
>
> My plan is to submit 4.2.5 to vote by the end of this week.
>
> Regards
> JB
>
> On 08/04/2019 11:36, Eric Lilja wrote:
> > I saw on Jira that this issue has been fixed (yay!), how far are we now
> > from a vote on Karaf 4.2.5, i.e., what other fixes need to go into the
> > release? Any chance for Karaf 4.2.5 to be out before the weekend? Just
> > asking, since we're starting a new project on Friday, and I intend to
> > use Karaf in it.
> >
> > - Eric L
> >
> > On Thu, Apr 4, 2019 at 3:27 PM Erwin Hogeweg  > <mailto:erwin.hoge...@me.com>> wrote:
> >
> > Thanks JB.
> >
> > Erwin
> >
> >
> > > On Apr 4, 2019, at 02:27, Jean-Baptiste Onofré  > <mailto:j...@nanthrax.net>> wrote:
> > >
> > > Hi,
> > >
> > > I found the cause of this change: Felix SCR doesn't "embed" the
> > > ComponentCommandsConverter anymore, it uses a service reference.
> > > The Converter is expected to be provided by gogo runtime/karaf
> shell,
> > > but it's not.
> > >
> > > I'm fixing that, PR will follow.
> > >
> > > I have some other fixes on the way, we can expect Karaf 4.2.5 for
> > next week.
> > >
> > > Regards
> > > JB
> > >
> > > On 24/03/2019 15:52, Erwin Hogeweg wrote:
> > >> Hi,
> > >>
> > >> I upgraded a project to Karaf-4.2.4, which went very smooth.
> Kudos to
> > >> the Karaf team.
> > >>
> > >> The only issue I am struggling with is the behavior of the scr
> > command.
> > >> scr:list used to give a clear list with installed components, now
> it
> > >> returns a hard to read JSON string. Also scr:info  used to
> > show the
> > >> details of a component, now it throws an error. See below.
> > >>
> > >> Am I missing something?
> > >>
> > >> Kind Regards,
> > >>
> > >> Erwin
> > >>
> > >>
> > >>
> > >> *karaf*@root()> feature:installscr
> > >> *karaf*@root()> scr:list
> > >> {"name":"ServiceCo...timeMBean", "bundle":{"id":46,
> > >> "lastModified":1553439020606, "state":32,
> > >> "symbolicName":"org.apach...anagement", "version":"4.2.4"},
> > >> "factory":null, "scope":"singleton",
> > >> "implementationClass":"org.apach...MBeanImpl",
> "defaultEnabled":true,
> > >> "immediate":true, "serviceInterfaces":["org.apach...timeMBean"],
> > >> "properties":{"hidden.component":"true"},
> > >> "references":[{"name":"ScrService",
> > >> "interfaceName":"org.osgintRuntime", "cardinality":"1..1",
> > >> "policy":"static", "policyOption":"reluctant", "target":null,
> > >> "bind":"setScrService", "unbind":"unsetScrService",
> "updated":null,
> > >> "field":null, "fieldOption":null, "scope":"bundle",
> "parameter":null,
> > >> "collectionType":null},{"name":"mBeanServer",
> > >> "interfaceName":"javax.man...eanServer", "cardinality":"1..1",
> > >> "policy":"static", "policyOption":"reluctant", "target":null,
> > >> "bind":"setmBeanServer", "unbind":"unsetmBeanServer",
> "updated":null,
> > >> "field":null, "fieldOption":null, "scope":"bundle",
> "parameter":null,
> > >> "collectionType":null}], "activate":"activate",
> > >> "deactivate":"deactivate", "modified":null,
> > >> "configurationPolicy":"optional",
> > >> "configurationPid":["ServiceCo...timeMBean"],
> > "factoryProperties":null,
> > >> "activationFields":[], "init":0}
> > >>
> > >>
> > >> *karaf*@root()> scr:info0
> > >> 10:18:38.884 [Karaf local console user karaf] ERROR
> > >> org.apache.karaf.shell.support.ShellUtil - Exception caught while
> > >> executing command
> > >> java.lang.IllegalArgumentException: No component description
> > matching "0".
> > >>
> > >> *karaf*@root()> la|grep-i scr
> > >> 46 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> > >> Management MBeans
> > >> 47 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> > >> Bundle State
> > >>
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org <mailto: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: Karaf-4.2.4 - Unexpected SCR behavior

[Eric Lilja]

Nice you found it! Can't wait for 4.2.5! Will this fix be a change in gogo
or karaf?

- Eric L

On Thu, Apr 4, 2019 at 8:31 AM Jean-Baptiste Onofré  wrote:

> Hi,
>
> I found the cause of this change: Felix SCR doesn't "embed" the
> ComponentCommandsConverter anymore, it uses a service reference.
> The Converter is expected to be provided by gogo runtime/karaf shell,
> but it's not.
>
> I'm fixing that, PR will follow.
>
> I have some other fixes on the way, we can expect Karaf 4.2.5 for next
> week.
>
> Regards
> JB
>
> On 24/03/2019 15:52, Erwin Hogeweg wrote:
> > Hi,
> >
> > I upgraded a project to Karaf-4.2.4, which went very smooth. Kudos to
> > the Karaf team.
> >
> > The only issue I am struggling with is the behavior of the scr command.
> > scr:list used to give a clear list with installed components, now it
> > returns a hard to read JSON string. Also scr:info  used to show the
> > details of a component, now it throws an error. See below.
> >
> > Am I missing something?
> >
> > Kind Regards,
> >
> > Erwin
> >
> >
> >
> > *karaf*@root()> feature:installscr
> > *karaf*@root()> scr:list
> > {"name":"ServiceCo...timeMBean", "bundle":{"id":46,
> > "lastModified":1553439020606, "state":32,
> > "symbolicName":"org.apach...anagement", "version":"4.2.4"},
> > "factory":null, "scope":"singleton",
> > "implementationClass":"org.apach...MBeanImpl", "defaultEnabled":true,
> > "immediate":true, "serviceInterfaces":["org.apach...timeMBean"],
> > "properties":{"hidden.component":"true"},
> > "references":[{"name":"ScrService",
> > "interfaceName":"org.osgintRuntime", "cardinality":"1..1",
> > "policy":"static", "policyOption":"reluctant", "target":null,
> > "bind":"setScrService", "unbind":"unsetScrService", "updated":null,
> > "field":null, "fieldOption":null, "scope":"bundle", "parameter":null,
> > "collectionType":null},{"name":"mBeanServer",
> > "interfaceName":"javax.man...eanServer", "cardinality":"1..1",
> > "policy":"static", "policyOption":"reluctant", "target":null,
> > "bind":"setmBeanServer", "unbind":"unsetmBeanServer", "updated":null,
> > "field":null, "fieldOption":null, "scope":"bundle", "parameter":null,
> > "collectionType":null}], "activate":"activate",
> > "deactivate":"deactivate", "modified":null,
> > "configurationPolicy":"optional",
> > "configurationPid":["ServiceCo...timeMBean"], "factoryProperties":null,
> > "activationFields":[], "init":0}
> >
> >
> > *karaf*@root()> scr:info0
> > 10:18:38.884 [Karaf local console user karaf] ERROR
> > org.apache.karaf.shell.support.ShellUtil - Exception caught while
> > executing command
> > java.lang.IllegalArgumentException: No component description matching
> "0".
> >
> > *karaf*@root()> la|grep-i scr
> > 46 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> > Management MBeans
> > 47 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> > Bundle State
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Karaf-4.2.4 - Unexpected SCR behavior

[Eric Lilja]

Hi JB! That is great news both for me and my organization, looking forward
to seeing Karaf 4.2.5 soonish then! On a side note, it is also possible to
get hibernate-validator 6.0.16 as part of it?

- Eric L

On Tue, Mar 26, 2019 at 12:01 PM Jean-Baptiste Onofré 
wrote:

> Hi Eric,
>
> I'm fixing that (and couple of other issues), then I will submit 4.2.5
> to vote.
>
> Regards
> JB
>
> On 26/03/2019 11:45, Eric Lilja wrote:
> > Is it possible we can get a 4.2.5 when this has been fixed (I see a few
> > other JIRAs has been fixed as well)? This functionality is essential to
> > us as we have a lot of interactive users and I believe this problem will
> > make it hard for my organization to move up to 4.2.x (and we want to use
> > the latest patch-release)
> >
> > - Eric L
> >
> > On Sun, Mar 24, 2019 at 6:48 PM Erwin Hogeweg  > <mailto:erwin.hoge...@me.com>> wrote:
> >
> > Thanks JB.
> >
> > Erwin
> >
> >
> > > On Mar 24, 2019, at 12:05, Jean-Baptiste Onofré  > <mailto:j...@nanthrax.net>> wrote:
> > >
> > > Hi Erwin,
> > >
> > > That's due to change in Felix SCR.
> > >
> > > I will fix that in Karaf, sorry about that.
> > >
> > > scr:info works for me, but I will double check.
> > >
> > > Regards
> > > JB
> > >
> > > On 24/03/2019 15:52, Erwin Hogeweg wrote:
> > >> Hi,
> > >>
> > >> I upgraded a project to Karaf-4.2.4, which went very smooth.
> Kudos to
> > >> the Karaf team.
> > >>
> > >> The only issue I am struggling with is the behavior of the scr
> > command.
> > >> scr:list used to give a clear list with installed components, now
> it
> > >> returns a hard to read JSON string. Also scr:info  used to
> > show the
> > >> details of a component, now it throws an error. See below.
> > >>
> > >> Am I missing something?
> > >>
> > >> Kind Regards,
> > >>
> > >> Erwin
> > >>
> > >>
> > >>
> > >> *karaf*@root()> feature:installscr
> > >> *karaf*@root()> scr:list
> > >> {"name":"ServiceCo...timeMBean", "bundle":{"id":46,
> > >> "lastModified":1553439020606, "state":32,
> > >> "symbolicName":"org.apach...anagement", "version":"4.2.4"},
> > >> "factory":null, "scope":"singleton",
> > >> "implementationClass":"org.apach...MBeanImpl",
> "defaultEnabled":true,
> > >> "immediate":true, "serviceInterfaces":["org.apach...timeMBean"],
> > >> "properties":{"hidden.component":"true"},
> > >> "references":[{"name":"ScrService",
> > >> "interfaceName":"org.osgintRuntime", "cardinality":"1..1",
> > >> "policy":"static", "policyOption":"reluctant", "target":null,
> > >> "bind":"setScrService", "unbind":"unsetScrService",
> "updated":null,
> > >> "field":null, "fieldOption":null, "scope":"bundle",
> "parameter":null,
> > >> "collectionType":null},{"name":"mBeanServer",
> > >> "interfaceName":"javax.man...eanServer", "cardinality":"1..1",
> > >> "policy":"static", "policyOption":"reluctant", "target":null,
> > >> "bind":"setmBeanServer", "unbind":"unsetmBeanServer",
> "updated":null,
> > >> "field":null, "fieldOption":null, "scope":"bundle",
> "parameter":null,
> > >> "collectionType":null}], "activate":"activate",
> > >> "deactivate":"deactivate", "modified":null,
> > >> "configurationPolicy":"optional",
> > >> "configurationPid":["ServiceCo...timeMBean"],
> > "factoryProperties":null,
> > >> "activationFields":[], "init":0}
> > >>
> > >>
> > >> *karaf*@root()> scr:info0
> > >> 10:18:38.884 [Karaf local console user karaf] ERROR
> > >> org.apache.karaf.shell.support.ShellUtil - Exception caught while
> > >> executing command
> > >> java.lang.IllegalArgumentException: No component description
> > matching "0".
> > >>
> > >> *karaf*@root()> la|grep-i scr
> > >> 46 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> > >> Management MBeans
> > >> 47 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> > >> Bundle State
> > >>
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org <mailto: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: Karaf-4.2.4 - Unexpected SCR behavior

[Eric Lilja]

Is it possible we can get a 4.2.5 when this has been fixed (I see a few
other JIRAs has been fixed as well)? This functionality is essential to us
as we have a lot of interactive users and I believe this problem will make
it hard for my organization to move up to 4.2.x (and we want to use the
latest patch-release)

- Eric L

On Sun, Mar 24, 2019 at 6:48 PM Erwin Hogeweg  wrote:

> Thanks JB.
>
> Erwin
>
>
> > On Mar 24, 2019, at 12:05, Jean-Baptiste Onofré  wrote:
> >
> > Hi Erwin,
> >
> > That's due to change in Felix SCR.
> >
> > I will fix that in Karaf, sorry about that.
> >
> > scr:info works for me, but I will double check.
> >
> > Regards
> > JB
> >
> > On 24/03/2019 15:52, Erwin Hogeweg wrote:
> >> Hi,
> >>
> >> I upgraded a project to Karaf-4.2.4, which went very smooth. Kudos to
> >> the Karaf team.
> >>
> >> The only issue I am struggling with is the behavior of the scr command.
> >> scr:list used to give a clear list with installed components, now it
> >> returns a hard to read JSON string. Also scr:info  used to show the
> >> details of a component, now it throws an error. See below.
> >>
> >> Am I missing something?
> >>
> >> Kind Regards,
> >>
> >> Erwin
> >>
> >>
> >>
> >> *karaf*@root()> feature:installscr
> >> *karaf*@root()> scr:list
> >> {"name":"ServiceCo...timeMBean", "bundle":{"id":46,
> >> "lastModified":1553439020606, "state":32,
> >> "symbolicName":"org.apach...anagement", "version":"4.2.4"},
> >> "factory":null, "scope":"singleton",
> >> "implementationClass":"org.apach...MBeanImpl", "defaultEnabled":true,
> >> "immediate":true, "serviceInterfaces":["org.apach...timeMBean"],
> >> "properties":{"hidden.component":"true"},
> >> "references":[{"name":"ScrService",
> >> "interfaceName":"org.osgintRuntime", "cardinality":"1..1",
> >> "policy":"static", "policyOption":"reluctant", "target":null,
> >> "bind":"setScrService", "unbind":"unsetScrService", "updated":null,
> >> "field":null, "fieldOption":null, "scope":"bundle", "parameter":null,
> >> "collectionType":null},{"name":"mBeanServer",
> >> "interfaceName":"javax.man...eanServer", "cardinality":"1..1",
> >> "policy":"static", "policyOption":"reluctant", "target":null,
> >> "bind":"setmBeanServer", "unbind":"unsetmBeanServer", "updated":null,
> >> "field":null, "fieldOption":null, "scope":"bundle", "parameter":null,
> >> "collectionType":null}], "activate":"activate",
> >> "deactivate":"deactivate", "modified":null,
> >> "configurationPolicy":"optional",
> >> "configurationPid":["ServiceCo...timeMBean"], "factoryProperties":null,
> >> "activationFields":[], "init":0}
> >>
> >>
> >> *karaf*@root()> scr:info0
> >> 10:18:38.884 [Karaf local console user karaf] ERROR
> >> org.apache.karaf.shell.support.ShellUtil - Exception caught while
> >> executing command
> >> java.lang.IllegalArgumentException: No component description matching
> "0".
> >>
> >> *karaf*@root()> la|grep-i scr
> >> 46 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> >> Management MBeans
> >> 47 │ Active   │  30 │ 4.2.4  │ Apache Karaf :: *SCR*::
> >> Bundle State
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
>

Re: Karaf-4.2.0 - "Unknown protocol: mvn" exception running custom distro - Reproducible

[Eric Lilja]

Sounds like pax-url-link is not available

On Sun, Aug 5, 2018 at 5:40 PM Jean-Baptiste Onofré  wrote:

> Hi,
>
> that's probably because your boot features set is not complete.
>
> What do you have there ?
>
> It's important to not have only standard but all boot features.
>
> Regards
> JB
>
> On 05/08/2018 14:22, Erwin Hogeweg wrote:
> > Hi Mike,
> >
> > I added the webconsole feature as a requirement to the project
> > feature.xml and removed it from the disco pom.xml.
> >
> >  > Server Karaf Feature">
> > cxf-jaxrs
> > cxf-dosgi-discovery-local
> > webconsole
> > war
> > ...
> >
> > That solved the problem for me but I don’t understand it yet. I am
> > eagerly awaiting the 4.2.1 release because JB mentioned he added some
> > info and examples re. custom distros.
> >
> >
> > Regards,
> >
> > Erwin
> >
> >> On Aug 2, 2018, at 10:57, Mike Gingell  >> > wrote:
> >>
> >> I am having the same issue.  Were you able to solve this?
> >> Thanks,
> >> - Mike
> >>
> >>
> >>
> >> --
> >> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Karaf 2.3.7 not found on maven central

[Eric Lilja]

Hi, I noticed that Karaf 2.3.7 was announced a few days ago, that's 
great (although I can't wait for 2.3.8). However, it doesn't seem to 
have reached maven central yet:

http://bit.ly/1wfl4kZ

Surely the artifacts should be there by now if things had worked? 2.3.6 
is there.


Thanks for a great job!

- EL