Re: paste broken on client console

[Markus Rathgeb]

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: OSGi R7 HTTP static resources and JAXRS whiteboard issue

[Markus Rathgeb]

I don't think you need to use
"replace.loopback.address.with.localhost" to solve your problem.
IMHO changing the default.application.base should be enough.


Am Mi., 11. März 2020 um 10:54 Uhr schrieb Maurice Betzel
:
>
> You must set default.application.base as well. I set it to :
>
> default.application.base=/api/rest/
>
> and removed it from the Path annotation leaving /@Path("hero")/
>
> CXF docs:
>
> http://cxf.apache.org/docs/jax-rs.html
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi R7 HTTP static resources and JAXRS whiteboard issue

[Markus Rathgeb]

Can you try to create a configuration for
"org.apache.aries.jax.rs.whiteboard.default" (e.g. by a file in etc
called "org.apache.aries.jax.rs.whiteboard.default.cfg"):

default.web=false
default.application.base=/jax-rs-whiteboard-default
replace.loopback.address.with.localhost=false

this disabled the default JAX-RS Whiteboard page. It also change the
default application path so it does not collide with another one.

Am Di., 10. März 2020 um 20:04 Uhr schrieb Maurice Betzel
:
>
> Hi all,
>
> I am experimenting with Karaf 4.3.0.RC1, Felix-http and Aries JAXRS to get
> Angular up and running. The JAXRS backend bundle is a recent Christian
> Schneider github example, the frontend bundle a Angular 9 hello world
> packaged with bnd @HttpWhiteboardResource having the Angular static content
> is in the root of the jar.
> Both get bound to the default http context, having the ReST api endpoint on
> /api/rest/hero and the static content accessible  on /heroes/*.
> Each bundle separate does what it’s supposed to do, if I start both I get
> 404 on the Angular. If I stop the Aries JAXRS whiteboard bundle I can access
> the static content again. The other way around and both work producing data
> in the frontend.
> Any ideas? Should I use separate http contexts? Equinox examples I studied
> equal my code, and the fast amount of configuration in the OSGi ref makes my
> head spin.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: paste broken on client console

[Markus Rathgeb]

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

Karaf 4.2.8: shell help broken

[Markus Rathgeb]

Hi,

if I call "help" on the Karaf 4.2.8 shell I get an error message
"Error executing command:
java.lang.reflect.InvocationTargetException".

The log contains some more details:

15:22:33.279 ERROR [Karaf local console user karaf] Exception caught
while executing command
java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_202]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_202]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_202]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_202]
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:143)
~[?:?]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.lambda$wrap$0(SessionFactoryImpl.java:218)
~[?:?]
at 
org.apache.karaf.shell.impl.console.SessionFactoryImpl$ShellCommand.execute(SessionFactoryImpl.java:264)
~[?:?]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
~[?:?]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
~[?:?]
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
~[?:?]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[?:1.8.0_202]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[?:1.8.0_202]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
~[?:1.8.0_202]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202]
Caused by: java.lang.NoSuchMethodError:
org.jline.builtins.Less.(Lorg/jline/terminal/Terminal;)V
at org.apache.felix.gogo.jline.Posix.less(Posix.java:960) ~[?:?]
at org.apache.felix.gogo.jline.Posix.run(Posix.java:207) ~[?:?]
at org.apache.felix.gogo.jline.Posix._main(Posix.java:145) ~[?:?]
... 19 more

Is this already known?

Re: Http Whiteboard - Pax-Web multiple instances

[Markus Rathgeb]

Hi all,

the both examples and its mechanism differs (thanks for providing it).

The one JB refers to is using a bundle header. This example has (the
time I tested it) not worked for me. My research (at the time I
comment this the first time) has been that this works for the usage of
the "Web Application Specification" only. I did not check it again,
but I was not aware that something has been changed.

The one Achim refers to uses a HttpContextMapping service additional
to the Servlet service and sets the necessary properties.
Achim, thanks a lot for your example. This one is working for me!

> https://github.com/ops4j/org.ops4j.pax.web/blob/master/samples/whiteboard-extended/src/main/java/org/ops4j/pax/web/extender/samples/whiteboard/internal/Activator.java

As it is only an example, it does not matter, but there is a bug in
this example.
All the http context mapping service registrations are assigned to
"httpContextMappingReg" and all servlet registrations to "servletReg".
The respective ...2 and ...3 variables are not used.
So, there is only one of each service unregistered and freed.

Best regards,
Markus

Re: Http Whiteboard - Pax-Web multiple instances

[Markus Rathgeb]

Hm, I checkout the master branch of Pax Web and grepped the samples

grep -ri Web-VirtualHosts samples

No hits. Can you point me to the sample that is using Web-VirtualHosts?

Achim: FYI it seems the link in your signature
"http://wiki.ops4j.org/display/paxweb/Pax+Web/; does not exist
anymore.

Re: Karaf 4.2.7 and PaxLogging/Knopflerfish

[Markus Rathgeb]

Hi,

shouldn't this be solved with Karaf 4.2.8?
Becuase of 
https://issues.apache.org/jira/projects/KARAF/issues/KARAF-6462?filter=allissues
I removed


  
org.knopflerfish.kf6
log-API
  


from my pom files after updating from 4.2.7 to 4.2.8.

Today I need to build a release.
I tried to trigger a Maven release of my custom distribution, that
also brings custom features and bundles.

The release build fails because of:

[INFO] [ERROR] Failed to execute goal on project runtime: Could not
resolve dependencies for project
my-group-id:my-artifact-id-of-a-feature:feature:x.y.z: Failed to
collect dependencies at
org.ops4j.pax.jdbc:pax-jdbc-features:xml:features:1.4.4 ->
org.apache.karaf.features:framework:kar:4.2.7 ->
org.ops4j.pax.logging:pax-logging-log4j2:jar:1.11.2 ->
org.knopflerfish.kf6:log-API:jar:5.0.0: Failed to read artifact
descriptor for org.knopflerfish.kf6:log-API:jar:5.0.0: Could not
transfer artifact org.knopflerfish.kf6:log-API:pom:5.0.0 from/to ...

Karaf 4.2.8 is using the Pax JDBC 1.4.4 feature.
Pax JDBC seems to depend on the 4.2.7 framework kar but misses the exclusion...

So it seems we need this exclusion also while using Karaf 4.2.8
(otherwise Karaf would need to add this exclusion while depending on
dependencies that brings it into the dependency chain again).

Best regards,
Markus

Re: paste broken on client console

[Markus Rathgeb]

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

Re: Http Whiteboard - Pax-Web multiple instances

[Markus Rathgeb]

Hi JB,

as I comment that link already in the first thread and also answered
to your link in the second thread:

> Isn't this similar to this thread (at least after some comments):
> https://lists.apache.org/thread.html/69182ee8feef88896f840efde48146053997119e820ef037853c1c9b@%3Cuser.karaf.apache.org%3E
> You also referenced to http://blog.nanthrax.net/?p=352
> My observations has been that it should work for "Web Bundles" and I
> did not found (that time) a way to get it working for servlets.

May I ask you if you already checked that this is really still working
for servlets?

Re: paste broken on client console

[Markus Rathgeb]

Hi JB,

the release not of Karaf 4.2.8 contains:
[KARAF-6372] - Upgrade to jline 3.12.1

If I look at KARAF-6372
(https://issues.apache.org/jira/browse/KARAF-6372) it has been marked
that it has already been fixed in 4.2.7.
I assume this has been labeled not correctly.

Am Fr., 31. Jan. 2020 um 14:43 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> No it doesn't work by default outside screen.
>
> Let me find the TERM mapping (I'm pretty sure it's a change in jline).
>
> I keep you posted.
>
> Regards
> JB
>
> On 31/01/2020 14:30, Markus Rathgeb wrote:
> > Hi JB,
> >
> > does it work for you using "bin/client" without screen?
> >
> > I opened the "good old" xterm twice.
> > In one xterm I opened "bin/karaf".
> > In the other one I opened "bin/client".
> >
> > To test it in xterm I used the X linux feature to mark a text to copy
> > it and paste it by middle click or shift+insert.
> > * it works for "bin/karaf" without screen
> > * it works for "bin/karaf" with screen
> > * it does not work for "bin/client" without screen
> > * it does not work for "bin/client" with screen
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Http Whiteboard - Pax-Web multiple instances

[Markus Rathgeb]

Hi,

if I understand your question correctly I assume it fits to this two
discussions:

* 
https://lists.apache.org/thread.html/69182ee8feef88896f840efde48146053997119e820ef037853c1c9b%40%3Cuser.karaf.apache.org%3E
* 
https://lists.apache.org/thread.html/4c76641e9ad8c4f2096f96308f320b5ef00e55f2d6ed7a8fdb35f8c5%40%3Cuser.karaf.apache.org%3E

Correct?
If this is the case perhaps someone already added a full example and
eventually added an improvement on Pax Web (I don't know).

Re: paste broken on client console

[Markus Rathgeb]

Hi JB,

does it work for you using "bin/client" without screen?

I opened the "good old" xterm twice.
In one xterm I opened "bin/karaf".
In the other one I opened "bin/client".

To test it in xterm I used the X linux feature to mark a text to copy
it and paste it by middle click or shift+insert.
* it works for "bin/karaf" without screen
* it works for "bin/karaf" with screen
* it does not work for "bin/client" without screen
* it does not work for "bin/client" with screen

Re: paste broken on client console

[Markus Rathgeb]

It is working inside screen but without screen it is not working.
Will try to further investigate

Re: paste broken on client console

[Markus Rathgeb]

Hi JB,

some environments I assume they could be related:

COLORFGBG=0;15
COLORTERM=truecolor
JAVA_BIN=/home/rathgeb/bin/pkgs/java/jdk/8/OracleJDK/jdk1.8.0_202/bin
JAVA_HOME=/home/rathgeb/bin/pkgs/java/jdk/8/OracleJDK/jdk1.8.0_202
JAVA=/home/rathgeb/bin/pkgs/java/jdk/8/OracleJDK/jdk1.8.0_202/bin/java
LANG=en_US.utf8
LC_TIME=en_DK.utf8
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.cfg=00;32:*.conf=00;32:*.diff=00;32:*.doc=00;32:*.ini=00;32:*.log=00;32:*.patch=00;32:*.pdf=00;32:*.ps=00;32:*.tex=00;32:*.txt=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
SHELL=/bin/bash
SHLVL=0
TERM=xterm-256color

I am using "konsole" (the KDE console).
I will also try different ones...

paste broken on client console

[Markus Rathgeb]

Hi,

I updated targets running a custom distribution to Karaf 4.2.8.
Now while maintaining that systems I realized a very annoying problem.
The copy and paste (to be precise, the "paste") is not working using
"bin/client" correctly.

The problem can be reproduced using the upstream Karaf distribution, too.
I am using a Linux system (host machine + target machines).

To reproduce:
* unpack Karaf 4.2.8
* start the Karaf process by "bin/karaf"
* open another terminal and connect to the instance using "bin/client"
* copy a text and paste it into the terminal running "bin/client"

Result:
* the text will not appear
* on enter no new line will be visible
* to escape the situation paste again or press ctrl+C

Using the pasted text does not work for me correctly.

That's a little bit annoying, because I cannot connect to the running
instance and paste commands and arguments... I need to type all the
long arguments list manually.

Can I set a special environment variable to a special value (e.g. TERM
or LC_COLORS) that works around the problem?

Best regads,
Markus

Re: Vaadin Flow and Apache Karaf

[Markus Rathgeb]

I got the vaadin start project (TextField, Button, Notification)
working in an bnd application.

I used vaadin 14.1.5 and flow 2.1.4.

So, I "know" all bundles that are necessary for that use case
and
how a pom needs to look like to build a vaadin bundle that is working.

Now I can start clean up stuff and try to understand what is vaadin at all ;)

Am So., 26. Jan. 2020 um 14:56 Uhr schrieb stefang :
>
> Hi,
>
> it would be nice if a "war" from Vaadin Flow build could be run as WebApp
> under Karaf with "war" feature.
> Thats actually not possible and because of this we must setup a separate
> Jetty Instance to get it running.
>
> Regards
> Stefan
>
>
>
>
> jbonofre wrote
> > Hi Markus,
> >
> > Julian reported issue with Vaadin. I never tried (we are using mostly
> > Karaf services with Angular).
> >
> > Let me create a Jira to add a vaadin example:
> > https://issues.apache.org/jira/browse/KARAF-6608
> >
> > Regards
> > JB
> >
> > On 25/01/2020 22:20, Markus Rathgeb wrote:
> >> Hi,
> >>
> >> has there been already any progress for example working features for
> >> Vaadin 14 or a simple demo bundle that shows the feature working in
> >> Karaf?
> >>
> >> Best regards,
> >> Markus
>
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Vaadin Flow and Apache Karaf

[Markus Rathgeb]

Hi,

has there been already any progress for example working features for
Vaadin 14 or a simple demo bundle that shows the feature working in
Karaf?

Best regards,
Markus

KMP: error message improval

[Markus Rathgeb]

Hi,

I am using the karaf maven plugin to verify my feature files.
As I changed some of them and introduced new ones (some restructuring)
I run into the error that the verification cannot be run anymore.

I found the error after some time, and it has been caused by a mistake
I did on the feature restructuring. The error has been in my feature
definitions and not in the Maven plugin, but the message given by the
plugin has not been really helpful (and could be perhaps improved).

So, let's first give you the error in a feature definition:
* there is feature_b that declares feature_a as repository
* there is feature_a that declares feature_b as repository (that
dependency has been introduced by copy and paste and has been my
fault)
* both projects can be build and verified at least as long as no
feature of the one repo needs one of the other
* there is feature_c that declares feature_b as repository
* the feature_c depends on features from feature_b

The verification of feature_c fails with that message (I used the
Maven option "-e" to get a stracktrace):

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  9.289 s
[INFO] Finished at: 2020-01-24T14:46:50+01:00
[INFO] 
[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.2.8:verify (verify) on
project foo: Unable to load features descriptors: Error:
[ERROR] null
[ERROR] null
[ERROR] null
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.8:verify
(verify) on project foo: Unable to load features descriptors
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to
load features descriptors
at org.apache.karaf.tooling.VerifyMojo.doExecute (VerifyMojo.java:319)
at org.apache.karaf.tooling.VerifyMojo.execute (VerifyMojo.java:202)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain 

Re: CNFE on Jetty after Karaf bump

[Markus Rathgeb]

Thanks for your effort!

Am So., 19. Jan. 2020 um 06:56 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> Just to let you know that I successfully tested my fix on Pax Web.
>
> I'm cutting Pax Web 7.3.14 this morning, and I will submit Karaf 4.2.8
> to vote later today.
>
> Sorry for the inconvenience.
>
> Regards
> JB
>
> On 14/01/2020 15:55, Markus Rathgeb wrote:
> > Hi,
> >
> > I updated a product using a custom distribution from 4.2.6 to 4.2.7.
> > Because of this in the runtime the following versions has been changed:
> > * Pax Web: 7.2.10 to 7.2.11
> > * Jetty: from 9.4.18.v20190429 to 9.4.20.v20190813
> >
> > There is a bundle that contains a HTTP servlet for a fie upload.
> >
> > The POST request is handled by a method that takes the
> > HttpServletRequest "request" and the HttpServletResponse "response".
> > At the beginning it calls:
> > final Collection parts = request.getParts();
> >
> > After that it handles the parts.
> >
> > This worked before but does not anymore.
> >
> > An exception is raised.
> >
> > java.lang.NoClassDefFoundError:
> > org/eclipse/jetty/util/MultiPartInputStreamParser
> > at 
> > org.eclipse.jetty.server.MultiParts$MultiPartsUtilParser.(MultiParts.java:104)
> > ~[!/:9.4.20.v20190813]
> > at org.eclipse.jetty.server.Request.newMultiParts(Request.java:2295)
> > ~[!/:9.4.20.v20190813]
> > at org.eclipse.jetty.server.Request.getParts(Request.java:2217)
> > ~[!/:9.4.20.v20190813]
> > at org.eclipse.jetty.server.Request.getParts(Request.java:2203)
> > ~[!/:9.4.20.v20190813]
> > at UploadServlet.doPost(UploadServlet.java:152) ~[?:?]
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> > ~[!/:3.1.0]
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > ~[!/:3.1.0]
> > at 
> > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1591)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> > ~[!/:?]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293)
> > ~[!/:?]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.han

Re: CNFE on Jetty after Karaf bump

[Markus Rathgeb]

Hi JB,

have a look at: https://github.com/maggu2810/multipart-test

Am Do., 16. Jan. 2020 um 06:02 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> do you have a test case about that ?
>
> Basically, you are implementing a servlet with input data ?
>
> What I did in Pax Web is to configure the RFC compliance. It should be
> enough (depending of use case), so I would like to add a example/test
> case in Karaf (to include in itest).
>
> Thanks,
> Regards
> JB
>
> On 15/01/2020 14:42, Markus Rathgeb wrote:
> > I am using the following workaround:
> >
> > * fetch the upstread jetty-utils artifact
> > * edit the manifest and remove the exclude statement
> > * publish the modified artifact with another group ID to a maven repo
> > * use org.apache.karaf.features.xml to replace the upstream
> > jetty-utils with the modified one
> >
> > That way the old deprecated excluded but still used
> > MultiPartInputStreamParser is found again.
> >
> > I just wonder why it still occurs in the Pax Web release that
> > configures to use the other new multi part implementation.
> > Perhaps the fix is not fully complete?
> >
> > Am Di., 14. Jan. 2020 um 21:26 Uhr schrieb Markus Rathgeb 
> > :
> >>
> >> The bundle that handles the upload specific part does not depend on
> >> any Jetty specific bundle / package.
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: CNFE on Jetty after Karaf bump

[Markus Rathgeb]

I am using the following workaround:

* fetch the upstread jetty-utils artifact
* edit the manifest and remove the exclude statement
* publish the modified artifact with another group ID to a maven repo
* use org.apache.karaf.features.xml to replace the upstream
jetty-utils with the modified one

That way the old deprecated excluded but still used
MultiPartInputStreamParser is found again.

I just wonder why it still occurs in the Pax Web release that
configures to use the other new multi part implementation.
Perhaps the fix is not fully complete?

Am Di., 14. Jan. 2020 um 21:26 Uhr schrieb Markus Rathgeb :
>
> The bundle that handles the upload specific part does not depend on
> any Jetty specific bundle / package.

Re: CNFE on Jetty after Karaf bump

[Markus Rathgeb]

The bundle that handles the upload specific part does not depend on
any Jetty specific bundle / package.

Re: CNFE on Jetty after Karaf bump

[Markus Rathgeb]

]
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
[!/:9.4.22.v20191022]
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
[!/:9.4.22.v20191022]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jetty.util.MultiPartInputStreamParser
at 
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1401)
~[?:?]
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) ~[?:1.8.0_212]
... 47 more

Am Di., 14. Jan. 2020 um 18:07 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> it should be done on Jetty connector, so basically in Pax Web.
>
> Regards
> JB
>
> On 14/01/2020 16:12, Markus Rathgeb wrote:
> > Do you know about a method that can I call in my bundle code (e.g. in
> > its init method) to get it running on 4.2.7?
> > Any change to call "setMultiPartFormDataCompliance" in the servlet
> > implementation?
> > Or adding a configuration to config admin, ...?
> >
> > Am Di., 14. Jan. 2020 um 16:01 Uhr schrieb Jean-Baptiste Onofré
> > :
> >>
> >> It should be fixed on 4.2.8.
> >>
> >> See https://ops4j1.jira.com/browse/PAXWEB-1246 for details.
> >>
> >> Regards
> >> JB
> >>
> >> On 14/01/2020 15:55, Markus Rathgeb wrote:
> >>> Hi,
> >>>
> >>> I updated a product using a custom distribution from 4.2.6 to 4.2.7.
> >>> Because of this in the runtime the following versions has been changed:
> >>> * Pax Web: 7.2.10 to 7.2.11
> >>> * Jetty: from 9.4.18.v20190429 to 9.4.20.v20190813
> >>>
> >>> There is a bundle that contains a HTTP servlet for a fie upload.
> >>>
> >>> The POST request is handled by a method that takes the
> >>> HttpServletRequest "request" and the HttpServletResponse "response".
> >>> At the beginning it calls:
> >>> final Collection parts = request.getParts();
> >>>
> >>> After that it handles the parts.
> >>>
> >>> This worked before but does not anymore.
> >>>
> >>> An exception is raised.
> >>>
> >>> java.lang.NoClassDefFoundError:
> >>> org/eclipse/jetty/util/MultiPartInputStreamParser
> >>> at 
> >>> org.eclipse.jetty.server.MultiParts$MultiPartsUtilParser.(MultiParts.java:104)
> >>> ~[!/:9.4.20.v20190813]
> >>> at 
> >>> org.eclipse.jetty.server.Request.newMultiParts(Request.java:2295)
> >>> ~[!/:9.4.20.v20190813]
> >>> at org.eclipse.jetty.server.Request.getParts(Request.java:2217)
> >>> ~[!/:9.4.20.v20190813]
> >>> at org.eclipse.jetty.server.Request.getParts(Request.java:2203)
> >>> ~[!/:9.4.20.v20190813]
> >>> at UploadServlet.doPost(UploadServlet.java:152) ~[?:?]
> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> >>> ~[!/:3.1.0]
> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> >>> ~[!/:3.1.0]
> >>> at 
> >>> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852)
> >>> ~[!/:9.4.20.v20190813]
> >>> at 
> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> >>> ~[!/:9.4.20.v20190813]
> >>> at 
> >>> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> >>> ~[!/:9.4.20.v20190813]
> >>> at 
> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1591)
> >>> ~[!/:9.4.20.v20190813]
> >>> at 
> >>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> >>> ~[!/:9.4.20.v20190813]
> >>> at 
> >>> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceS

Re: CNFE on Jetty after Karaf bump

[Markus Rathgeb]

Do you know about a method that can I call in my bundle code (e.g. in
its init method) to get it running on 4.2.7?
Any change to call "setMultiPartFormDataCompliance" in the servlet
implementation?
Or adding a configuration to config admin, ...?

Am Di., 14. Jan. 2020 um 16:01 Uhr schrieb Jean-Baptiste Onofré
:
>
> It should be fixed on 4.2.8.
>
> See https://ops4j1.jira.com/browse/PAXWEB-1246 for details.
>
> Regards
> JB
>
> On 14/01/2020 15:55, Markus Rathgeb wrote:
> > Hi,
> >
> > I updated a product using a custom distribution from 4.2.6 to 4.2.7.
> > Because of this in the runtime the following versions has been changed:
> > * Pax Web: 7.2.10 to 7.2.11
> > * Jetty: from 9.4.18.v20190429 to 9.4.20.v20190813
> >
> > There is a bundle that contains a HTTP servlet for a fie upload.
> >
> > The POST request is handled by a method that takes the
> > HttpServletRequest "request" and the HttpServletResponse "response".
> > At the beginning it calls:
> > final Collection parts = request.getParts();
> >
> > After that it handles the parts.
> >
> > This worked before but does not anymore.
> >
> > An exception is raised.
> >
> > java.lang.NoClassDefFoundError:
> > org/eclipse/jetty/util/MultiPartInputStreamParser
> > at 
> > org.eclipse.jetty.server.MultiParts$MultiPartsUtilParser.(MultiParts.java:104)
> > ~[!/:9.4.20.v20190813]
> > at org.eclipse.jetty.server.Request.newMultiParts(Request.java:2295)
> > ~[!/:9.4.20.v20190813]
> > at org.eclipse.jetty.server.Request.getParts(Request.java:2217)
> > ~[!/:9.4.20.v20190813]
> > at org.eclipse.jetty.server.Request.getParts(Request.java:2203)
> > ~[!/:9.4.20.v20190813]
> > at UploadServlet.doPost(UploadServlet.java:152) ~[?:?]
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> > ~[!/:3.1.0]
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > ~[!/:3.1.0]
> > at 
> > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1591)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> > ~[!/:?]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293)
> > ~[!/:?]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> > ~[!/:9.4.20.v20190813]
> > at 
> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204)
> > ~[

CNFE on Jetty after Karaf bump

[Markus Rathgeb]

Hi,

I updated a product using a custom distribution from 4.2.6 to 4.2.7.
Because of this in the runtime the following versions has been changed:
* Pax Web: 7.2.10 to 7.2.11
* Jetty: from 9.4.18.v20190429 to 9.4.20.v20190813

There is a bundle that contains a HTTP servlet for a fie upload.

The POST request is handled by a method that takes the
HttpServletRequest "request" and the HttpServletResponse "response".
At the beginning it calls:
final Collection parts = request.getParts();

After that it handles the parts.

This worked before but does not anymore.

An exception is raised.

java.lang.NoClassDefFoundError:
org/eclipse/jetty/util/MultiPartInputStreamParser
at 
org.eclipse.jetty.server.MultiParts$MultiPartsUtilParser.(MultiParts.java:104)
~[!/:9.4.20.v20190813]
at org.eclipse.jetty.server.Request.newMultiParts(Request.java:2295)
~[!/:9.4.20.v20190813]
at org.eclipse.jetty.server.Request.getParts(Request.java:2217)
~[!/:9.4.20.v20190813]
at org.eclipse.jetty.server.Request.getParts(Request.java:2203)
~[!/:9.4.20.v20190813]
at UploadServlet.doPost(UploadServlet.java:152) ~[?:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
~[!/:3.1.0]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
~[!/:3.1.0]
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1591)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
~[!/:9.4.20.v20190813]
at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
~[!/:?]
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307)
~[!/:9.4.20.v20190813]
at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293)
~[!/:?]
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
~[!/:9.4.20.v20190813]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
~[!/:?]
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:722)
~[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
~[!/:9.4.20.v20190813]
at org.eclipse.jetty.server.Server.handle(Server.java:494)
~[!/:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374)
[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268)
[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
[!/:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
[!/:9.4.20.v20190813]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782)
[!/:9.4.20.v20190813]
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918)
[!/:9.4.20.v20190813]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]

I do not use the "MultiPartInputStreamParser" 

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

Hi

Just to be clear: org.osgi.service.log is provided by Pax Logging (not
> Karaf directly).
> The version is set by Pax Logging.
>

That's absolutely clear.
As written before, I updated the Pax Logging of an Karaf instance already
to 2.0.0-SNAPSHOT and bundles requiring org.osgi.service.log 1.4 seems to
work.
What is not working is e.g. the "log" commands of Karaf and I am pretty
sure they are provided by "org.apache.karaf.log.core" and not by Pax
Logging.
So, I had been able to get Pax Logging 2.0.0-SNAPSHOT in the container and
the wiring of 3rd party bundles but the Karaf integration is missing.
But we don't need to care about, it has just been a test.

So, my proposal is:
>
> 1. I do Pax Logging 2.0.0 release
>

great ;)


> 2. I upgrade Pax Logging on karaf master to cut 4.3.0.RC1 (R7 compliant)
>

great ;)

3. Once Karaf 4.2.8 is released (it will happen this week),


great ;)

I will
> update on 4.2.9-SNAPSHOT to evaluate support of Pax Logging 2.0.0 (and
> update command and so). If good, I will prepare 4.2.9 with that.
>

great ;)

Does it sound good to you ?
>

All fine, thank you.

Best regards,
Markus

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

Hi,

it's more Pax Logging related.
>

hm, I updated (on december) a Karaf instance to use the most recent (that
time) 2.0.0 SNAPSHOT and the only breakage I identified at that time is the
Karaf integration itself (org.apache.karaf.log.core) -- missing commands
etc.
So for me Pax Logging has been already ready (more or less) but the Karaf
side cannot use it.
But I did not do excessive testing.

In the long run I will definitely move to 4.3.0 but this is a bigger change
that cannot be done such easily (testing etc) than moving from 4.2.7 to
4.2.8.

Best regards,
Markus

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

Hi JB,

have you had any luck on adding support for the most recent Pax Logging
code base to org.apache.karaf.log.core?

Do you already know if you find enough time to add Log Service
Specification 1.4 support to Karaf 4.2.8?

Best regards,
Markus

Am So., 22. Dez. 2019 um 13:14 Uhr schrieb Markus Rathgeb <
maggu2...@gmail.com>:

> At least for me it would be really great of the log service 1.4 could
> be used in 4.2.8 ;)
>
> Am Fr., 20. Dez. 2019 um 15:52 Uhr schrieb Jean-Baptiste Onofré
> :
> >
> > Hi,
> >
> > I think we can backport this in Karaf 4.2.x. Originally, I planned to
> > focus this only on Karaf 4.3.x, but it makes sense to backport
> > "compendium/extra" package on 4.2.x, even if the framework is still R6.
> >
> > I'm not sure I will have time to do that for 4.2.8, but let me try.
> >
> > Regards
> > JB
> >
> > On 20/12/2019 14:59, Markus Rathgeb wrote:
> > > Hi JB,
> > > me again. ;)
> > >
> > > In Karaf 4.2.7 the scr feature already implements the Declarative
> > > Services Specification 1.4.
> > > Would it be possible that Pax Logging provides an implementation of
> > > the Log Service Specification 1.4 in Karaf 4.2.8?
> > > Or will the Log Service Specification 1.4 rely on some Core R7 feature?
> > >
> > > Best regards,
> > > Markus
> > >
> > > Am Fr., 20. Dez. 2019 um 14:29 Uhr schrieb Markus Rathgeb <
> maggu2...@gmail.com>:
> > >>
> > >> The "Equinox Common" can be used on Felix Framework using the "Equinox
> > >> Supplement" package that provides e.g. "org.eclipse.equinox.log".
> > >>
> > >> The Equinox Logger implements the Logger interface of the OSGi Log
> > >> Service specification 1.4
> > >>
> https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/src/org/eclipse/equinox/log/Logger.java#L23
> > >>
> > >> The "Equinox Supplement" does not usage version constraints at all on
> > >> its imports:
> > >>
> https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/META-INF/MANIFEST.MF#L25
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>

Re: Monitor the contents of a directory

[Markus Rathgeb]

You could have a look at "Apache Felix File Install". Using
felix.fileinstall.dir to setup the watched directories.

LuisLo  schrieb am Mo., 23. Dez. 2019, 11:06:

> Hi.
>
> We would like to add a folder with a behavior similar to deploy.
> Is there a service that allows you to monitor the contents of a folder and
> notify when it has changed?
>
> Our intention was to reuse the deploy operation but we did not find how it
> does it.
>
> Thanks.
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

At least for me it would be really great of the log service 1.4 could
be used in 4.2.8 ;)

Am Fr., 20. Dez. 2019 um 15:52 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi,
>
> I think we can backport this in Karaf 4.2.x. Originally, I planned to
> focus this only on Karaf 4.3.x, but it makes sense to backport
> "compendium/extra" package on 4.2.x, even if the framework is still R6.
>
> I'm not sure I will have time to do that for 4.2.8, but let me try.
>
> Regards
> JB
>
> On 20/12/2019 14:59, Markus Rathgeb wrote:
> > Hi JB,
> > me again. ;)
> >
> > In Karaf 4.2.7 the scr feature already implements the Declarative
> > Services Specification 1.4.
> > Would it be possible that Pax Logging provides an implementation of
> > the Log Service Specification 1.4 in Karaf 4.2.8?
> > Or will the Log Service Specification 1.4 rely on some Core R7 feature?
> >
> > Best regards,
> > Markus
> >
> > Am Fr., 20. Dez. 2019 um 14:29 Uhr schrieb Markus Rathgeb 
> > :
> >>
> >> The "Equinox Common" can be used on Felix Framework using the "Equinox
> >> Supplement" package that provides e.g. "org.eclipse.equinox.log".
> >>
> >> The Equinox Logger implements the Logger interface of the OSGi Log
> >> Service specification 1.4
> >> https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/src/org/eclipse/equinox/log/Logger.java#L23
> >>
> >> The "Equinox Supplement" does not usage version constraints at all on
> >> its imports:
> >> https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/META-INF/MANIFEST.MF#L25
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

Hi JB,
me again. ;)

In Karaf 4.2.7 the scr feature already implements the Declarative
Services Specification 1.4.
Would it be possible that Pax Logging provides an implementation of
the Log Service Specification 1.4 in Karaf 4.2.8?
Or will the Log Service Specification 1.4 rely on some Core R7 feature?

Best regards,
Markus

Am Fr., 20. Dez. 2019 um 14:29 Uhr schrieb Markus Rathgeb :
>
> The "Equinox Common" can be used on Felix Framework using the "Equinox
> Supplement" package that provides e.g. "org.eclipse.equinox.log".
>
> The Equinox Logger implements the Logger interface of the OSGi Log
> Service specification 1.4
> https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/src/org/eclipse/equinox/log/Logger.java#L23
>
> The "Equinox Supplement" does not usage version constraints at all on
> its imports:
> https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/META-INF/MANIFEST.MF#L25

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

The "Equinox Common" can be used on Felix Framework using the "Equinox
Supplement" package that provides e.g. "org.eclipse.equinox.log".

The Equinox Logger implements the Logger interface of the OSGi Log
Service specification 1.4
https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/src/org/eclipse/equinox/log/Logger.java#L23

The "Equinox Supplement" does not usage version constraints at all on
its imports:
https://github.com/eclipse/rt.equinox.framework/blob/63a9e1075ab029c5090a3d50cf52b82f052c62f6/bundles/org.eclipse.osgi/supplement/META-INF/MANIFEST.MF#L25

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

The interface Logger of org.osgi.service.log has been added on 1.4.

So if "Equinox Common" is using Logger then the imported version range
is wrong: org.osgi.service.log;version="[1.3.0, 2.0)"

Correct?

Am Fr., 20. Dez. 2019 um 14:05 Uhr schrieb Jean-Baptiste Onofré
:
>
> In the common headers, I see some packages specific to equinox:
>
> org.eclipse.equinox.log;version="[1.0,2.0)"
>
> for instance.
>
> I'm checking if requirement provides it (it might be provided only by
> the equinox framework).
>
> Regards
> JB
>
> On 20/12/2019 14:02, Jean-Baptiste Onofré wrote:
> > Ah, it fails with Felix only. Let me check the common headers, maybe a
> > require bundle or dep.
> >
> > On 20/12/2019 13:59, Jean-Baptiste Onofré wrote:
> >> I guess it works fine using Felix Framework right ? The problem happens
> >> when you install equinox common no ?
> >>
> >> Regards
> >> JB
> >>
> >> On 20/12/2019 13:54, Markus Rathgeb wrote:
> >>> So, if the Equinox framework is the problem, why is the exception
> >>> shown if the Apache Felix Framework is used only?
> >>>
> >>> Am Fr., 20. Dez. 2019 um 13:51 Uhr schrieb Jean-Baptiste Onofré
> >>> :
> >>>>
> >>>> Hi,
> >>>>
> >>>> The problem is more about the equinox which export the log package
> >>>> whereas it should not (as it's not part of core).
> >>>>
> >>>> Pax Logging looks good: it exports the packages and mention it uses the
> >>>> framework which is good IMHO.
> >>>>
> >>>> An easy fix would be a wrap/shade equinox to not export the log packages.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 20/12/2019 13:45, Markus Rathgeb wrote:
> >>>>> Hi,
> >>>>>
> >>>>> some third party bundle that is part of my runtime depends on
> >>>>> "org.eclipse.equinox.common".
> >>>>>
> >>>>> I am using Karaf 4.2.7
> >>>>>
> >>>>> If the Equinox framework is used I can install and start
> >>>>> "org.eclipse.equinox.common".
> >>>>>
> >>>>> # Install requirement
> >>>>> bundle:install 
> >>>>> mvn:org.eclipse.platform/org.eclipse.equinox.supplement/1.9.0
> >>>>> # Install and start Equinox Common
> >>>>> bundle:install -s 
> >>>>> mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400
> >>>>>
> >>>>> If the same commands are entered using Felix framework (so an
> >>>>> unmodified Karaf configuration) the Activator of Equinox Common fails.
> >>>>>
> >>>>> ===
> >>>>> 13:39:13.316 ERROR [Karaf local console user karaf] Exception caught
> >>>>> while executing command
> >>>>> org.apache.karaf.shell.support.MultiException: Error installing bundles:
> >>>>> Unable to start bundle
> >>>>> mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400:
> >>>>> org.osgi.framework.BundleException: Activator start error in bundle
> >>>>> org.eclipse.equinox.common [45].
> >>>>> at 
> >>>>> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
> >>>>> ~[?:?]
> >>>>> at 
> >>>>> org.apache.karaf.bundle.command.Install.execute(Install.java:131)
> >>>>> ~[?:?]
> >>>>> at 
> >>>>> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> >>>>> ~[?:?]
> >>>>> at 
> >>>>> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
> >>>>> ~[?:?]
> >>>>> at 
> >>>>> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
> >>>>> ~[?:?]
> >>>>> at 
> >>>>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
> >>>>> ~[?:?]
> >>>>> at 
> >>>>> org.apache.felix.gogo.runtime.Closure.executeSta

Re: org.osgi.service.log.Logger

[Markus Rathgeb]

So, if the Equinox framework is the problem, why is the exception
shown if the Apache Felix Framework is used only?

Am Fr., 20. Dez. 2019 um 13:51 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi,
>
> The problem is more about the equinox which export the log package
> whereas it should not (as it's not part of core).
>
> Pax Logging looks good: it exports the packages and mention it uses the
> framework which is good IMHO.
>
> An easy fix would be a wrap/shade equinox to not export the log packages.
>
> Regards
> JB
>
> On 20/12/2019 13:45, Markus Rathgeb wrote:
> > Hi,
> >
> > some third party bundle that is part of my runtime depends on
> > "org.eclipse.equinox.common".
> >
> > I am using Karaf 4.2.7
> >
> > If the Equinox framework is used I can install and start
> > "org.eclipse.equinox.common".
> >
> > # Install requirement
> > bundle:install mvn:org.eclipse.platform/org.eclipse.equinox.supplement/1.9.0
> > # Install and start Equinox Common
> > bundle:install -s 
> > mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400
> >
> > If the same commands are entered using Felix framework (so an
> > unmodified Karaf configuration) the Activator of Equinox Common fails.
> >
> > ===
> > 13:39:13.316 ERROR [Karaf local console user karaf] Exception caught
> > while executing command
> > org.apache.karaf.shell.support.MultiException: Error installing bundles:
> > Unable to start bundle
> > mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400:
> > org.osgi.framework.BundleException: Activator start error in bundle
> > org.eclipse.equinox.common [45].
> > at 
> > org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
> > ~[?:?]
> > at org.apache.karaf.bundle.command.Install.execute(Install.java:131)
> > ~[?:?]
> > at 
> > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> > ~[?:?]
> > at 
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
> > ~[?:?]
> > at 
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
> > ~[?:?]
> > at 
> > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
> > ~[?:?]
> > at 
> > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
> > ~[?:?]
> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
> > ~[?:?]
> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > ~[?:1.8.0_202]
> > at 
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> > ~[?:1.8.0_202]
> > at 
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> > ~[?:1.8.0_202]
> > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202]
> > Suppressed: java.lang.Exception: Unable to start bundle
> > mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400:
> > org.osgi.framework.BundleException: Activator start error in bundle
> > org.eclipse.equinox.common [45].
> > at
> > org.apache.karaf.bundle.command.Install.execute(Install.java:117)
> > ~[?:?]
> > at
> > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> > ~[?:?]
> > at
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
> > ~[?:?]
> > at
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
> > ~[?:?]
> > at
> > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
> > ~[?:?]
> > at
> > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
> > ~[?:?]
> > at
> > org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) ~[?:?]
> > at
> > org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) 
> > ~[?:?]
> > at org.apache.felix

org.osgi.service.log.Logger

[Markus Rathgeb]

Hi,

some third party bundle that is part of my runtime depends on
"org.eclipse.equinox.common".

I am using Karaf 4.2.7

If the Equinox framework is used I can install and start
"org.eclipse.equinox.common".

# Install requirement
bundle:install mvn:org.eclipse.platform/org.eclipse.equinox.supplement/1.9.0
# Install and start Equinox Common
bundle:install -s mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400

If the same commands are entered using Felix framework (so an
unmodified Karaf configuration) the Activator of Equinox Common fails.

===
13:39:13.316 ERROR [Karaf local console user karaf] Exception caught
while executing command
org.apache.karaf.shell.support.MultiException: Error installing bundles:
Unable to start bundle
mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400:
org.osgi.framework.BundleException: Activator start error in bundle
org.eclipse.equinox.common [45].
at 
org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
~[?:?]
at org.apache.karaf.bundle.command.Install.execute(Install.java:131)
~[?:?]
at 
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
~[?:?]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
~[?:?]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
~[?:?]
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
~[?:?]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[?:1.8.0_202]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[?:1.8.0_202]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
~[?:1.8.0_202]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202]
Suppressed: java.lang.Exception: Unable to start bundle
mvn:org.eclipse.platform/org.eclipse.equinox.common/3.10.400:
org.osgi.framework.BundleException: Activator start error in bundle
org.eclipse.equinox.common [45].
at
org.apache.karaf.bundle.command.Install.execute(Install.java:117)
~[?:?]
at
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
~[?:?]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
~[?:?]
at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
~[?:?]
at
org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
~[?:?]
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
~[?:?]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) ~[?:?]
at
org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[?:1.8.0_202]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[?:1.8.0_202]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
~[?:1.8.0_202]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202]
Caused by: org.osgi.framework.BundleException: Activator start
error in bundle org.eclipse.equinox.common [45].
at
org.apache.felix.framework.Felix.activateBundle(Felix.java:2290)
~[?:?]
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2146) ~[?:?]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
~[?:?]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
~[?:?]
at
org.apache.karaf.bundle.command.Install.execute(Install.java:115)
~[?:?]
... 13 more
Caused by: java.lang.NoClassDefFoundError: org/osgi/service/log/Logger
at java.lang.ClassLoader.defineClass1(Native Method)
~[?:1.8.0_202]
at
java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:1.8.0_202]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194)
~[?:?]
at

Re: Karaf feature processing

[Markus Rathgeb]

Sorry for the noise.

If I fix the typo (bundlebundleReplacements => bundleReplacements) it
works as expected.

Am Fr., 20. Dez. 2019 um 11:40 Uhr schrieb Markus Rathgeb :
>
> Hi,
>
> I have a question about the feature processing.
>
> I have afile "etc/org.apache.karaf.features.xml" that looks like:
>
> 
>  xmlns="http://karaf.apache.org/xmlns/features-processing/v1.0.0;
> xmlns:f="http://karaf.apache.org/xmlns/features/v1.5.0;>
>   
>  replacement="mvn:org.eclipse.jetty/jetty-client/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-continuation/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-deploy/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-http/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-io/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-jaas/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-jmx/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-jndi/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-plus/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-proxy/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-rewrite/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-security/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-jaspi/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-server/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-servlet/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-servlets/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-util/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-util-ajax/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-webapp/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty/jetty-xml/9.4.20.v20190813"
> mode="maven" />
>  originalUri="mvn:org.eclipse.jetty.websocket/javax-websocket-client-impl/[9,10)"
> replacement="mvn:org.eclipse.jetty.websocket/javax-websocket-client-impl/9.4.20.v20190813"
> mode="maven" />
>  originalUri="mvn:org.eclipse.jetty.websocket/javax-websocket-server-impl/[9,10)"
> replacement="mvn:org.eclipse.jetty.websocket/javax-websocket-server-impl/9.4.20.v20190813"
> mode="maven" />
>  replacement="mvn:org.eclipse.jetty.websocket/websocket-api/9.4.20.v20190813"
> mode="maven" />
>  originalUri="mvn:org.eclipse.jetty.websocket/websocket-client/[9,10)"
> replacement="mvn:org.eclipse.jetty.websocket/websocket-client/9.4.20.v20190813"
> mode="maven" />
>  originalUri="mvn:org.eclipse.jetty.websocket/websocket-common/[9,10)"
> replacement="mvn:org.eclipse.jetty.websocket/websocket-common/9.4.20.v20190813"
> mode="maven" />
>  originalUri="mvn:org.eclipse.jetty.websocket/websocket-server/[9,10)"
> replacement="mvn:org.eclipse.jetty.websocket/websocket-server/9.4.20.v20190813"
> mode="maven" />
>  originalUri="mvn:org.eclipse.jetty.websocket/websocket-servlet/[9,10)"
> replacement="mvn:org.eclipse.jetty.websocket/websocket-servlet/9.4.20.v20190813"
> mode="maven" />
>   
> 
>
> Shouldn't such a file prevent me from situations like this one:
>
> 191 │ Active│  80 │ 9.4.18.v20190429│
> mvn:org.eclipse.jetty/jetty-http/9.4.18.v20190429
> 192 │ Active│  30 │ 9.4.20.v20190813│
> mvn:org.eclipse.jetty/jetty-http/9.4.20.v20190813
>
> 210 │ Active│  80 │ 9.4.18.v20190429│
> mvn:org.eclipse.jetty.websocket/websocket-common/9.4.18.v20190429
> 211 │ Active│  30 │ 9.4.20.v20190813│
> mvn:org.eclipse.jetty.websocket/websocket-common/9.4.20.v20190813
>
> My question is about the "feature processing" feature itself and not
> about how this situation could be prevented otherwise. ;)
>
> Grzegorz Grzybek, perhaps you can give me more insights to that feature.
>
> Best regards,
> Markus

Karaf feature processing

[Markus Rathgeb]

Hi,

I have a question about the feature processing.

I have afile "etc/org.apache.karaf.features.xml" that looks like:


http://karaf.apache.org/xmlns/features-processing/v1.0.0;
xmlns:f="http://karaf.apache.org/xmlns/features/v1.5.0;>
  



























  


Shouldn't such a file prevent me from situations like this one:

191 │ Active│  80 │ 9.4.18.v20190429│
mvn:org.eclipse.jetty/jetty-http/9.4.18.v20190429
192 │ Active│  30 │ 9.4.20.v20190813│
mvn:org.eclipse.jetty/jetty-http/9.4.20.v20190813

210 │ Active│  80 │ 9.4.18.v20190429│
mvn:org.eclipse.jetty.websocket/websocket-common/9.4.18.v20190429
211 │ Active│  30 │ 9.4.20.v20190813│
mvn:org.eclipse.jetty.websocket/websocket-common/9.4.20.v20190813

My question is about the "feature processing" feature itself and not
about how this situation could be prevented otherwise. ;)

Grzegorz Grzybek, perhaps you can give me more insights to that feature.

Best regards,
Markus

Re: FeaturesService Code Examples

[Markus Rathgeb]

Hi,

openHAB uses the feature service programmatically, too.
So, for an example you could also look at:
https://github.com/openhab/openhab-core/blob/c50766d7c37a19f634e88fbe47b03b90215ab398/bundles/org.openhab.core.karaf/src/main/java/org/openhab/core/karaf/internal/FeatureInstaller.java#L115

I never checked that code if it is done correctly but for some inspiration...


Am Fr., 22. Nov. 2019 um 06:01 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Paul,
>
> You can use Cave Deployer that deal with features service, locally or
> remotely (using JMX).
>
> Regards
> JB
>
> On 22/11/2019 05:59, Paul Fraser wrote:
> > Hi,
> >
> > Now at the stage of wanting to install,  uninstall and do all of the
> > clever karaf things in code, but I cannot locate any usefull examples.
> >
> > My attempts so far have failed as there seems to be peculiar forms of
> > presenting feature repo and feature names in code and the required work
> > flow eludes me.
> >
> > I have checked out the itest test code in the karaf distribution but the
> > code is rather difficult to follow and I have not found suitable snippets.
> >
> > Any where I should be looking for inspiration?
> >
> > Paul Fraser
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf pax.web 2 Servlets 2 ports

[Markus Rathgeb]

Isn't this similar to this thread (at least after some comments):
https://lists.apache.org/thread.html/69182ee8feef88896f840efde48146053997119e820ef037853c1c9b@%3Cuser.karaf.apache.org%3E
You also referenced to http://blog.nanthrax.net/?p=352
My observations has been that it should work for "Web Bundles" and I
did not found (that time) a way to get it working for servlets.

Re: Johnzon JSON-B on OSGi

[Markus Rathgeb]

Hi,

as I did not found a set of bundle that satisfy the contract JavaCDI
v2.0.0 I repackaged the Johnzon JSON-B bundle to not depend on CDI at
all.

A question about the serviceloader specific manifest entries (WRT to
the example from
https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html):

The bundle that provides an implementation by SPI should contain that
manifest headers:

Require-Capability:
osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)"
Provide-Capability: osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI

Let's name it bundle_provider for the moment.

If my reading has been correct the ServiceLoader Registrar (e.g.
SPI-fly) register the specific implementation class OSGi Services so
that OSGi-aware consumers can simply use them from the OSGi Service
Registry.

If "@Reference foo.bar.MySPI" is used in a component (so a consumer)
the bnd tooling will generate that manifest header:

Require-Capability:
osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active

Wouldn't it make sense if bundle_provider also contains the header:

Provide-Capability: osgi.service;objectClass:List="foo.bar.MySPI"

As bundle_provider requires the ServiceLoader Registrar can't it state
that the OSGi is provided?

Or should the requirement
osgi.service;filter:="(objectClass=foo.bar.MySPI)";effective:=active
also be satisfied by the provided
osgi.serviceloader;osgi.serviceloader=foo.bar.MySPI (and its
requirement for the Registrar)
by resolving utils?

Best regards,
Markus

Am Mo., 16. Sept. 2019 um 11:14 Uhr schrieb Markus Rathgeb
:
>
> Hi again,
> be back with all the information (hopefully)
>
> For JSON-P provided by Johnzon:
> ===
>
> bundle:install 
> mvn:org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.2.3
> bundle:install mvn:org.apache.geronimo.specs/geronimo-json_1.1_spec/1.2
> bundle:install -s mvn:org.apache.johnzon/johnzon-core/1.1.12
>
> So far, all fine.
>
>
>
>
> Next try for JSON-B provided by Johnzon
> ===
>
> The manifest of johnzon-jsonb contains (excerpt):
>
> ...
> Require-Capability =
> osgi.extender;filter:=(osgi.extender=osgi.serviceloader.registrar),
> 
> osgi.contract;filter:=(&(osgi.contract=JavaCDI)(version=2.0.0));osgi.contract=JavaCDI,
> 
> osgi.contract;filter:=(&(osgi.contract=JavaJSONP)(version=1.1.0));osgi.contract=JavaJSONP,
> 
> osgi.contract;filter:=(&(osgi.contract=JavaAnnotation)(version=1.3.0));osgi.contract=JavaAnnotation,
> 
> osgi.contract;filter:=(&(osgi.contract=JavaJAXRS)(version=2.1.0));osgi.contract=JavaJAXRS,
> 
> osgi.contract;filter:=(&(osgi.contract=JavaJSONB)(version=1.0.0));osgi.contract=JavaJSONB,
> osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))
> ...
> Import-Package =
> javax.annotation,
> javax.enterprise.context.spi;resolution:=optional,
> javax.enterprise.event;resolution:=optional,
> javax.enterprise.inject.spi;resolution:=optional,
> javax.json,
> javax.json.bind,
> javax.json.bind.adapter,
> javax.json.bind.annotation,
> javax.json.bind.config,
> javax.json.bind.serializer,
> javax.json.bind.spi,
> javax.json.spi,
> javax.json.stream,
> javax.ws.rs,
> javax.ws.rs.core,
> javax.ws.rs.ext,
> org.apache.johnzon.core;version="[1.1,2)",
> org.apache.johnzon.jsonb,
> org.apache.johnzon.jsonb.cdi,
> org.apache.johnzon.jsonb.converter,
> org.apache.johnzon.jsonb.extension,
> org.apache.johnzon.jsonb.factory,
> org.apache.johnzon.jsonb.serializer,
> org.apache.johnzon.jsonb.spi,
> org.apache.johnzon.mapper;version="[1.1,2)",
> org.apache.johnzon.mapper.access;version="[1.1,2)",
> org.apache.johnzon.mapper.converter;version="[1.1,2)",
> org.apache.johnzon.mapper.internal;version="[1.1,2)",
> org.apache.johnzon.mapper.reflection;version="[1.1,2)"
>
>
> The first thing I wonder:
> If the package imports are already marked as optional, makes it sense
> to use a mandatory requirement for the OSGi contract?
>
>
> Let's continue:
>
> bundle:install 
> mvn:org.apache.aries.spec/org.apache.aries.javax.jax.rs-api/1.0.0
> bundle:install mvn:org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
> bundle:install mvn:org.apache.johnzon/johnzon-mapper/1.1.12
> bundle:install mvn:org.apache.johnzon/johnzon-jsonb/1.1.12
>
>
> Start Johnzon's JSON-B implementation
> ===
> bundle:start "Johnzon :: JSON-B Implementation"
> Error executing comma

Re: Johnzon JSON-B on OSGi

[Markus Rathgeb]

 1.0"
===
Done

Try to start JCDI again.
===
karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
Error executing command: Error executing command on bundles:
Error starting bundle 52: Unable to resolve
org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
52.0)] osgi.wiring.package; (osgi.wiring.package=javax.interceptor)
Unresolved requirements:
[[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
osgi.wiring.package; (osgi.wiring.package=javax.interceptor)]
===

Let's find a bundle that exports javax.interceptor
===
karaf@root()> bundle:install
mvn:org.apache.geronimo.specs/geronimo-interceptor_1.2_spec/1.1
karaf@root()> bundle:start "Apache Geronimo Interceptor Spec 1.2"
===

Try to start JCDI again.
===
karaf@root()> bundle:start "Apache Geronimo JCDI Spec 2.0"
Error executing command: Error executing command on bundles:
Error starting bundle 52: Unable to resolve
org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0): missing
requirement [org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R
52.0)] osgi.serviceloader;
(osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
Unresolved requirements:
[[org.apache.geronimo.specs.geronimo-jcdi_2.0_spec [52](R 52.0)]
osgi.serviceloader;
(osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)]
===


So, I need "something" that provides a ServiceLoader for
"javax.enterprise.inject.se.SeContainerInitializer" or another  bundle
that provides the JavaCDI v2.0.0 contract.



If CDI is optional for Johnzon JSON-B as the option imports of
"javax.enterprise.*" suggests, perhaps the contract should be removed
or marked optional (can a contract be marked optional at all?).

But regardless of Johnzon at all, how can "Apache Geronimo JCDI Spec
2.0" be satisfied at all?

Best regards,
Markus

Am Mo., 16. Sept. 2019 um 07:54 Uhr schrieb Jean-Baptiste Onofré
:
>
> That's exactly my point: johnzon-jsonb should not expose johnzon
> packages at all.
>
> Back on cap, for service loader, the SPI bundle should provide it:
>
> https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
>
> So, if johnzon-jsonb doesn't provide, it's a mistake in this bundle IMHO.
>
> Regards
> JB
>
> On 16/09/2019 07:43, Markus Rathgeb wrote:
> > Hi,
> >
> >> However, the JSON-B impl using Johnzon
> >> can embed Johnzon as private and just expose JSON-B service.
> >> That's actually better IMHO as you hide the implementation details from
> >> the API.
> >> That's the purpose of OSGi IMHO.
> >
> > From my understanding this is exactly what johnzon-jsonb should provide:
> > "Johnzon provides a module johnzon-jsonb implementing JSON-B standard
> > based on Johnzon Mapper."
> >
> > johnzon-josnb uses internally the johnzon-mapper implementation to
> > provide that functionality by the JSON-B API.
> >
> > I just want to use the JSON-B API in all my implementations and use
> > johnzon-jsonb as a bundle that provides a JSON-B implementation (the
> > fact that Johnzon [Mapper] is used I don't really care about).
> > johnzon-jsonb an OSGi manifest so I would like to get it running ;)
> >
> >> The question is why "client" bundles have a requirement not already
> >> provided or existing.
> >
> > Good question, I don't know.
> > My assumption has been, that the bundle exists that provides the
> > required capabilities, I just don't find them.
> > So my request: Does anyone know about the bundle(s) that provide the
> > capabilities.
> >
> > I will post the required capas soon (if I am back on my working machine).
> >
> > Best regards,
> > Markus
> >
> >>
> >> We already did some "wrapped" bundles (for instance Aries JAXRS API) in
> >> such case.
> >> More than a bundle, it's maybe better to evaluate to provide such
> >> capability at feature level.
> >>
> >> Regards
> >> JB
> >>
> >> On 16/09/2019 07:00, Markus Rathgeb wrote:
> >>> Hi JB,
> >>>
> >>> thanks for your reply.
> >>>
> >>> About your comment that you don't understand why people would like to
> >>> use OSGi bundles if possible instead of import stuff into private
> >>> packages:
> >>>
> >>> Isn't one thing we prefer in OSGi that we program / compile against an
> >>> API instead of a specific implementation?
> >>> I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
> >>

Re: Johnzon JSON-B on OSGi

[Markus Rathgeb]

Hi,

> However, the JSON-B impl using Johnzon
> can embed Johnzon as private and just expose JSON-B service.
> That's actually better IMHO as you hide the implementation details from
> the API.
> That's the purpose of OSGi IMHO.

>From my understanding this is exactly what johnzon-jsonb should provide:
"Johnzon provides a module johnzon-jsonb implementing JSON-B standard
based on Johnzon Mapper."

johnzon-josnb uses internally the johnzon-mapper implementation to
provide that functionality by the JSON-B API.

I just want to use the JSON-B API in all my implementations and use
johnzon-jsonb as a bundle that provides a JSON-B implementation (the
fact that Johnzon [Mapper] is used I don't really care about).
johnzon-jsonb an OSGi manifest so I would like to get it running ;)

> The question is why "client" bundles have a requirement not already
> provided or existing.

Good question, I don't know.
My assumption has been, that the bundle exists that provides the
required capabilities, I just don't find them.
So my request: Does anyone know about the bundle(s) that provide the
capabilities.

I will post the required capas soon (if I am back on my working machine).

Best regards,
Markus

>
> We already did some "wrapped" bundles (for instance Aries JAXRS API) in
> such case.
> More than a bundle, it's maybe better to evaluate to provide such
> capability at feature level.
>
> Regards
> JB
>
> On 16/09/2019 07:00, Markus Rathgeb wrote:
> > Hi JB,
> >
> > thanks for your reply.
> >
> > About your comment that you don't understand why people would like to
> > use OSGi bundles if possible instead of import stuff into private
> > packages:
> >
> > Isn't one thing we prefer in OSGi that we program / compile against an
> > API instead of a specific implementation?
> > I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
> > dependency because using that specific implementation) to JSON-P
> > (JSR-353) and JSON-B (JSR-367).
> > Doesn't it make sense (for you) to such an official standard?
> >
> > After more and more bundles (of mine) will be migrated to e.g. JSON-B
> > I would like to use JSON-B in my OSGi environments easily.
> > Just state that there must be such an implementation available at runtime.
> >
> > Is this wrong?
> > Isn't that exactly what has been chosen for the reference
> > implementation of the Configurator by Apache Felix?
> > They didn't embed an JSON-P implementation in the configurator bundle
> > but an implementation of our choose can be used at runtime.
> >
> > johnzon-jsonb already contains the OSGi related headers in its
> > manifest I just want to get it working.
> > I already created a fake bundle that just tell the runtime it would
> > provide the requested capability (without providing it).
> > This works at the moment as it seems no-one really needs the requested
> > capabilities.
> > (I have to use a bundle instead of a feature because it should work in
> > Karaf and inside any other OSGi runtime that does not know about Karaf
> > specific stuff e.g. features).
> >
> > Wouldn't it be better to get / "know" the correct bundle set to get it
> > working and perhaps create some PRs to get it working everywhere
> > instead of fixing it downstream on my side only?
> >
> > I will provide the specific messages later.
> > AFAIK servicemix already provides some API bundles (for other APIs)
> > that differ between the plain API bundles as the servicemix ones
> > contains a serviceloader and that manifest entries.
> >
> > Best regards,
> > Markus
> >
> > Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
> > :
> >>
> >> First, you can also embed Johnzon as private package in your bundle,
> >> that's probably the easiest way.
> >>
> >> All is not necessary bundle and import in OSGi ! I don't understand why
> >> the users systematically wants bundles/imports for everything ;)
> >>
> >> Anyway, can you share exactly the message ? The missing is not a bundle,
> >> it's a capability (service.loader). It's something you can add in a
> >> feature for instance.
> >>
> >> What I propose to you is to create a features for that.
> >>
> >> Regards
> >> JB
> >>
> >> On 15/09/2019 12:20, Markus Rathgeb wrote:
> >>> Hi,
> >>>
> >>> I posted my problem already to the Johnzon mailing list and have been
> >>> told to ask the Karaf team. So please let me ask you (this should be
> >>> no cross po

Re: Johnzon JSON-B on OSGi

[Markus Rathgeb]

Hi JB,

thanks for your reply.

About your comment that you don't understand why people would like to
use OSGi bundles if possible instead of import stuff into private
packages:

Isn't one thing we prefer in OSGi that we program / compile against an
API instead of a specific implementation?
I would like to move from Jackson, Gson, Johnzon Mapper usage (hard
dependency because using that specific implementation) to JSON-P
(JSR-353) and JSON-B (JSR-367).
Doesn't it make sense (for you) to such an official standard?

After more and more bundles (of mine) will be migrated to e.g. JSON-B
I would like to use JSON-B in my OSGi environments easily.
Just state that there must be such an implementation available at runtime.

Is this wrong?
Isn't that exactly what has been chosen for the reference
implementation of the Configurator by Apache Felix?
They didn't embed an JSON-P implementation in the configurator bundle
but an implementation of our choose can be used at runtime.

johnzon-jsonb already contains the OSGi related headers in its
manifest I just want to get it working.
I already created a fake bundle that just tell the runtime it would
provide the requested capability (without providing it).
This works at the moment as it seems no-one really needs the requested
capabilities.
(I have to use a bundle instead of a feature because it should work in
Karaf and inside any other OSGi runtime that does not know about Karaf
specific stuff e.g. features).

Wouldn't it be better to get / "know" the correct bundle set to get it
working and perhaps create some PRs to get it working everywhere
instead of fixing it downstream on my side only?

I will provide the specific messages later.
AFAIK servicemix already provides some API bundles (for other APIs)
that differ between the plain API bundles as the servicemix ones
contains a serviceloader and that manifest entries.

Best regards,
Markus

Am So., 15. Sept. 2019 um 19:19 Uhr schrieb Jean-Baptiste Onofré
:
>
> First, you can also embed Johnzon as private package in your bundle,
> that's probably the easiest way.
>
> All is not necessary bundle and import in OSGi ! I don't understand why
> the users systematically wants bundles/imports for everything ;)
>
> Anyway, can you share exactly the message ? The missing is not a bundle,
> it's a capability (service.loader). It's something you can add in a
> feature for instance.
>
> What I propose to you is to create a features for that.
>
> Regards
> JB
>
> On 15/09/2019 12:20, Markus Rathgeb wrote:
> > Hi,
> >
> > I posted my problem already to the Johnzon mailing list and have been
> > told to ask the Karaf team. So please let me ask you (this should be
> > no cross posting).
> > See: 
> > https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E
> >
> > I am not really sure if Karaf is using Johnzon. The current master
> > source tree only finds the usage of johnzon-core and johnzon-mapper on
> > an camel demo / example and it uses a rather old version (0.95).
> > But as you "know" a lot of OSGi bundles you perhaps know which one
> > satisfy the respective requirements.
> >
> > Let me repeat the description of my problem:
> >
> > I would like to use johnzon-jsonb 1.1.12 in an OSGi container.
> >
> > After adding johnzon-jsonb I got:
> > osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))
> >
> > That's easy, we need the respective API bundle.
> > I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1
> >
> > johnzon-jsonb requires: osgi.contract: 
> > (&(osgi.contract=JavaCDI)(version=2.0.0))
> > I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
> > This bundle provides the JavaCDI contract version 2.0.0
> >
> > The jcdi bundle requires: osgi.wiring.package: 
> > (&(osgi.wiring.package=javax.el))
> > I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1
> >
> > The jcdi also requires: osgi.wiring.package:
> > (&(osgi.wiring.package=javax.inject))
> > I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1
> >
> > The jcdi also requires: osgi.serviceloader:
> > (osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)
> >
> > I don't know which bundle provides that service loader.
> >
> > Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?
> >
> > With regards,
> > Markus
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Johnzon JSON-B on OSGi

[Markus Rathgeb]

Hi,

I posted my problem already to the Johnzon mailing list and have been
told to ask the Karaf team. So please let me ask you (this should be
no cross posting).
See: 
https://lists.apache.org/thread.html/b2134d2002738d33a57a329966ef38563372613502947158358092fa@%3Cdev.johnzon.apache.org%3E

I am not really sure if Karaf is using Johnzon. The current master
source tree only finds the usage of johnzon-core and johnzon-mapper on
an camel demo / example and it uses a rather old version (0.95).
But as you "know" a lot of OSGi bundles you perhaps know which one
satisfy the respective requirements.

Let me repeat the description of my problem:

I would like to use johnzon-jsonb 1.1.12 in an OSGi container.

After adding johnzon-jsonb I got:
osgi.wiring.package: (&(osgi.wiring.package=javax.json.bind))

That's easy, we need the respective API bundle.
I added org.apache.geronimo.specs/geronimo-jsonb_1.0_spec/1.1

johnzon-jsonb requires: osgi.contract: (&(osgi.contract=JavaCDI)(version=2.0.0))
I added org.apache.geronimo.specs/geronimo-jcdi_2.0_spec/1.1
This bundle provides the JavaCDI contract version 2.0.0

The jcdi bundle requires: osgi.wiring.package: (&(osgi.wiring.package=javax.el))
I added org.apache.geronimo.specs/geronimo-el_2.2_spec/1.1

The jcdi also requires: osgi.wiring.package:
(&(osgi.wiring.package=javax.inject))
I added org.apache.geronimo.specs/geronimo-atinject_1.0_spec/1.1

The jcdi also requires: osgi.serviceloader:
(osgi.serviceloader=javax.enterprise.inject.se.SeContainerInitializer)

I don't know which bundle provides that service loader.

Can you please point me to a set of bundles to use Johnzon JSON-B in OSGi?

With regards,
Markus

Re: Karaf and Transaction Control Service Specification

[Markus Rathgeb]

I got it working while creating the features myself.

Re: Karaf and Transaction Control Service Specification

[Markus Rathgeb]

Hi,

did you see my message?
Is the feature still in progress or is it just me that did not find it?

Am Mo., 22. Juli 2019 um 13:03 Uhr schrieb Markus Rathgeb :
>
> Hi JB,
>
> can you point me to the feature repositories I need to add to Karaf
> 4.2.6 to use OSGi R7 transaction control and JPA?
>
> Am Di., 5. Feb. 2019 um 16:53 Uhr schrieb Jean-Baptiste Onofré
> :
> >
> > I'm volunteer to add the features repository in aries-tx-control. That
> > would be helpful in Karaf.
> >
> > Regards
> > JB
> >
> > On 05/02/2019 16:51, Christian Schneider wrote:
> > > I am pretty sure you can use it.
> > >
> > > There is an example in enroute:
> > > https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
> > >
> > > If you use the same bundles it should work.
> > > We can create a karaf feature in the aries-tx-control repo for it to
> > > make it easier to install.
> > >
> > > Christian
> > >
> > > Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
> > > mailto:alex.s...@envieta.com>>:
> > >
> > > Hi,
> > >
> > > Is it possible to use Transaction Control Service Specification with
> > > Karaf?
> > >
> > > 
> > > https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
> > >
> > >
> > > Any good example or tutorial?
> > >
> > > (I am currently using Aries JPA Template, but I would like to move
> > > on to use the standard)
> > >
> > > Best regards,
> > > Alex soto
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Computer Scientist
> > > http://www.adobe.com
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com

Re: Karaf and Transaction Control Service Specification

[Markus Rathgeb]

Hi JB,

can you point me to the feature repositories I need to add to Karaf
4.2.6 to use OSGi R7 transaction control and JPA?

Am Di., 5. Feb. 2019 um 16:53 Uhr schrieb Jean-Baptiste Onofré
:
>
> I'm volunteer to add the features repository in aries-tx-control. That
> would be helpful in Karaf.
>
> Regards
> JB
>
> On 05/02/2019 16:51, Christian Schneider wrote:
> > I am pretty sure you can use it.
> >
> > There is an example in enroute:
> > https://github.com/osgi/osgi.enroute/tree/master/examples/microservice/rest-app-jpa
> >
> > If you use the same bundles it should work.
> > We can create a karaf feature in the aries-tx-control repo for it to
> > make it easier to install.
> >
> > Christian
> >
> > Am Di., 5. Feb. 2019 um 16:34 Uhr schrieb Alex Soto
> > mailto:alex.s...@envieta.com>>:
> >
> > Hi,
> >
> > Is it possible to use Transaction Control Service Specification with
> > Karaf?
> >
> > 
> > https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html
> >
> >
> > Any good example or tutorial?
> >
> > (I am currently using Aries JPA Template, but I would like to move
> > on to use the standard)
> >
> > Best regards,
> > Alex soto
> >
> >
> >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf Decanter log => mail

[Markus Rathgeb]

Here it is: https://issues.apache.org/jira/browse/KARAF-6355

I did not find how to change the "assign to" field.
Perhaps I don't have the power.

I don't know which title would be a good one - feel free to change it.

Am Mo., 8. Juli 2019 um 16:25 Uhr schrieb Jean-Baptiste Onofré
:
>
> Sure ! and thanks for your feedback !
>
> Do you mind to create a corresponding Jira and assign to me ? Else I
> will later today.
>
> Regards
> JB
>
> On 08/07/2019 16:20, Markus Rathgeb wrote:
> > Hi JB,
> >
> > sounds good.
> > Thank you.
> >
> > Can you keep me informed?
> >
> > Would it make sense (e.g. for log alert usage) to enhance the checker
> > configuration also for multiple matches (excludes)?
> >
> > E.g. type log,
> > * property level should match WARN
> > AND
> > * property message should not contain the regex foobar (or should
> > contain the regex)
> >
> > Or we could filter some loc.class and loc.method log messages that we
> > know are "false positives".
> >
> >
> >
> > Am Mo., 8. Juli 2019 um 15:19 Uhr schrieb Jean-Baptiste Onofré
> > :
> >>
> >> Hi Markus,
> >>
> >> Correct, but you raised a valid point. Let me do the improvements on the
> >> checker, adding an option to "always" send the alert, ignoring previous
> >> ones.
> >>
> >> I imagine something like:
> >>
> >> log.level.warn.always=
> >>
> >> I do the change for Decanter 2.3.0 and I will cut the release asap.
> >>
> >> OK for you ?
> >>
> >> Regards
> >> JB
> >>
> >> On 08/07/2019 15:04, Markus Rathgeb wrote:
> >>>> In the case of log, it's a bit special: you receive an alert as soon as
> >>>> you have a log.level in WARN, and it's stored in the Decanter alerts.
> >>>> Then, the next log message which is not a WARN will notify you.
> >>>>
> >>>> I need to improve a bit the mail alerter to only send the first email in
> >>>> the case of log (it makes sense for metrics, like the ones coming from
> >>>> the JMX collector).
> >>>
> >>> So, it is more like state entered and state exited. ?
> >>>
> >>> Let's assume the following log messages:
> >>>
> >>> * INFO 0
> >>> * WARN 1
> >>> * WARN 2
> >>> * WARN 3
> >>> * WARN 4
> >>> * INFO 5
> >>> * INFO 6
> >>> * WARN 7
> >>> * INFO 8
> >>>
> >>> Is it correct that I will only receive mails for "WARN 1", "INFO 5",
> >>> "WARN 7" and "INFO 8"?
> >>>
> >>> If I would like to get a mail per WARN log message, I need to write my
> >>> own log appender?
> >>>
> >>
> >> --
> >> 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: Karaf Decanter log => mail

[Markus Rathgeb]

Hi JB,

sounds good.
Thank you.

Can you keep me informed?

Would it make sense (e.g. for log alert usage) to enhance the checker
configuration also for multiple matches (excludes)?

E.g. type log,
* property level should match WARN
AND
* property message should not contain the regex foobar (or should
contain the regex)

Or we could filter some loc.class and loc.method log messages that we
know are "false positives".



Am Mo., 8. Juli 2019 um 15:19 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> Correct, but you raised a valid point. Let me do the improvements on the
> checker, adding an option to "always" send the alert, ignoring previous
> ones.
>
> I imagine something like:
>
> log.level.warn.always=
>
> I do the change for Decanter 2.3.0 and I will cut the release asap.
>
> OK for you ?
>
> Regards
> JB
>
> On 08/07/2019 15:04, Markus Rathgeb wrote:
> >> In the case of log, it's a bit special: you receive an alert as soon as
> >> you have a log.level in WARN, and it's stored in the Decanter alerts.
> >> Then, the next log message which is not a WARN will notify you.
> >>
> >> I need to improve a bit the mail alerter to only send the first email in
> >> the case of log (it makes sense for metrics, like the ones coming from
> >> the JMX collector).
> >
> > So, it is more like state entered and state exited. ?
> >
> > Let's assume the following log messages:
> >
> > * INFO 0
> > * WARN 1
> > * WARN 2
> > * WARN 3
> > * WARN 4
> > * INFO 5
> > * INFO 6
> > * WARN 7
> > * INFO 8
> >
> > Is it correct that I will only receive mails for "WARN 1", "INFO 5",
> > "WARN 7" and "INFO 8"?
> >
> > If I would like to get a mail per WARN log message, I need to write my
> > own log appender?
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf Decanter log => mail

[Markus Rathgeb]

> In the case of log, it's a bit special: you receive an alert as soon as
> you have a log.level in WARN, and it's stored in the Decanter alerts.
> Then, the next log message which is not a WARN will notify you.
>
> I need to improve a bit the mail alerter to only send the first email in
> the case of log (it makes sense for metrics, like the ones coming from
> the JMX collector).

So, it is more like state entered and state exited. ?

Let's assume the following log messages:

* INFO 0
* WARN 1
* WARN 2
* WARN 3
* WARN 4
* INFO 5
* INFO 6
* WARN 7
* INFO 8

Is it correct that I will only receive mails for "WARN 1", "INFO 5",
"WARN 7" and "INFO 8"?

If I would like to get a mail per WARN log message, I need to write my
own log appender?

Re: Karaf Decanter log => mail

[Markus Rathgeb]

The mails content does not seem to be fully correct.

There is e.g. a mail with subject: Alert on level back to normal
and body:
===
warn alert: level was out of the pattern match:WARN, but back to normal now

Details:
hostName: pc05
alertPattern: match:WARN
component.name: org.apache.karaf.decanter.collector.log
loc.class: ...
level: WARN
alertLevel: warn
type: log
message: no feature found for class: class ...
MDC: {bundle.version=..., bundle.name=..., bundle.id=22}
threadName: ...
loc.method: ...
loc.file: ...java
component.id: 43
alertBackToNormal: true
karafName: root
name: log
org.ops4j.pax.logging.appender.name: DecanterLogCollectorAppender
hostAddress: 127.0.0.1
loggerName: ...
loggerClass: org.ops4j.pax.logging.slf4j.Slf4jLogger
renderedMessage: no feature found for class: class ...
alertAttribute: level
timestamp: 1562588565010
loc.line: 125
event.topics: decanter/alert/warn
===

and another one with subject: [warn] Alert on level
and body
===
warn alert: level is out of the pattern match:WARN

Details:
hostName: pc05
alertPattern: match:WARN
component.name: org.apache.karaf.decanter.collector.log
loc.class: ...
level: INFO
alertLevel: warn
type: log
message: dropped already queued function for ...
MDC: {bundle.version=..., bundle.name=..., bundle.id=22}
threadName: ...
loc.method: ...
loc.file: java
component.id: 43
alertBackToNormal: false
karafName: root
name: log
org.ops4j.pax.logging.appender.name: DecanterLogCollectorAppender
hostAddress: 127.0.0.1
loggerName: ...
loggerClass: org.ops4j.pax.logging.slf4j.Slf4jLogger
renderedMessage: dropped already queued function for ...
alertAttribute: level
timestamp: 1562588567267
loc.line: 56
event.topics: decanter/alert/warn
===

I would expect the opposite.
If "level: WARN" I would expect the subject "[warn] Alert on level"
and if level is not WARN an subject of "Alert on level back to normal"

Or is my understanding wrong here?

Re: Karaf Decanter log => mail

[Markus Rathgeb]

After reading the code of
org.apache.karaf.decanter.alerting.checker.Checker I realized that the
checker configuration needs to be equal to:

===
log.level.error=match:ERROR
log.level.warn=match:WARN
===

Am Mo., 8. Juli 2019 um 14:10 Uhr schrieb Jean-Baptiste Onofré
:
>
> Let me try to reproduce on my machine. Give me couple of hours, I will
> get back to you.
>
> Regards
> JB
>
> On 08/07/2019 13:51, Markus Rathgeb wrote:
> > Hi,
> >
> > I would like to setup a Karaf based system to send mails for log
> > messages of priority WARN and ERROR.
> >
> > I read some of the "Apache Karaf Decanter 2.x" documentation.
> >
> > $ tar xzf apache-karaf-4.2.6.tar.gz
> > $ cd apache-karaf-4.2.6/
> > $ bin/karaf
> >
> > karaf@root()> feature:repo-add
> > mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.0.0/xml/features
> > karaf@root()> feature:install decanter-collector-log
> > karaf@root()> feature:install decanter-alerting-email
> >
> > There are now three configuration files:
> > * org.apache.karaf.decanter.alerting.checker.cfg
> > * org.apache.karaf.decanter.alerting.email.cfg
> > * org.apache.karaf.decanter.collector.log.cfg
> >
> > Edit "org.apache.karaf.decanter.alerting.checker.cfg" and add that lines:
> > ===
> > loggerLevel.error=match:ERROR
> > loggerLevel.warn=match:WARN
> > ===
> >
> > Add the mail setup to "org.apache.karaf.decanter.alerting.email.cfg".
> >
> > Keep the standard "org.apache.karaf.decanter.collector.log.cfg".
> >
> > Let's trigger an ERROR log by trigger a feature installation of an non
> > existing one:
> > karaf@root()> feature:install unknown-feature-name
> >
> > The error contains that message:
> > ===
> > 13:40:55.830 ERROR [Karaf local console user karaf] Exception caught
> > while executing command
> > java.lang.IllegalArgumentException: No matching features for
> > unknown-feature-name/0
> > at 
> > org.apache.karaf.features.internal.service.FeaturesServiceImpl.computeFeaturesToAdd(FeaturesServiceImpl.java:835)
> > ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:798)
> > ~[?:?]
> > at 
> > org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:78)
> > ~[?:?]
> > at 
> > org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:40)
> > ~[?:?]
> > at 
> > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> > ~[?:?]
> > at 
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
> > ~[?:?]
> > at 
> > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
> > ~[?:?]
> > at 
> > org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
> > ~[?:?]
> > at 
> > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
> > ~[?:?]
> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
> > ~[?:?]
> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
> > 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) [?:?]
> > ===
> >
> > I would expect to receive a mail message now.
> >
> > No mail has been received.
> >
> > If I try to use the TRACE level for the decanter package space to
> > "see" what's going on
> > karaf@root()> log:set TRACE org.apache.karaf.decanter
> >
> > I get the additional log message:
> > ===
> > 2019-07-08 13:48:55,021 Karaf local console user karaf ERROR Recursive
> > call to appender PaxOsgi
> > ===
> >
> > So, I assume I need to use a debugger to get further information what
> > is going on / wrong.
> >
> > Any other suggestions?
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Karaf Decanter log => mail

[Markus Rathgeb]

Hi,

I would like to setup a Karaf based system to send mails for log
messages of priority WARN and ERROR.

I read some of the "Apache Karaf Decanter 2.x" documentation.

$ tar xzf apache-karaf-4.2.6.tar.gz
$ cd apache-karaf-4.2.6/
$ bin/karaf

karaf@root()> feature:repo-add
mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.0.0/xml/features
karaf@root()> feature:install decanter-collector-log
karaf@root()> feature:install decanter-alerting-email

There are now three configuration files:
* org.apache.karaf.decanter.alerting.checker.cfg
* org.apache.karaf.decanter.alerting.email.cfg
* org.apache.karaf.decanter.collector.log.cfg

Edit "org.apache.karaf.decanter.alerting.checker.cfg" and add that lines:
===
loggerLevel.error=match:ERROR
loggerLevel.warn=match:WARN
===

Add the mail setup to "org.apache.karaf.decanter.alerting.email.cfg".

Keep the standard "org.apache.karaf.decanter.collector.log.cfg".

Let's trigger an ERROR log by trigger a feature installation of an non
existing one:
karaf@root()> feature:install unknown-feature-name

The error contains that message:
===
13:40:55.830 ERROR [Karaf local console user karaf] Exception caught
while executing command
java.lang.IllegalArgumentException: No matching features for
unknown-feature-name/0
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.computeFeaturesToAdd(FeaturesServiceImpl.java:835)
~[?:?]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:798)
~[?:?]
at 
org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:78)
~[?:?]
at 
org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:40)
~[?:?]
at 
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
~[?:?]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
~[?:?]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599)
~[?:?]
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526)
~[?:?]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415)
~[?:?]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
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) [?:?]
===

I would expect to receive a mail message now.

No mail has been received.

If I try to use the TRACE level for the decanter package space to
"see" what's going on
karaf@root()> log:set TRACE org.apache.karaf.decanter

I get the additional log message:
===
2019-07-08 13:48:55,021 Karaf local console user karaf ERROR Recursive
call to appender PaxOsgi
===

So, I assume I need to use a debugger to get further information what
is going on / wrong.

Any other suggestions?

Re: feature for jetty proxy

[Markus Rathgeb]

Thanks a lot (for both)!

Am Mo., 10. Juni 2019 um 18:36 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> I'm already added jetty-proxy in the Pax Web and Karaf features.
>
> I just mentioned a workaround waiting for new Pax Web/Karaf releases.
>
> Regards
> JB
>
> On 10/06/2019 17:55, Markus Rathgeb wrote:
> > Hi JB,
> >
> >> First, you can use the ProxyService directly to programmatically create
> >> the proxies you need.
> >
> > I read the proxy service of the Karaf project but this does not fit to
> > my use-case.
> > I use a subclass of Jetty's proxy servlet because the "proxyTo" is not 
> > fixed.
> > It depends on the caller of the URL which backend is used to generate
> > the response for the request.
> >
> > Think about a system where an user needs to be logged in first.
> > The login credentials are used to choose the real backend system.
> >
> > If user 1 calls httsp://some.thing/foo/bar the "reverse proxy"
> > redirects the request to https://10.10.10.101/foo/bar
> > If user 2 calls httsp://some.thing/foo/bar the "reverse proxy"
> > redirects the request to https://10.10.10.102/foo/bar
> > ...
> >
> > So my servlet is a subclass of the proxy servlet that generated the
> > URL for the rewrite target in a very dynamic way.
> >
> > And it is already working it is just some additional work to align the
> > Jetty version on every Karaf bump.
> >
> >> About the version, it's actually the opposite: the Jetty proxy is a pure
> >> servlet, and a version of Jetty proxy can work with other Jetty version.
> >
> > Sure, the proxy is just a servlet but the implementation is using a
> > e.g. Jetty HttpClient:
> >
> > * 
> > https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L43
> > * 
> > https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L129
> > * 
> > https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L273
> >
> > If the Jetty proxy servlet implementation is newer then the Jetty HTTP
> > Client the proxy servlet implementation could potentially use
> > functions that are not yet present in the provided HttpClient
> > implementation.
> > If strong semver is used a newer HTTP Client should still support all
> > stuff used by the proxy servlet but how knows...
> >
> >
> > The Jetty proxy artifact is already an OSGi bundle, so what's the "big
> > win" to add its classes to every bundle as private package instead of
> > adding the jetty-proxy bundle to the OSGi runtime?
> >
> > Thank you for your patient,
> > Markus
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: feature for jetty proxy

[Markus Rathgeb]

Hi JB,

> First, you can use the ProxyService directly to programmatically create
> the proxies you need.

I read the proxy service of the Karaf project but this does not fit to
my use-case.
I use a subclass of Jetty's proxy servlet because the "proxyTo" is not fixed.
It depends on the caller of the URL which backend is used to generate
the response for the request.

Think about a system where an user needs to be logged in first.
The login credentials are used to choose the real backend system.

If user 1 calls httsp://some.thing/foo/bar the "reverse proxy"
redirects the request to https://10.10.10.101/foo/bar
If user 2 calls httsp://some.thing/foo/bar the "reverse proxy"
redirects the request to https://10.10.10.102/foo/bar
...

So my servlet is a subclass of the proxy servlet that generated the
URL for the rewrite target in a very dynamic way.

And it is already working it is just some additional work to align the
Jetty version on every Karaf bump.

> About the version, it's actually the opposite: the Jetty proxy is a pure
> servlet, and a version of Jetty proxy can work with other Jetty version.

Sure, the proxy is just a servlet but the implementation is using a
e.g. Jetty HttpClient:

* 
https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L43
* 
https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L129
* 
https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/AbstractProxyServlet.java#L273

If the Jetty proxy servlet implementation is newer then the Jetty HTTP
Client the proxy servlet implementation could potentially use
functions that are not yet present in the provided HttpClient
implementation.
If strong semver is used a newer HTTP Client should still support all
stuff used by the proxy servlet but how knows...


The Jetty proxy artifact is already an OSGi bundle, so what's the "big
win" to add its classes to every bundle as private package instead of
adding the jetty-proxy bundle to the OSGi runtime?

Thank you for your patient,
Markus

Re: feature for jetty proxy

[Markus Rathgeb]

Added a link below

Am Mo., 10. Juni 2019 um 13:51 Uhr schrieb Markus Rathgeb :
>
> Hi JB,
>
> I will have a look at the Karaf ProxyService if it fits the need.
> What I need to do is to create proxies dynamic and programmatic on
> runtime on special user behaviour.
> Some of that proxies need to choose the redirect URI by some other
> information about the client.
> So the real proxy target varies.
> Think about a reverse proxy that redirects to different targets based
> on session information.
> It already works using the proxy base class provided by Jetty.
>
> Jetty Proxy depends on Jetty Client, Jetty Server, and all the
> external dependencies Jetty is using.

See e.g. 
https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/jetty-proxy/src/main/java/org/eclipse/jetty/proxy/ProxyServlet.java#L35-L44

> I could embed Jetty Proxy to every bundle that uses it but this will
> increase every bundle.
> And I still risk that Jetty Proxy version X does not work correctly
> with Jetty Proxy version Y.
> If Jetty Proxy itself does not depend on any other Jetty package and
> is just a standard servlet I will check again. At least the feature
> verification of a feature uses jetty proxy also depends on other jetty
> bundles.
>
> What's the problem with adding a jetty-proxy feature to the standard
> distribution that adds that one jetty bundle and depends
> (dependency=true) on e.g. the jetty feature.
> I see you don't use that bundle yourself but it will prevent anyone
> that would like to use Karaf and jetty-proxy to align the versions.
> And all the ones that don't need the feature just don't need to
> install it (as any other).
>
> Best regards,
> Markus
>
> Am Mo., 10. Juni 2019 um 13:32 Uhr schrieb Jean-Baptiste Onofré
> :
> >
> > Hi Markus,
> >
> > I'm suggesting to take a look on the Karaf http feature. It provides the
> > Karaf ProxyService (see http://blog.nanthrax.net/?p=830 for details).
> > The Karaf proxy works with any webcontainer (jetty, tomcat, undertow)
> > that can run in Karaf.
> >
> > If you want to use the Jetty transport proxy servlet yourself, you can
> > add this as private package.
> >
> > It's exactly what I do in Decanter backend:
> >
> > https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/src/main/java/org/apache/karaf/decanter/kibana6/Activator.java
> >
> > You can see the bundle I did, using jetty proxy servlet as private
> > package (it's just a servlet after all ;) ):
> >
> > https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L53
> > https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L88
> >
> > So, I don't think jetty-proxy should be part of the http/jetty feature.
> >
> > Regards
> > JB
> >
> > On 10/06/2019 10:04, Markus Rathgeb wrote:
> > > Hello,
> > >
> > > the Karaf distributions contains features for jetty.
> > > Mainly there are the jetty one in the standard feature repo and
> > > pax-jetty in the pax web feature repo.
> > >
> > > Both feature repos does not contain a feature that provides the
> > > jetty-proxy bundle.
> > >
> > > With every Karaf bump I need to modify a feature of mine for
> > > jetty-proxy to align the jetty version used by the Karaf distribution.
> > >
> > > Would it be possible to add that bundle to the respective features?
> > > Perhaps using dependency="true" so it is not installed if not needed?
> > >
> > > Best regards,
> > > Markus
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com

Re: feature for jetty proxy

[Markus Rathgeb]

Hi JB,

I will have a look at the Karaf ProxyService if it fits the need.
What I need to do is to create proxies dynamic and programmatic on
runtime on special user behaviour.
Some of that proxies need to choose the redirect URI by some other
information about the client.
So the real proxy target varies.
Think about a reverse proxy that redirects to different targets based
on session information.
It already works using the proxy base class provided by Jetty.

Jetty Proxy depends on Jetty Client, Jetty Server, and all the
external dependencies Jetty is using.
I could embed Jetty Proxy to every bundle that uses it but this will
increase every bundle.
And I still risk that Jetty Proxy version X does not work correctly
with Jetty Proxy version Y.
If Jetty Proxy itself does not depend on any other Jetty package and
is just a standard servlet I will check again. At least the feature
verification of a feature uses jetty proxy also depends on other jetty
bundles.

What's the problem with adding a jetty-proxy feature to the standard
distribution that adds that one jetty bundle and depends
(dependency=true) on e.g. the jetty feature.
I see you don't use that bundle yourself but it will prevent anyone
that would like to use Karaf and jetty-proxy to align the versions.
And all the ones that don't need the feature just don't need to
install it (as any other).

Best regards,
Markus

Am Mo., 10. Juni 2019 um 13:32 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> I'm suggesting to take a look on the Karaf http feature. It provides the
> Karaf ProxyService (see http://blog.nanthrax.net/?p=830 for details).
> The Karaf proxy works with any webcontainer (jetty, tomcat, undertow)
> that can run in Karaf.
>
> If you want to use the Jetty transport proxy servlet yourself, you can
> add this as private package.
>
> It's exactly what I do in Decanter backend:
>
> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/src/main/java/org/apache/karaf/decanter/kibana6/Activator.java
>
> You can see the bundle I did, using jetty proxy servlet as private
> package (it's just a servlet after all ;) ):
>
> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L53
> https://github.com/apache/karaf-decanter/blob/master/backend/kibana-6.x/pom.xml#L88
>
> So, I don't think jetty-proxy should be part of the http/jetty feature.
>
> Regards
> JB
>
> On 10/06/2019 10:04, Markus Rathgeb wrote:
> > Hello,
> >
> > the Karaf distributions contains features for jetty.
> > Mainly there are the jetty one in the standard feature repo and
> > pax-jetty in the pax web feature repo.
> >
> > Both feature repos does not contain a feature that provides the
> > jetty-proxy bundle.
> >
> > With every Karaf bump I need to modify a feature of mine for
> > jetty-proxy to align the jetty version used by the Karaf distribution.
> >
> > Would it be possible to add that bundle to the respective features?
> > Perhaps using dependency="true" so it is not installed if not needed?
> >
> > Best regards,
> > Markus
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

feature for jetty proxy

[Markus Rathgeb]

Hello,

the Karaf distributions contains features for jetty.
Mainly there are the jetty one in the standard feature repo and
pax-jetty in the pax web feature repo.

Both feature repos does not contain a feature that provides the
jetty-proxy bundle.

With every Karaf bump I need to modify a feature of mine for
jetty-proxy to align the jetty version used by the Karaf distribution.

Would it be possible to add that bundle to the respective features?
Perhaps using dependency="true" so it is not installed if not needed?

Best regards,
Markus

Re: Karaf bump, Spring Framework CNF exception

[Markus Rathgeb]

> > By the way, you don't need to install the spring-messaging bundle, you
> > can use the spring-messaging feature directly.
>
> Thanks! The feature has not been as the "my-spring" (not the real
> name) has been created initially.

JBO, can you please point me to the definition of the
"spring-messaging" feature you are reffering to.
I don't find them on Karaf 4.2.5:

karaf@root()> feature:list | grep spring
spring  │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x support
spring-aspects  │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x AOP
support
spring-instrument   │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x
Instrument support
spring-jdbc │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x JDBC
support
spring-jms  │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x JMS
support
spring-test │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x Test
support
spring-orm  │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x ORM
support
spring-oxm  │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x OXM
support
spring-tx   │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x
Transaction (TX) support
spring-web  │ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x Web
support
spring-websocket│ 5.0.12.RELEASE_1 │  │
Uninstalled │ spring-4.2.5  │ Spring 5.0.x
WebSocket support
spring  │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x support
spring-aspects  │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x AOP
support
spring-instrument   │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x
Instrument support
spring-jdbc │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x JDBC
support
spring-jms  │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x JMS
support
spring-test │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x Test
support
spring-orm  │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x ORM
support
spring-oxm  │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x OXM
support
spring-tx   │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x
Transaction (TX) support
spring-web  │ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x Web
support
spring-websocket│ 5.1.5.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring 5.1.x
WebSocket support
spring-security │ 5.1.3.RELEASE_1  │  │
Uninstalled │ spring-4.2.5  │ Spring Security
5.1.x support
aries-blueprint-spring  │ 0.0.0│  │
Uninstalled │ spring-4.2.5  │

Re: Karaf bump, Spring Framework CNF exception

[Markus Rathgeb]

> By the way, you don't need to install the spring-messaging bundle, you
> can use the spring-messaging feature directly.

Thanks! The feature has not been as the "my-spring" (not the real
name) has been created initially.

> OK good, but I would like to understand who's bringing the different
> Spring version.

I will try to find the time to create a minimal reproducible example.

Re: Karaf bump, Spring Framework CNF exception

[Markus Rathgeb]

It seems to work after I used a version range that allows exactly one
spring verion only.

  
spring
spring-web
spring-tx
spring-websocket
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-messaging/${spring.version}
  

Re: Karaf bump, Spring Framework CNF exception

[Markus Rathgeb]

I realized that there are two versions of the Spring Framework installed now.
This has not been the case on Karaf 4.2.1.
Is there some relationship to "Two versions of jetty"?
Have there been some changes to the feature resolver?

Am Mo., 20. Mai 2019 um 09:04 Uhr schrieb Markus Rathgeb :
>
> Hi,
>
> I had to update a custom distribution that contains a bundle that is
> using the Spring Framework.
> Currently the distribution is using Karaf 4.2.1, so Spring Framework
> 5.0.8.RELEASE_1.
> After the bump Karaf 4.2.5 will be used and so Spring Framework
> 5.0.12.RELEASE_1.
>
> While doing the migration I get an CNF exception on startup.
>
> ===
> RROR [paxweb-extender-1-thread-1] Exception finalizing HttpContext 
> registration
> javax.servlet.ServletException:
> mvc-dispatcher@f974527a==org.springframework.web.servlet.DispatcherServlet,jsp=null,order=1,inst=false
> at 
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:691)
> ~[?:?]
> at 
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:427)
> ~[?:?]
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:760)
> ~[?:?]
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:374)
> ~[?:?]
> at 
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.startContext(HttpServiceContext.java:414)
> ~[?:?]
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:847)
> ~[?:?]
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:287)
> ~[?:?]
> at 
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doStart(HttpServiceContext.java:267)
> ~[?:?]
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> ~[?:?]
> at 
> org.ops4j.pax.web.service.jetty.internal.JettyServerImpl$1.start(JettyServerImpl.java:329)
> ~[?:?]
> at 
> org.ops4j.pax.web.service.internal.HttpServiceStarted.end(HttpServiceStarted.java:1261)
> ~[?:?]
> at 
> org.ops4j.pax.web.service.internal.HttpServiceProxy.end(HttpServiceProxy.java:456)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorWC.end(RegisterWebAppVisitorWC.java:405)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.model.WebApp.accept(WebApp.java:658)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.register(WebAppPublisher.java:228)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:173)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:129)
> ~[?:?]
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> ~[?:?]
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> ~[?:?]
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> ~[?:?]
> at 
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> ~[?:?]
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
> ~[?:?]
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.WebAppPublisher.publish(WebAppPublisher.java:98)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.WebObserver.deploy(WebObserver.java:217)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.WebObserver$1.doStart(WebObserver.java:172)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.extender.SimpleExtension.start(SimpleExtension.java:59)
> ~[?:?]
> at 
> org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.lambda$createExtension$0(AbstractExtender.java:277)
> ~[?:?]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [?:?]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [?:?]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
> at 
> 

Karaf bump, Spring Framework CNF exception

[Markus Rathgeb]

Hi,

I had to update a custom distribution that contains a bundle that is
using the Spring Framework.
Currently the distribution is using Karaf 4.2.1, so Spring Framework
5.0.8.RELEASE_1.
After the bump Karaf 4.2.5 will be used and so Spring Framework
5.0.12.RELEASE_1.

While doing the migration I get an CNF exception on startup.

===
RROR [paxweb-extender-1-thread-1] Exception finalizing HttpContext registration
javax.servlet.ServletException:
mvc-dispatcher@f974527a==org.springframework.web.servlet.DispatcherServlet,jsp=null,order=1,inst=false
at 
org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:691)
~[?:?]
at 
org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:427)
~[?:?]
at 
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:760)
~[?:?]
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:374)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.startContext(HttpServiceContext.java:414)
~[?:?]
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:847)
~[?:?]
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:287)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doStart(HttpServiceContext.java:267)
~[?:?]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerImpl$1.start(JettyServerImpl.java:329)
~[?:?]
at 
org.ops4j.pax.web.service.internal.HttpServiceStarted.end(HttpServiceStarted.java:1261)
~[?:?]
at 
org.ops4j.pax.web.service.internal.HttpServiceProxy.end(HttpServiceProxy.java:456)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.RegisterWebAppVisitorWC.end(RegisterWebAppVisitorWC.java:405)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.model.WebApp.accept(WebApp.java:658)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.register(WebAppPublisher.java:228)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:173)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.WebAppPublisher$WebAppDependencyListener.addingService(WebAppPublisher.java:129)
~[?:?]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
~[?:?]
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
~[?:?]
at 
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
~[?:?]
at 
org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
~[?:?]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:318)
~[?:?]
at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:261)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.WebAppPublisher.publish(WebAppPublisher.java:98)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.WebObserver.deploy(WebObserver.java:217)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.WebObserver$1.doStart(WebObserver.java:172)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.extender.SimpleExtension.start(SimpleExtension.java:59)
~[?:?]
at 
org.ops4j.pax.web.extender.war.internal.extender.AbstractExtender.lambda$createExtension$0(AbstractExtender.java:277)
~[?:?]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException:
Unexpected exception parsing XML document from ServletContext resource
[/WEB-INF/mvc-dispatcher-servlet.xml]; nested exception is
org.springframework.beans.FatalBeanException: Unresolvable class
definition for NamespaceHandler class
[org.springframework.web.socket.config.WebSocketNamespaceHandler] for
namespace [http://www.springframework.org/schema/websocket]; nested
exception is java.lang.NoClassDefFoundError:
org/springframework/beans/factory/xml/NamespaceHandlerSupport
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414)
~[?:?]
at 

Re: Karaf, Pax Web, Jetty: "some" client authentication

[Markus Rathgeb]

I assume I need to use a "Web Application" and cannot rely on servlets etc.
https://osgi.org/specification/osgi.cmpn/7.0.0/service.war.html

Any change to get this mixed with Declarative Service?

Am Do., 16. Mai 2019 um 20:32 Uhr schrieb Markus Rathgeb :
>
> If this already known (WRT to the following comment)?
> https://nierbeck.de/2013/01/bind-certain-web-applications-to-specific-httpconnectors/#comment-62
>
> Am Do., 16. Mai 2019 um 20:26 Uhr schrieb Markus Rathgeb 
> :
> >
> > Hi Łukasz, hi JB,
> >
> > thank you for that information.
> >
> > I did not found an official documentation for that feature.
> >
> > I found this one (WRT the information given to me from you):
> > * https://ops4j1.jira.com/browse/PAXWEB-396
> > * 
> > https://nierbeck.de/2013/01/bind-certain-web-applications-to-specific-httpconnectors/
> > * http://blog.nanthrax.net/?p=352
> > * Source code of Pax Web
> >
> > I gave it a try using two additional connectors in jetty.xml.
> > I used the example that has been present in the current jetty.xml as
> > "SelectChannelConnector" did not work ("Caused by:
> > java.lang.ClassNotFoundException:
> > org.eclipse.jetty.server.nio.SelectChannelConnector not found by
> > org.eclipse.jetty.server [62]").
> > ===
> > 
> > 
> > 
> > 
> > 
> >  > type="org.eclipse.jetty.server.ConnectionFactory">
> > 
> >  > class="org.eclipse.jetty.server.HttpConnectionFactory">
> >  > refid="httpConfig" />
> > 
> > 
> > 
> > 
> >  > default="localhost" />
> >  > default="8201" />
> >  > default="3" />
> > conn1
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  > type="org.eclipse.jetty.server.ConnectionFactory">
> > 
> >  > class="org.eclipse.jetty.server.HttpConnectionFactory">
> >  > refid="httpConfig" />
> > 
> > 
> > 
> > 
> >  > default="localhost" />
> >  > default="8202" />
> >  > default="3" />
> > conn2
> > 
> > 
> > 
> > ===
> >
> > So, additional to 8181 there should be two connetors. conn1 on 8201
> > and conn2 on 8202.
> >
> > I created two bundles. Each bundle registers one servlet and use one
> > Web-Connector settings:
> >
> > Bundle 1 - Component:
> > ===
> > @Component(immediate = true)
> > @Header(name = "Web-Connectors", value = "conn1")
> > @Header(name = "Web-VirtualHosts", value = "localhost")
> > public class ComponentImpl {
> >
> > private static final String ALIAS = "/1";
> >
> > private final HttpService httpService;
> >
> > @Activate
> > public ComponentImpl(final @Reference HttpService httpService)
> > throws ServletException, NamespaceException {
> > this.httpService = httpService;
> > httpService.registerServlet(ALIAS, new HttpServlet() {
> >
> > @Override
> > protected void doGet(final HttpServletRequest req, final
> > HttpServletResponse resp)
> > throws ServletException, IOException {
> > final PrintWriter writer = resp.getWriter();
> > writer.println("This is the servlet: " + ALIAS);
> > }
> >
> > }, null, null);
> > }
> >
> > @Deactivate
> > public void close() {
> > httpService.unregister(ALIAS);
> > }
> >
> > }
> > ===
> >
> > The "Bundle 2 - Component" is identicial to the "1" but uses the alias
> > "/2" and the "Web-Connectors" "conn2".
> >
> > But this does

Re: Karaf, Pax Web, Jetty: "some" client authentication

[Markus Rathgeb]

If this already known (WRT to the following comment)?
https://nierbeck.de/2013/01/bind-certain-web-applications-to-specific-httpconnectors/#comment-62

Am Do., 16. Mai 2019 um 20:26 Uhr schrieb Markus Rathgeb :
>
> Hi Łukasz, hi JB,
>
> thank you for that information.
>
> I did not found an official documentation for that feature.
>
> I found this one (WRT the information given to me from you):
> * https://ops4j1.jira.com/browse/PAXWEB-396
> * 
> https://nierbeck.de/2013/01/bind-certain-web-applications-to-specific-httpconnectors/
> * http://blog.nanthrax.net/?p=352
> * Source code of Pax Web
>
> I gave it a try using two additional connectors in jetty.xml.
> I used the example that has been present in the current jetty.xml as
> "SelectChannelConnector" did not work ("Caused by:
> java.lang.ClassNotFoundException:
> org.eclipse.jetty.server.nio.SelectChannelConnector not found by
> org.eclipse.jetty.server [62]").
> ===
> 
> 
> 
> 
> 
> 
> 
>  class="org.eclipse.jetty.server.HttpConnectionFactory">
>  refid="httpConfig" />
> 
> 
> 
> 
>  default="localhost" />
>  default="8201" />
>  default="3" />
> conn1
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  class="org.eclipse.jetty.server.HttpConnectionFactory">
>  refid="httpConfig" />
> 
> 
> 
> 
>  default="localhost" />
>  default="8202" />
>  default="3" />
> conn2
> 
> 
> 
> ===
>
> So, additional to 8181 there should be two connetors. conn1 on 8201
> and conn2 on 8202.
>
> I created two bundles. Each bundle registers one servlet and use one
> Web-Connector settings:
>
> Bundle 1 - Component:
> ===
> @Component(immediate = true)
> @Header(name = "Web-Connectors", value = "conn1")
> @Header(name = "Web-VirtualHosts", value = "localhost")
> public class ComponentImpl {
>
> private static final String ALIAS = "/1";
>
> private final HttpService httpService;
>
> @Activate
> public ComponentImpl(final @Reference HttpService httpService)
> throws ServletException, NamespaceException {
> this.httpService = httpService;
> httpService.registerServlet(ALIAS, new HttpServlet() {
>
> @Override
> protected void doGet(final HttpServletRequest req, final
> HttpServletResponse resp)
> throws ServletException, IOException {
> final PrintWriter writer = resp.getWriter();
> writer.println("This is the servlet: " + ALIAS);
> }
>
> }, null, null);
> }
>
> @Deactivate
> public void close() {
> httpService.unregister(ALIAS);
> }
>
> }
> ===
>
> The "Bundle 2 - Component" is identicial to the "1" but uses the alias
> "/2" and the "Web-Connectors" "conn2".
>
> But this does not seem to work as expected.
> "/1" and "/2" can be open on port 8181, 8201 and 8202.
>
> So, all of them are available on all connectors.
>
> Can you point me to my misconfiguration?
> Or can you provide me two working demo bundles each of them using
> another connector?
>
> Best regards,
> Markus
>
> Am Do., 16. Mai 2019 um 16:18 Uhr schrieb Jean-Baptiste Onofré
> :
> >
> > Hi,
> >
> > I'm not sure it's what you are looking for, but you can configure
> > several connectors via jetty.xml (in addition of the default one created
> > by Pax Web), then, you can use "VirtualHost" to deploy a servlet on a
> > specific connector.
> >
> > I blogged about this while ago (http://blog.nanthrax.net/?p=352).
> >
> > Regards
> > JB
> >
> > On 16/05/2019 08:12, Markus Rathgeb wrote:
> > > Hi,
> > >
> > > I assume there are different parties invo

Re: Karaf, Pax Web, Jetty: "some" client authentication

[Markus Rathgeb]

Hi Łukasz, hi JB,

thank you for that information.

I did not found an official documentation for that feature.

I found this one (WRT the information given to me from you):
* https://ops4j1.jira.com/browse/PAXWEB-396
* 
https://nierbeck.de/2013/01/bind-certain-web-applications-to-specific-httpconnectors/
* http://blog.nanthrax.net/?p=352
* Source code of Pax Web

I gave it a try using two additional connectors in jetty.xml.
I used the example that has been present in the current jetty.xml as
"SelectChannelConnector" did not work ("Caused by:
java.lang.ClassNotFoundException:
org.eclipse.jetty.server.nio.SelectChannelConnector not found by
org.eclipse.jetty.server [62]").
===
















conn1



















conn2



===

So, additional to 8181 there should be two connetors. conn1 on 8201
and conn2 on 8202.

I created two bundles. Each bundle registers one servlet and use one
Web-Connector settings:

Bundle 1 - Component:
===
@Component(immediate = true)
@Header(name = "Web-Connectors", value = "conn1")
@Header(name = "Web-VirtualHosts", value = "localhost")
public class ComponentImpl {

private static final String ALIAS = "/1";

private final HttpService httpService;

@Activate
public ComponentImpl(final @Reference HttpService httpService)
throws ServletException, NamespaceException {
this.httpService = httpService;
httpService.registerServlet(ALIAS, new HttpServlet() {

@Override
protected void doGet(final HttpServletRequest req, final
HttpServletResponse resp)
throws ServletException, IOException {
final PrintWriter writer = resp.getWriter();
writer.println("This is the servlet: " + ALIAS);
}

}, null, null);
}

@Deactivate
public void close() {
httpService.unregister(ALIAS);
}

}
===

The "Bundle 2 - Component" is identicial to the "1" but uses the alias
"/2" and the "Web-Connectors" "conn2".

But this does not seem to work as expected.
"/1" and "/2" can be open on port 8181, 8201 and 8202.

So, all of them are available on all connectors.

Can you point me to my misconfiguration?
Or can you provide me two working demo bundles each of them using
another connector?

Best regards,
Markus

Am Do., 16. Mai 2019 um 16:18 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi,
>
> I'm not sure it's what you are looking for, but you can configure
> several connectors via jetty.xml (in addition of the default one created
> by Pax Web), then, you can use "VirtualHost" to deploy a servlet on a
> specific connector.
>
> I blogged about this while ago (http://blog.nanthrax.net/?p=352).
>
> Regards
> JB
>
> On 16/05/2019 08:12, Markus Rathgeb wrote:
> > Hi,
> >
> > I assume there are different parties involved, so if this question
> > should be raised on another mailing list, please can you point me to?
> >
> > I am using Karaf + Pax Web + Jetty.
> >
> > Currently I build a custom distribution that Pax Web configuration
> > (org.ops4j.pax.web.cfg) contains also this lines:
> >
> > ===
> > org.ops4j.pax.web.ssl.clientauthwanted = true
> > org.ops4j.pax.web.ssl.clientauthneeded = true
> >
> > org.ops4j.pax.web.ssl.truststore=${karaf.etc}/truststore.jks
> > org.ops4j.pax.web.ssl.truststore.password=that-is-not-the-real-one
> > ===
> >
> > This distribution contains a bundle that registers a servlet "MyServlet".
> >
> > Now, just FYI, I assume not all is relevant:
> >
> > ===
> > "MyServlet" extends the "WebSocketServlet"
> > (org.eclipse.jetty.websocket.servlet.WebSocketServlet).
> > Type hierarchy: MyServlet -> WebSocketServlet -> HttpServlet ->
> > GenericServlet [Servlet, ServletConfig, Serializable].
> >
> > The WebSocketServlet requires the implementation of the abstract
> > method "public abstract void configure(WebSocketServletFactory
> > factory);"
> >
> &g

Karaf, Pax Web, Jetty: "some" client authentication

[Markus Rathgeb]

Hi,

I assume there are different parties involved, so if this question
should be raised on another mailing list, please can you point me to?

I am using Karaf + Pax Web + Jetty.

Currently I build a custom distribution that Pax Web configuration
(org.ops4j.pax.web.cfg) contains also this lines:

===
org.ops4j.pax.web.ssl.clientauthwanted = true
org.ops4j.pax.web.ssl.clientauthneeded = true

org.ops4j.pax.web.ssl.truststore=${karaf.etc}/truststore.jks
org.ops4j.pax.web.ssl.truststore.password=that-is-not-the-real-one
===

This distribution contains a bundle that registers a servlet "MyServlet".

Now, just FYI, I assume not all is relevant:

===
"MyServlet" extends the "WebSocketServlet"
(org.eclipse.jetty.websocket.servlet.WebSocketServlet).
Type hierarchy: MyServlet -> WebSocketServlet -> HttpServlet ->
GenericServlet [Servlet, ServletConfig, Serializable].

The WebSocketServlet requires the implementation of the abstract
method "public abstract void configure(WebSocketServletFactory
factory);"

In the "configure" implementation is set a "creator".

factory.setCreator(new MyCreator(...));

MyCreator implements the following method (required by the
WebSocketCreator interface):

public @Nullable Object createWebSocket(final ServletUpgradeRequest
req, final ServletUpgradeResponse resp);

In that method I do a simple certificate check.

I call "final X509Certificate[] certs = req.getCertificates();" and
use the returned chain for the check.

Now back to the relevant part.
===

The current implementation of the client certificate chain check
relies that Jetty already required the client authentication
(clientauthneeded) and that the certificate is already checked against
the configured truststore (that contains only a special CA).

As we could rely on a "valid" certifcate I just need to extract the
information I need from the client certifcate and "all is fine".


Now, I need to add another servlet to that custom distribution that
should work without a client certifcate.

I assume I will need to remove the truststore and clientauth settings
from the configuration (keep wanted and drop needed?) and check the
certifcate in the code for "MyServlet" itself.
I further assume it should work by a filter or in the servlet itself.

Are there better ways to handle two servlet
* Servlet1 needs client authentication
* Servlet2 do not use client authentication

How can I trigger the check of the client certificate correctly in the
servlet / filter to check against a specific truststore?

I am interested in your inputs.

Best regards,
Markus

Re: Service Sisibility

[Markus Rathgeb]

Hi Tim,

can you point me to the part of the spec that states that service
configuration properties can be used to set such fields (e.g. target
filter)?
I just know that it works ;)

Best regards,
Markus

Tim Ward  schrieb am Mi., 15. Mai 2019, 15:45:

> Declarative Services is amazing, so this is trivially easy to do. In this
> case you should add the configuration property
>
> *service.target*
>
>
> to your configuration dictionary with the value being an LDAP filter
> selecting the service you want to inject.
>
> Note that “service” is the name of your reference (it defaults to the
> field name) and that if your reference has a different name (e.g. if you
> change the name of the field) then the name of the property will change too.
>
> For example:
>
> service.target=(foo=bar)
>
>
> Inject me with a MyInterfaceB which has the service property foo equal to
> bar.
>
> All the best,
>
> Tim
>
> On 15 May 2019, at 14:35, Matthias Leinweber <
> matthias.leinwe...@ida-analytics.de> wrote:
>
> Hello Karaf Experts,
>
> i am trying to isolate services from each other.
>
> For Example you have a component:
>
> @Component(
> configurationPid = "MyInterfacA.factory",
> configurationPolicy = ConfigurationPolicy.REQUIRE,
> public Class MyInterfaceAImpl implements MyInterfacA{
>
> @Reference
> MyInterfaceB service;
>
>  ...}
>
> During runtime I create multiple services from type MyInterfaceB and
> multiple componentes of MyInterfaceAImpl with configadmin.
> Depending on the configuration of MyInterfaceAImpl I want to filter which
> MyInterfaceB implementation is injected.
>
> I thought about FindHook but there I dont see a way how to get the
> information which service from the bundle is requesting the reference.
>
>
> Is there any chance to do this, or do I have to go for an alternative
> design. Or a better way to isolate services from another?
>
>
> Best regards,
> Matthias
>
>
>

Re: Karaf, Pax Web, Jetty, GzipHandler (compression)

[Markus Rathgeb]

Solved for me!
See:https://groups.google.com/d/topic/ops4j/U-uglsVkaMU/discussion

I edited the jetty.xml and it seems the gzip handler is used for every servlet.

Re: Karaf, Pax Web, Jetty, GzipHandler (compression)

[Markus Rathgeb]

I want to add the handler to a servlet that is registered programmatically.
Currently my servlet is a subclass of "javax.servlet.http.HttpServlet".
This class is registered by using "httpService.registerServlet(alias,
new MyServlet(args), null, null);" in the activation method of an OSGi
component.

Optionally I would also like to know how to configure it using
jetty.xml but this is not really important.


Am Do., 18. Apr. 2019 um 13:43 Uhr schrieb Jean-Baptiste Onofré
:
>
> Yeah, I remember to have use it with previous Jetty version.
>
> If I understand correct, you want to add the handler programmatically ?
> not via the jetty.xml right ?
>
> Regards
> JB
>
> On 18/04/2019 13:38, Markus Rathgeb wrote:
> > The GzipFilter is deprecated for Jetty >8 and does not contain any
> > logic anymore: 
> > https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/GzipFilter.java
> >
> > Am Do., 18. Apr. 2019 um 13:33 Uhr schrieb Jean-Baptiste Onofré
> > :
> >>
> >> Did you try to add the GzipFilter ?
> >>
> >> You can register the GzipFilter as a Filter service (using the http
> >> whiteboard pattern), providing mimeTypes and url-patterns as service
> >> properties.
> >>
> >> Regards
> >> JB
> >>
> >> On 18/04/2019 13:17, Markus Rathgeb wrote:
> >>> To be clear:
> >>> My whole setup is currently working WITHOUT the gzip compression 
> >>> (GzipHandler).
> >>> I just want to know what I need to do to add Jetty's GzipHandler to
> >>> programmatically registered servlets and to static content that is
> >>> currently already added by the jetty.xml.
> >>>
> >>> Am Do., 18. Apr. 2019 um 12:33 Uhr schrieb Jean-Baptiste Onofré
> >>> :
> >>>>
> >>>> Hi Markus,
> >>>>
> >>>> Are you using jetty.xml in config property from org.ops4j.pax.web.cfg ?
> >>>> Else your configuration won't be loaded in the Karaf Jetty connector.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 18/04/2019 11:36, Markus Rathgeb wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I would like to use gzip compression for
> >>>>> * my servlets registered using the "registerServlet" method of 
> >>>>> "HttpService"
> >>>>> * for a handler that provides static content of a directory added by 
> >>>>> jetty.xml
> >>>>>
> >>>>> The programmatic registered servlets are the most important ones.
> >>>>> Would be nice if there is one global option to configure the default
> >>>>> behavior and if it is still configurable per servlet.
> >>>>>
> >>>>> For the static content I am currently using that part of the jetty.xml
> >>>>> ===
> >>>>>   
> >>>>> 
> >>>>>   
> >>>>> 
> >>>>>   /foo/static
> >>>>>   
> >>>>>  >>>>> class="org.eclipse.jetty.server.handler.ResourceHandler">
> >>>>>>>>>> name="http.base.conf" />/html-foo
> >>>>>   false
> >>>>> 
> >>>>>   
> >>>>> 
> >>>>>   
> >>>>> 
> >>>>> 
> >>>>>   
> >>>>> 
> >>>>>   /bar/static
> >>>>>>>>>> name="http.base.conf" />/html-bar
> >>>>>   
> >>>>> org.eclipse.jetty.servlet.DefaultServlet
> >>>>> /
> >>>>> 
> >>>>>   dirAllowed
> >>>>>   false
> >>>>> 
> >>>>>   
> >>>>> 
> >>>>>   
> >>>>> 
> >>>>>   
> >>>>> ===
> >>>>>
> >>>>> Can you give me some tips / information / solution?
> >>>>>
> >>>>> Best regards,
> >>>>> Markus
> >>>>>
> >>>>
> >>>> --
> >>>> 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
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Karaf, Pax Web, Jetty, GzipHandler (compression)

[Markus Rathgeb]

The GzipFilter is deprecated for Jetty >8 and does not contain any
logic anymore: 
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/GzipFilter.java

Am Do., 18. Apr. 2019 um 13:33 Uhr schrieb Jean-Baptiste Onofré
:
>
> Did you try to add the GzipFilter ?
>
> You can register the GzipFilter as a Filter service (using the http
> whiteboard pattern), providing mimeTypes and url-patterns as service
> properties.
>
> Regards
> JB
>
> On 18/04/2019 13:17, Markus Rathgeb wrote:
> > To be clear:
> > My whole setup is currently working WITHOUT the gzip compression 
> > (GzipHandler).
> > I just want to know what I need to do to add Jetty's GzipHandler to
> > programmatically registered servlets and to static content that is
> > currently already added by the jetty.xml.
> >
> > Am Do., 18. Apr. 2019 um 12:33 Uhr schrieb Jean-Baptiste Onofré
> > :
> >>
> >> Hi Markus,
> >>
> >> Are you using jetty.xml in config property from org.ops4j.pax.web.cfg ?
> >> Else your configuration won't be loaded in the Karaf Jetty connector.
> >>
> >> Regards
> >> JB
> >>
> >> On 18/04/2019 11:36, Markus Rathgeb wrote:
> >>> Hi,
> >>>
> >>> I would like to use gzip compression for
> >>> * my servlets registered using the "registerServlet" method of 
> >>> "HttpService"
> >>> * for a handler that provides static content of a directory added by 
> >>> jetty.xml
> >>>
> >>> The programmatic registered servlets are the most important ones.
> >>> Would be nice if there is one global option to configure the default
> >>> behavior and if it is still configurable per servlet.
> >>>
> >>> For the static content I am currently using that part of the jetty.xml
> >>> ===
> >>>   
> >>> 
> >>>   
> >>> 
> >>>   /foo/static
> >>>   
> >>> 
> >>>>>> name="http.base.conf" />/html-foo
> >>>   false
> >>> 
> >>>   
> >>> 
> >>>   
> >>> 
> >>> 
> >>>   
> >>> 
> >>>   /bar/static
> >>>>>> name="http.base.conf" />/html-bar
> >>>   
> >>> org.eclipse.jetty.servlet.DefaultServlet
> >>> /
> >>> 
> >>>   dirAllowed
> >>>   false
> >>> 
> >>>   
> >>> 
> >>>   
> >>> 
> >>>   
> >>> ===
> >>>
> >>> Can you give me some tips / information / solution?
> >>>
> >>> Best regards,
> >>> Markus
> >>>
> >>
> >> --
> >> 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: Karaf, Pax Web, Jetty, GzipHandler (compression)

[Markus Rathgeb]

To be clear:
My whole setup is currently working WITHOUT the gzip compression (GzipHandler).
I just want to know what I need to do to add Jetty's GzipHandler to
programmatically registered servlets and to static content that is
currently already added by the jetty.xml.

Am Do., 18. Apr. 2019 um 12:33 Uhr schrieb Jean-Baptiste Onofré
:
>
> Hi Markus,
>
> Are you using jetty.xml in config property from org.ops4j.pax.web.cfg ?
> Else your configuration won't be loaded in the Karaf Jetty connector.
>
> Regards
> JB
>
> On 18/04/2019 11:36, Markus Rathgeb wrote:
> > Hi,
> >
> > I would like to use gzip compression for
> > * my servlets registered using the "registerServlet" method of "HttpService"
> > * for a handler that provides static content of a directory added by 
> > jetty.xml
> >
> > The programmatic registered servlets are the most important ones.
> > Would be nice if there is one global option to configure the default
> > behavior and if it is still configurable per servlet.
> >
> > For the static content I am currently using that part of the jetty.xml
> > ===
> >   
> > 
> >   
> > 
> >   /foo/static
> >   
> > 
> >> name="http.base.conf" />/html-foo
> >   false
> > 
> >   
> > 
> >   
> > 
> > 
> >   
> > 
> >   /bar/static
> >> name="http.base.conf" />/html-bar
> >   
> > org.eclipse.jetty.servlet.DefaultServlet
> > /
> > 
> >   dirAllowed
> >   false
> > 
> >   
> > 
> >   
> > 
> >   
> > ===
> >
> > Can you give me some tips / information / solution?
> >
> > Best regards,
> > Markus
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Karaf, Pax Web, Jetty, GzipHandler (compression)

[Markus Rathgeb]

Hi,

I would like to use gzip compression for
* my servlets registered using the "registerServlet" method of "HttpService"
* for a handler that provides static content of a directory added by jetty.xml

The programmatic registered servlets are the most important ones.
Would be nice if there is one global option to configure the default
behavior and if it is still configurable per servlet.

For the static content I am currently using that part of the jetty.xml
===
  

  

  /foo/static
  

  /html-foo
  false

  

  


  

  /bar/static
  /html-bar
  
org.eclipse.jetty.servlet.DefaultServlet
/

  dirAllowed
  false

  

  

  
===

Can you give me some tips / information / solution?

Best regards,
Markus

Re: Bndtools & Karaf : the right way

[Markus Rathgeb]

> It think bndtools at least builds the jar on each save. (This should also be 
> true if you use the maven setup for your project instead of the workspace 
> one). I am not sure if it also deploys to the local repo but maybe it does as 
> it is a cheap operation if the jar is already built. You should ask this on 
> the bndtools list for clarification.

I does not.
You could add a custom Eclipse m2e lifecycle mapping to your pom to
install the bundle on an incremental build, but it can be a problem if
your bundle is using Maven plugin that are not executed inside the
Eclipse IDE build and so the JAR will miss some content.

Re: Feature verify error with Karaf 4.2.2

[Markus Rathgeb]

Can you try to remove "effective:=active" from the capabilitiy?

resolving org.apache.qpid.proton-j

[Markus Rathgeb]

Hi,

I would like to use the bundle "org.apache.qpid.proton-j".
I started a clean standard Karaf 4.2.1 distribution and installed the
bundle:

bundle:install mvn:org.apache.qpid/proton-j/0.31.0

The bundle has unsatisfied requirements:

karaf@root()> bundle:diag 45
Proton-J (45)
-
Status: Installed
Unsatisfied Requirements:
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.amqp)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.amqp.messaging)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.amqp.security)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.amqp.transaction)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.amqp.transport)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.codec)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.codec.impl)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.codec.messaging)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.codec.security)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.codec.transaction)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.codec.transport)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.engine)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.engine.impl)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.engine.impl.ssl)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.framing)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.message)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.message.impl)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.reactor)
[org.apache.qpid.proton-j [45](R 45.0)] osgi.wiring.package;
(osgi.wiring.package=org.apache.qpid.proton.reactor.impl)

But AFAIK that packages are exported by the bundle itself.

I had a look at the bundle manifest and for me it seems that every all the
imported packages (except javax.net.ssl that resolution is optional) are
exported one.

Why does the wiring fail?

Best regards,
Markus

Re: Aries JAX-RS Whiteboard

[Markus Rathgeb]

Hi JB,

can you please point me to the correct repositories?
I cannot find your commits.

Best regards,
Markus

Re: Aries JAX-RS Whiteboard

[Markus Rathgeb]

Hi JB,

as I'm creating the Aries JAXRS feature for Karaf, I'm currently using
> the one from Aries.
>

could you share your feature?

Best regards,
Markus

Re: Aries JPA: The persistence unit has incomplete configuration and cannot be created.

[Markus Rathgeb]

Hi,


> I'm suggesting to create a Jira at Aries, we will tackle that.
>

Has a Jira at Aries been created?
Can you point me to?

Re: use JAXP compliant XML parser by OSGi service

[Markus Rathgeb]

Hi Tim, hi JB,

sorry for not being clear enough...

As written in my initial post / mail the call to
"SAXParserFactory.newInstance();" works for me as expected.

After reading
https://osgi.org/javadoc/r4v41/org/osgi/util/xml/XMLParserActivator.html I
just want to know

* if anyone knows about a bundle that provides a SAXParserFactory OSGi
service (as the specification exist for a long time my assumption has been
that there exist already bundles that expose the SAXParserFactory as an
OSGi service) and could point me to

* if it is safe to use "SAXParserFactory.newInstance();" static method call
or are there any reasons not to use it

* if "SAXParserFactory.newInstance();" works as expected in all the cases
why that specification at all


The last point "why that specification exist" leads me to the assumption
that it is perhaps better to rely on an OSGi service instead of that static
method.

If I had not read the document, I would not have questioned that static
method.

Regards,
Markus

Re: use JAXP compliant XML parser by OSGi service

[Markus Rathgeb]

Hi Tim,

isn't the information of your link about the R7 spec similar to that one I
posted in the first mail for R4.1?
It does not work for me (see output of first mail).

Or didn't I get your point?

Best regards,
Markus

Re: use JAXP compliant XML parser by OSGi service

[Markus Rathgeb]

I have found also this one:
http://apache-sling.73963.n3.nabble.com/jaxb-OSGI-amp-com-sun-xml-bind-Cannot-be-resolved-and-overwritten-by-Boot-Delegation-td4046690.html

As I am using a SAX parser I don't think I will run into some
"OSGi-compatible concerning class loading" problems..
But WDYT, does it make more sense to rely on a working
"SAXParserFactory.newInstance()"?

use JAXP compliant XML parser by OSGi service

[Markus Rathgeb]

Hello,

I (assume I) have some problems using a SAXParser "the OSGi way".

Code like this is currently (Karaf 4.2.0 and Java 8) working:

===
final SAXParserFactory factory = SAXParserFactory.newInstance();
final SAXParser saxParser;
try {
saxParser = factory.newSAXParser();
} catch (ParserConfigurationException | SAXException ex) {
throw new IllegalStateException(ex);
}
===


I have read this:
https://osgi.org/javadoc/r4v41/org/osgi/util/xml/XMLParserActivator.html

So I would assume there exist a SAX XML parser (factory) "somewhere" that
can be referenced as an OSGi service.


I  tried Xerces:

===
karaf@root()> bundle:install -s
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.xerces/2.12.0_1

karaf@root()> bundle:classes -a org.apache.servicemix.bundles.xerces | grep
SAXParserFactory

META-INF/services/javax.xml.parsers.SAXParserFactory | exported: false
org/apache/xerces/jaxp/SAXParserFactoryImpl.class | exported: true
org/apache/xerces/jaxp/javax.xml.parsers.SAXParserFactory | exported: true
META-INF/services/javax.xml.parsers.SAXParserFactory | exported: false
org/apache/xerces/jaxp/SAXParserFactoryImpl.class | exported: true
org/apache/xerces/jaxp/SAXParserFactoryImpl.java | exported: true
org/apache/xerces/jaxp/javax.xml.parsers.SAXParserFactory | exported: true

karaf@root()> service:list -a -n | grep -i sax
[nothing]
===


I also tried to install the OSGi XML util:

===
karaf@root()> bundle:install -s mvn:org.osgi/org.osgi.util.xml/1.0.1

karaf@root()> service:list -a -n | grep -i sax
[nothing]
===


Can you point me to a SAX parser factory that is provided as an OSGi
service?

Should I rely that on a working "SAXParserFactory.newInstance()" call?

How to use SAX parsing correctly?

Best regards,
Markus

Re: How do i change a single line in a custom distro file?

[Markus Rathgeb]

Have you already tried "assembly-property-edits.xml" in the
"src/main/karaf" folder of your custom distribution?
I don't find the official documentation, but you can found examples using a
search engine of your choose ;)

Re: Event admin blacklisting?

[Markus Rathgeb]

AFAIK there is also "org.apache.felix.eventadmin.Timeout=0" to disable the
timeout handling at all.

Another approach would be that your event handlers only take the event and
add it to a blocking queue (e.g. LinkedBlockingDeque).
You could use another thread that handles the elements added to that queue.
I assume in that case you return very fast.

At leat we don't see any blacklisting anymore (without the timeout=0 option
but with delegation the event handling to a separate thread).

Am Mi., 20. Juni 2018 um 18:36 Uhr schrieb Leschke, Scott <
slesc...@medline.com>:

> I’m still having some issues with this.  I have a 2 (maybe 3) event
> handlers in my app and I’ve recently started having blacklist issues.  I
> don’t know what’s causing it since the handlers themselves haven’t changed
> and should run very quickly, probably under a 10 millis or so in most cases.
>
>
>
> Anyway, per Ben Graf’s response below, I updated  file
> org.apache.felix.eventadmin.impl.EventAdmin.cfg with the following line:
>
>
>
> org.apache.felix.eventadmin.IgnoreTimeout=com.medline.*
>
>
>
> Given the description of the property, I expected this to cover all the
> event handlers in my app but I’m still seeing at least one of the handlers
> get blacklisted.  Is the syntax wrong or are there any other
> recommendations regarding this?
>
>
>
> Thanks in advance,
>
> Scott
>
>
>
> *From:* Benjamin Graf [mailto:benjamin.g...@gmx.net]
> *Sent:* Wednesday, June 13, 2018 11:16 AM
> *To:* user@karaf.apache.org
> *Subject:* Re: Event admin blacklisting?
>
> Hi Scott,
>
> timeout for blacklisting is 5000ms. (see
>
> http://felix.apache.org/documentation/subprojects/apache-felix-event-admin.html
> )
>
> Regards
>
> Benjamin
>
>
> Am 13.06.2018 um 17:41 schrieb Leschke, Scott:
> >  I'm having an issue where events sto
>
>
>

Re: wrap:mvn in offline mode

[Markus Rathgeb]

Hi,

if I understand your use case correctly, you want to add "wrap" to
"installedFeature".
https://karaf.apache.org/manual/latest/#_plugin_configuration

2017-10-24 11:03 GMT+02:00 DERIES Sebastien :
> Hey Everyone,
>
>
>
> I currently work on a custom karaf distribution (based on 4.1.2) built using
> the karaf-maven-plugin. This distribution was working perfectly offline (any
> nexus server) until I added a non OSGi jar file inside one of our custom
> karaf feature using the wrap:mvn protocol.
>
>
>
> 
> wrap:mvn:somegroup/some-artifact/0.0.1/bundle>
>
> 
>
>
>
> The first time I ran the new distribution with a wrapped jar file, the
> distribution was trying to connect to remote nexus repositories. To avoid
> this, I tuned etc/org.ops4j.pax.url.mvn.cfg etc/karaf_maven_settings.xml to
> work offline (only in the distribution local repository.) like this:
>
>
>
> etc/org.ops4j.pax.url.mvn.cfg :
>
> org.ops4j.pax.url.mvn.certificateCheck=true
>
> org.ops4j.pax.url.mvn.settings=${karaf.home}/etc/karaf_maven_settings.xml
>
> org.ops4j.pax.url.mvn.localRepository=${karaf.home}/${karaf.default.repository}
>
> org.ops4j.pax.url.mvn.useFallbackRepositories=false
>
> org.ops4j.pax.url.mvn.defaultRepositories=\
>
>
> file:${karaf.home}/${karaf.default.repository}@id=system.repository@snapshots,
> \
>
> file:${karaf.data}/kar@id=kar.repository@multi@snapshots, \
>
>
> file:${karaf.base}/${karaf.default.repository}@id=child.system.repository@snapshots
>
> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote = true
>
> org.ops4j.pax.url.mvn.repositories=
>
>
>
> karaf_maven_settings.xml
>
> 
>
> http://maven.apache.org/SETTINGS/1.0.0;
>
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>
>   xsi:schemaLocation="http:/maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
> 
>
>
>
> However, I now need to install all the dependencies of the wrap
> functionality inside the local repository.
>
> Should I add  any pax-url-wrap bundle dependency into my feature
> “some-feature” or is there a karaf feature I could add to my assembly that
> would embed all those dependencies for me ?
>
>
>
> Thank you very much for your help.
>
>
>
> Regards
>
>
>
> Seb
>
>
>
> PS: Thank you for the great you do with Karaf !
>
>
>
>

Re: Karaf Container 4.0.x / minimum configuration

[Markus Rathgeb]

Hi,
do you use the OpenJDK or Oracle Java?
On ARM the Oracle JVM works much better (performace) then the OpenJDK
-- at the time I tested it.

Best regards,
Markus

2017-06-22 13:57 GMT+02:00 jljordan :
> Hi JB,
>
> Thanks for your answer.
> We use Debian 8 (Jessie) with a kernel part based on NXP Linux BSP iMx
> version 4.1.15_1.2.0
> and user part is the base system Debian.
> We have 1GB RAM and 4 GB Flash and our software is executed on 16GB Micro-SD
> card.
> Following our installation procedure, first we install Karaf and launch it
> without features.
> It is in the next step that the features are installed.
> But in the first step, after the Karaf installation,
> if we execute a command through the Karaf console,
> it takes 1 minute almost.
> We checked by a top command that karaf process has a 100% cpu occupancy.
> We checked that we have not the issue if we install Karaf on a Virtual Box.
>
> Regards,
> Jean-Luc Jordan
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Karaf-Container-4-0-x-minimum-configuration-tp4050843p4050856.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Is anybody using Jetty client from Karaf?

[Markus Rathgeb]

Will have a look at tomorrow, but I am pretty sure I am using the jetty
client bundle in K408.

Am 23.03.2017 21:20 schrieb "Leschke, Scott" :

> *Sent this about 1.5 weeks ago. Thought I’d resend one more time just in
> case there’s somebody out there using this.*
>
>
>
> *From:* Leschke, Scott [mailto:slesc...@medline.com]
> *Sent:* Monday, March 13, 2017 11:52 AM
> *To:* user@karaf.apache.org
> *Subject:* Jetty client
>
>
>
> I’m curious if anybody is using the Jetty HTTP client from Karaf (v 4.0.8)
> successfully. I would like to move from using Apache to Jetty but I get a
> runtime NPE from Jetty.  I tried it with both the 9.3.16 and 9.4.2 versions
> of the client with the exact same results.
>
>
>
> The following Jetty bundles were required.
>
>
>
> Jetty-client-9.3.16v…….
>
> Jetty-http-9.3.16v…….
>
> Jetty-io-9.3.16v…….
>
> Jetty-util-9.3.16v…….
>
>
>
> Scott Leschke
>

Re: Karaf running on ARM - RaspberryPi

[Markus Rathgeb]

Hello,
the first problem you reported is known and has been already solved for
K408.
So, if you ewant to use Karaf on ARM, don't use K406 or K407 -- use K408
(or K410).


Am 18.03.2017 15:57 schrieb "JT" :

Hi all,

I've got a couple of issues running Karaf on a RaspberryPi 2 (ARM 32 bit).

Starting Karaf is fine but:

1. trying to log-in locally with './client' results in the error:

Could not load library. Reasons: [no jansi in java.library.path,
/home/pi/apache-karaf-4.0.7/data/tmp/libjansi-32-5060191913484045686.so:
/home/pi/apache-karaf-4.0.7/data/tmp/libjansi-32-5060191913484045686.so:
cannot open shared object file: No such file or directory (Possible cause:
can't load IA 32-bit .so on a ARM-bit platform)]

libjansi is available in the Raspbian repos and tried installing but still
got the same error. Looks like Karaf looks for this in it;s local
installation? Is there a way around this?

2. I can ssh into a running Karaf and then I have tried to deploy the
latest build of OpenCV 3.2.0 Java bundle which includes the native OpenCv
library, but I get this error:

Error starting bundle 52: Unable to resolve org.opencv [52](R 52.0):
missing requirement [org.opencv [52](R 52.0)] osgi.native;
(&(osgi.native.osname~=linux)(osgi.native.processor~=arm_le)) Unresolved
requirements: [[org.opencv [52](R 52.0)] osgi.native;
(&(osgi.native.osname~=linux)(osgi.native.processor~=arm_le))]

Is there anyway I can resolve this missing dependency?

Thanks

Kerry

Re: K410: Exception caused by Jetty bug

[Markus Rathgeb]

> will take care of that

Thank you Achim

Re: K410: Exception caused by Jetty bug

[Markus Rathgeb]

Hi Achim,

I have created the issues:
* https://ops4j1.jira.com/browse/PAXWEB-1065
* https://issues.apache.org/jira/browse/KARAF-4990

Best regards,
Markus

K410: Exception caused by Jetty bug

[Markus Rathgeb]

Hi,

after I changed some stuff to use the recent Karaf 4.1.0 I realized an
error in my log (see below if you are interested in the whole
message).
The error has been cased by a bug in the
"org.eclipse.jetty.websocket.server" bundle (SPI without no-arg
constructor).
The issue has already been reported
(https://github.com/eclipse/jetty.project/issues/1276).
It has been resolved in the master branch and in the new 9.3 release
"9.3.16.v20170120"
(https://github.com/eclipse/jetty.project/commit/a205fb3aae65f9cd6721def40bc5956b04bfa9e4)
already.

The question I am interested in is, is there any change to see this
fixed in Karaf 4.1.1
I assume it is not possible easily as we need first a new release of Pax Web.
And who knows what got broken between jetty-9.3.15.v20161220 and
jetty-9.3.16.v20170120

So, what do you think about?

Best regards,
Markus



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

Afte

Re: Karaf: feature satisfy requirements

[Markus Rathgeb]

>> Should I create a Jira + PR if it is working?

> Sure, but it would be interesting to do a complete pass on the services
> provided by each framework for completeness.

You could have a look at: https://issues.apache.org/jira/browse/KARAF-4980

Re: Karaf: feature satisfy requirements

[Markus Rathgeb]

That looks good, thanks a lot.

Do you think this is something others are interested in?
Should I create a Jira + PR if it is working?

2017-02-06 9:21 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
> The best option is to:
>   * fix the system bundle capabilities
>   * use a dependency feature as you did
>
> To fix the system bundle capabilities, depending on the framework used, you
> can do something along the following:
>
> org.osgi.framework.system.capabilities=\
>...\
>${${framework}-capabilities}
>
> felix-capabilities=
>
> equinox-capabilities=\
>
> osgi.service;effective:=active;objectClass=javax.xml.parsers.SAXParserFactory
>
> I haven't tested the above, but hopefully you'll get the idea.  It's similar
> to what's done for the ${jre-${java.specification.version}}...
>
> 2017-02-06 9:16 GMT+01:00 Markus Rathgeb <maggu2...@gmail.com>:
>>
>> Hi Guillaume,
>> thank you for your reply.
>>
>> In this special case it is about an implementation for
>> "javax.xml.parsers.SAXParserFactory" and a service for that.
>> The bundle "org.eclipse.equinox.registry" (I need to use to satisfy
>> third party dependencies) is using a tracker to find an implementation
>> and prints errors to stdout if there is no one.
>> To prevent that messages on every Karaf start I would like to have
>> such a service in the Karaf instance.
>>
>> The Equinox OSGi framework provides that service itself. Without any
>> provide capability in its manifest.
>> The Apache Felix OSGi framework doesn't provide such a service.
>>
>> So, what are the options:
>>
>> add it to "org.osgi.framework.system.capabilities"
>> IMHO this will be not correct, because the service is present if
>> Equinox is used and not present if Felix is used.
>>
>> Use "conditionals" in a feature to install another bundle that
>> provides a "javax.xml.parsers.SAXParserFactory" service if Felix is
>> used (and so the conditional will skip the installation if Equinox is
>> used).
>> If my reading has been correct, conditionals could be used for
>> installed features and not for the special OSGi framework
>> implementation.
>>
>> I can install another bundle / feature that provides that service
>> implementation for both frameworks.
>> This is okay, but if it is not necessary...
>>
>> So, is there a simple method to leave it up to the user to switch
>> between "karaf.framework" Felix or Equinox and handle that in some
>> way, so another implementation is installed only if not Equinox is
>> choosen?
>>
>> Best regards,
>> Markus
>>
>> 2017-02-06 8:45 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
>> > You can modify the etc/config.properties file, in particular the
>> >   org.osgi.framework.system.capabilities
>> > configuration.  If some service are provided by default by the framework
>> > and
>> > are missing,
>> > you may want to raise a JIRA issue and provide a patch / pull request.
>> >
>> > 2017-02-05 12:05 GMT+01:00 Markus Rathgeb <maggu2...@gmail.com>:
>> >>
>> >> Ah, okay, I assume it is caused by the missing
>> >> Provide-Capability of the Equinox bundle that it provides that service.
>> >> Could this information be added by some configuration file without
>> >> modify the Equinox bundle itself?
>> >>
>> >> 2017-02-05 11:49 GMT+01:00 Markus Rathgeb <maggu2...@gmail.com>:
>> >> > Hello,
>> >> >
>> >> > I thought I understand how the dependency flag is working for
>> >> > features
>> >> > and bundles, but at least it seems to be different.
>> >> > Perhaps someone could explain me the following scenario:
>> >> >
>> >> > Feature file:
>> >> > ===
>> >> > 
>> >> > > >> > xmlns="http://karaf.apache.org/xmlns/features/v1.4.0;>
>> >> >
>> >> >   
>> >> >
>> >> >
>> >> > osgi.service;filter:="(objectClass=javax.xml.parsers.SAXParserFactory)";effective:=active
>> >> > jboss-xerces
>> >> >   
>> >> >
>> >> >   > >> > version="1.0-SNAPSHOT">
>> >> > OSGi service for
>> >> > 'javax.xml.parsers.SAXParserFactory'
>> >> >
>> >> > 
>> >> > 
>> >> >

Re: Karaf: feature satisfy requirements

[Markus Rathgeb]

Hi Guillaume,
thank you for your reply.

In this special case it is about an implementation for
"javax.xml.parsers.SAXParserFactory" and a service for that.
The bundle "org.eclipse.equinox.registry" (I need to use to satisfy
third party dependencies) is using a tracker to find an implementation
and prints errors to stdout if there is no one.
To prevent that messages on every Karaf start I would like to have
such a service in the Karaf instance.

The Equinox OSGi framework provides that service itself. Without any
provide capability in its manifest.
The Apache Felix OSGi framework doesn't provide such a service.

So, what are the options:

add it to "org.osgi.framework.system.capabilities"
IMHO this will be not correct, because the service is present if
Equinox is used and not present if Felix is used.

Use "conditionals" in a feature to install another bundle that
provides a "javax.xml.parsers.SAXParserFactory" service if Felix is
used (and so the conditional will skip the installation if Equinox is
used).
If my reading has been correct, conditionals could be used for
installed features and not for the special OSGi framework
implementation.

I can install another bundle / feature that provides that service
implementation for both frameworks.
This is okay, but if it is not necessary...

So, is there a simple method to leave it up to the user to switch
between "karaf.framework" Felix or Equinox and handle that in some
way, so another implementation is installed only if not Equinox is
choosen?

Best regards,
Markus

2017-02-06 8:45 GMT+01:00 Guillaume Nodet <gno...@apache.org>:
> You can modify the etc/config.properties file, in particular the
>   org.osgi.framework.system.capabilities
> configuration.  If some service are provided by default by the framework and
> are missing,
> you may want to raise a JIRA issue and provide a patch / pull request.
>
> 2017-02-05 12:05 GMT+01:00 Markus Rathgeb <maggu2...@gmail.com>:
>>
>> Ah, okay, I assume it is caused by the missing
>> Provide-Capability of the Equinox bundle that it provides that service.
>> Could this information be added by some configuration file without
>> modify the Equinox bundle itself?
>>
>> 2017-02-05 11:49 GMT+01:00 Markus Rathgeb <maggu2...@gmail.com>:
>> > Hello,
>> >
>> > I thought I understand how the dependency flag is working for features
>> > and bundles, but at least it seems to be different.
>> > Perhaps someone could explain me the following scenario:
>> >
>> > Feature file:
>> > ===
>> > 
>> > > > xmlns="http://karaf.apache.org/xmlns/features/v1.4.0;>
>> >
>> >   
>> >
>> > osgi.service;filter:="(objectClass=javax.xml.parsers.SAXParserFactory)";effective:=active
>> > jboss-xerces
>> >   
>> >
>> >   > > version="1.0-SNAPSHOT">
>> > OSGi service for
>> > 'javax.xml.parsers.SAXParserFactory'
>> >
>> > 
>> > 
>> > > > start-level="30">https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/osgi/xerces/jbosgi-xerces/3.1.0.Final/jbosgi-xerces-3.1.0.Final.jar
>> >
>> > osgi.service;objectClass=javax.xml.parsers.SAXParserFactory
>> >
>> > > > start-level="30">mvn:org.osgi/org.osgi.util.xml/1.0.1
>> > > > start-level="8">mvn:org.ops4j.pax.logging/pax-logging-api/1.9.1
>> >   
>> >
>> > 
>> > ===
>> >
>> > I would expect if I install the feature "saxparserfactory" the feature
>> > jboss-xerces is installed only if the requirements are not already
>> > fulfilled.
>> > The only requirement the feature drops in should be to ensure that
>> > there is a SAXParserFactory service available.
>> > Should this be possible?
>> >
>> >
>> > Test
>> > ===
>> >
>> > I used the current Karaf 4.1.0 form the second voting round.
>> >
>> > Start a clean instance:
>> > $ bin/karaf clean
>> >
>> > As expected Apache Felix is the used OSGi framework
>> >
>> > karaf@root()> bundle:list -t 0 -s 0 | grep Active
>> >  0 │ Active │   0 │ 5.6.1   │ org.apache.felix.framework
>> >
>> > I added the feature repository file.
>> >
>> > karaf@root()> feature:repo-add
>> > file:///home/maggu2810/tmp/saxparserfactory-feature.xml
>> > Adding feature url
>> > file:///home/maggu2810/tmp/saxparserfactory-feature.xml
>> >
>> >

Re: Karaf: feature satisfy requirements

[Markus Rathgeb]

Ah, okay, I assume it is caused by the missing
Provide-Capability of the Equinox bundle that it provides that service.
Could this information be added by some configuration file without
modify the Equinox bundle itself?

2017-02-05 11:49 GMT+01:00 Markus Rathgeb <maggu2...@gmail.com>:
> Hello,
>
> I thought I understand how the dependency flag is working for features
> and bundles, but at least it seems to be different.
> Perhaps someone could explain me the following scenario:
>
> Feature file:
> ===
> 
>  xmlns="http://karaf.apache.org/xmlns/features/v1.4.0;>
>
>   
> 
> osgi.service;filter:="(objectClass=javax.xml.parsers.SAXParserFactory)";effective:=active
> jboss-xerces
>   
>
>version="1.0-SNAPSHOT">
> OSGi service for 'javax.xml.parsers.SAXParserFactory'
>
> 
> 
>  start-level="30">https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/osgi/xerces/jbosgi-xerces/3.1.0.Final/jbosgi-xerces-3.1.0.Final.jar
> 
> osgi.service;objectClass=javax.xml.parsers.SAXParserFactory
>
>  start-level="30">mvn:org.osgi/org.osgi.util.xml/1.0.1
>  start-level="8">mvn:org.ops4j.pax.logging/pax-logging-api/1.9.1
>   
>
> 
> ===
>
> I would expect if I install the feature "saxparserfactory" the feature
> jboss-xerces is installed only if the requirements are not already
> fulfilled.
> The only requirement the feature drops in should be to ensure that
> there is a SAXParserFactory service available.
> Should this be possible?
>
>
> Test
> ===
>
> I used the current Karaf 4.1.0 form the second voting round.
>
> Start a clean instance:
> $ bin/karaf clean
>
> As expected Apache Felix is the used OSGi framework
>
> karaf@root()> bundle:list -t 0 -s 0 | grep Active
>  0 │ Active │   0 │ 5.6.1   │ org.apache.felix.framework
>
> I added the feature repository file.
>
> karaf@root()> feature:repo-add
> file:///home/maggu2810/tmp/saxparserfactory-feature.xml
> Adding feature url file:///home/maggu2810/tmp/saxparserfactory-feature.xml
>
> After that let's look if there is already a SAXParserFactory present:
>
> karaf@root()> service:list javax.xml.parsers.SAXParserFactory
>
> No output, so as expected, no service found.
>
> Check what will be done if the feature is installed:
>
> karaf@root()> feature:install -t -v saxparserfactory
> Adding features: saxparserfactory/[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]
> Changes to perform:
>   Region: root
> Bundles to install:
>   
> https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/osgi/xerces/jbosgi-xerces/3.1.0.Final/jbosgi-xerces-3.1.0.Final.jar
>   mvn:org.osgi/org.osgi.util.xml/1.0.1
>
> This is as I expect what should be done.
>
> Let's exit the Karaf container.
>
> karaf@root()> shutdown -f
>
>
>
> After that I used the Equinox framework
>
> $ echo 'karaf.framework=equinox' >> etc/custom.properties
>
> and started again a clean isntance.
>
> $ bin/karaf clean
>
> Ensure the feature repository is available:
>
> karaf@root()> feature:repo-add
> file:///home/maggu2810/tmp/saxparserfactory-feature.xml
> Adding feature url file:///home/maggu2810/tmp/saxparserfactory-feature.xml
>
> The Equinox OSGi framework bundle already provides a SAXParserFactory service.
>
> karaf@root()> service:list javax.xml.parsers.SAXParserFactory
> [javax.xml.parsers.SAXParserFactory]
> 
>  service.pid = 0.org.eclipse.osgi.internal.framework.XMLParsingServiceFactory
>  service.vendor = Eclipse.org - Equinox
>  service.id = 20
>  service.bundleid = 0
>  service.scope = bundle
> Provided by :
>  OSGi System Bundle (0)
>
> Now I would expect that the installation of the saxparserfactory
> feature will not trigger an installation of the jboss-xerces feature,
> because all requirements should be already satisfied.
> But it looks like:
>
> karaf@root()> feature:install -t -v saxparserfactory
> Adding features: saxparserfactory/[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]
> Changes to perform:
>   Region: root
> Bundles to install:
>   
> https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/osgi/xerces/jbosgi-xerces/3.1.0.Final/jbosgi-xerces-3.1.0.Final.jar
>   mvn:org.osgi/org.osgi.util.xml/1.0.1
>
> What am I doing wrong?
>
> Best regards,
> Markus Rathgeb

Karaf: feature satisfy requirements

[Markus Rathgeb]

Hello,

I thought I understand how the dependency flag is working for features
and bundles, but at least it seems to be different.
Perhaps someone could explain me the following scenario:

Feature file:
===

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

  

osgi.service;filter:="(objectClass=javax.xml.parsers.SAXParserFactory)";effective:=active
jboss-xerces
  

  
OSGi service for 'javax.xml.parsers.SAXParserFactory'



https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/osgi/xerces/jbosgi-xerces/3.1.0.Final/jbosgi-xerces-3.1.0.Final.jar

osgi.service;objectClass=javax.xml.parsers.SAXParserFactory

mvn:org.osgi/org.osgi.util.xml/1.0.1
mvn:org.ops4j.pax.logging/pax-logging-api/1.9.1
  


===

I would expect if I install the feature "saxparserfactory" the feature
jboss-xerces is installed only if the requirements are not already
fulfilled.
The only requirement the feature drops in should be to ensure that
there is a SAXParserFactory service available.
Should this be possible?


Test
===

I used the current Karaf 4.1.0 form the second voting round.

Start a clean instance:
$ bin/karaf clean

As expected Apache Felix is the used OSGi framework

karaf@root()> bundle:list -t 0 -s 0 | grep Active
 0 │ Active │   0 │ 5.6.1   │ org.apache.felix.framework

I added the feature repository file.

karaf@root()> feature:repo-add
file:///home/maggu2810/tmp/saxparserfactory-feature.xml
Adding feature url file:///home/maggu2810/tmp/saxparserfactory-feature.xml

After that let's look if there is already a SAXParserFactory present:

karaf@root()> service:list javax.xml.parsers.SAXParserFactory

No output, so as expected, no service found.

Check what will be done if the feature is installed:

karaf@root()> feature:install -t -v saxparserfactory
Adding features: saxparserfactory/[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]
Changes to perform:
  Region: root
Bundles to install:
  
https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/osgi/xerces/jbosgi-xerces/3.1.0.Final/jbosgi-xerces-3.1.0.Final.jar
  mvn:org.osgi/org.osgi.util.xml/1.0.1

This is as I expect what should be done.

Let's exit the Karaf container.

karaf@root()> shutdown -f



After that I used the Equinox framework

$ echo 'karaf.framework=equinox' >> etc/custom.properties

and started again a clean isntance.

$ bin/karaf clean

Ensure the feature repository is available:

karaf@root()> feature:repo-add
file:///home/maggu2810/tmp/saxparserfactory-feature.xml
Adding feature url file:///home/maggu2810/tmp/saxparserfactory-feature.xml

The Equinox OSGi framework bundle already provides a SAXParserFactory service.

karaf@root()> service:list javax.xml.parsers.SAXParserFactory
[javax.xml.parsers.SAXParserFactory]

 service.pid = 0.org.eclipse.osgi.internal.framework.XMLParsingServiceFactory
 service.vendor = Eclipse.org - Equinox
 service.id = 20
 service.bundleid = 0
 service.scope = bundle
Provided by :
 OSGi System Bundle (0)

Now I would expect that the installation of the saxparserfactory
feature will not trigger an installation of the jboss-xerces feature,
because all requirements should be already satisfied.
But it looks like:

karaf@root()> feature:install -t -v saxparserfactory
Adding features: saxparserfactory/[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]
Changes to perform:
  Region: root
Bundles to install:
  
https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/osgi/xerces/jbosgi-xerces/3.1.0.Final/jbosgi-xerces-3.1.0.Final.jar
  mvn:org.osgi/org.osgi.util.xml/1.0.1

What am I doing wrong?

Best regards,
Markus Rathgeb

Re: Unable to resolve 'org.osgi.service.component.annotations'

[Markus Rathgeb]

Hi Jens,

> So as I understood it the annotations should not be imported.

Yes, there is no need to import the component service annotations.
As already written, this annotations are used a compile time to
generate the XML files for DS.

Best regards,
Markus

Re: A way to extend/parent "assembly-property-edits.xml"

[Markus Rathgeb]

Hi Jens,

I run into that "property file edit single location" problem myself
from time to time.
I planed to create a patch for that but haven't found any time for this, yet.

Best regards,
Markus