Problems due to the endorsed java.lang.Exception

[Cristiano Costantini]

Hello all,

it is some days I was having troubles using CXF services on ServiceMix (and
it is some days I spam on the mailing list of ServiceMix, Camel and CXF :-D
) and I've finally come to the source of my issues which are due to the
"endorsed" java.lang.Exception which is used by Karaf:

https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java

My problem is due to the fact that this class has a public property,
public Class[] getClassContext() {
return classContext;
}
which is seen by JaxB at runtime inside Karaf which cause it to marshall
the Exception in SOAP services with a wrong XML, an XML which include
 tags.

The class in Karaf has not changed since committed by Guillaume Nodet in
2010, so this issue with CXF has probably always been there.

In my opinion, this getter should be private or protected as I guess it is
only used on the nested class method's getThrowableContext (it is a
replacement for the JRE's class, I don't think there are external project
using this modification of the Exception class).


To confirm my thesis, I've hacked the org.apache.karaf.exception-2.4.0.jar
inside the lib/endorsed folder with a class compiled by myself where I've
changed the method to
private Class[] getClassContext() {
return classContext;
}
and with this hack, Karaf has continued to work (and my CXF service now
works properly).

Do you think there are potential side effects in this fix?
Do you need me to open an issue on Jira to handle the problem?
If it is confirmed that the fix of making this method private, do you think
it could be included soon on the next Karaf Release?

Thank you very much to all,
Cristiano

Re: Problems due to the endorsed java.lang.Exception

[Matt Sicker]

If there's a way to fix this in log4j, that would be better.

On 19 March 2016 at 06:02, James Carman  wrote:

> That's kind of a nasty trick just to get pretty stack traces.  Is this
> really necessary?
>
> On Fri, Mar 18, 2016 at 3:05 PM Guillaume Nodet  wrote:
>
> > I wrote that years ago and nobody complained about it, until today
> > Adding the @XmlTransient should be a good and quick fix.
> >
> > The benefit of the custom Exception is that this information is stored
> > along with the exception. This information is always lost when you need
> it
> > to render the exception, as the stack trace may be completely different
> and
> > even in a from different thread, which mean you loose the information. So
> > ReflectionUtil.getCurrentStackTrace() works the same, but the information
> > is the one of the calling code, not the one of the exception, and that's
> > useless.
> >
> > If you look at a stack trace in Karaf, it looks like the following:
> >
> > org.apache.karaf.shell.support.MultiException: Error installing bundles:
> >
> > Unable to install bundle foo
> >
> > at
> >
> >
> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
> > ~[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at org.apache.karaf.bundle.command.Install.execute(Install.java:113)
> > [12:org.apache.karaf.bundle.core:4.1.0.SNAPSHOT]
> >
> > at
> >
> >
> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at
> >
> >
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at
> >
> >
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:548)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:474)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:363)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:227)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> > [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
> >
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> >
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > [?:?]
> >
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> > [?:?]
> >
> > at java.lang.Thread.run(Thread.java:745) [?:?]
> >
> > The information in the brackets, at the end of each line, is actually
> > accurate (bundle id, symbolic name, version).  Without the information
> > stored in the Exception, I'm not aware of any way to do that
> unfortunately.
> >
> > 2016-03-18 18:41 GMT+01:00 Matt Sicker :
> >
> > > What's wrong with the class context from
> > > ReflectionUtil.getCurrentStackTrace() that requires a custom
> > implementation
> > > of Exception?
> > >
> > > On 18 March 2016 at 12:11, Guillaume Nodet  wrote:
> > >
> > > > The getClassContext() method is used in pax-logging to render the
> > > exception
> > > > in a nicer way.
> > > > I don't have any problem moving the qualifier to protected or
> whatever,
> > > but
> > > > we'd need to change the code in pax-logging
> > > >
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
> > > >
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
> > > >
> > > > It should not be a big deal, but the current code expect the method
> to
> > be
> > > > public unfortunately.
> > > >
> > > > Guillaume
> > > >
> > > >
> > > > 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré :
> > > >
> > > > > Hi Cristiano,
> > > > >
> > > > > I think you are right, it's probably something existing for a
> while.
> > > I'm
> > > > > just surprised that you encountered now.
> > > > >
> > > > > Let me check your detailed use case that you sent previously.
> > > > >
> > > > > Regards
> > > > > JB
> > > > >
> > > > >
> > > > > On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
> > > > >
> > > > >> Hello all,
> > > > >>
> > > > >> it is some days I was having troubles using CXF services on
> > ServiceMix
> > > > >> (and
> > > > >> it is some days I spam on the mailing list of ServiceMix, Camel
> and
> > > CXF
> > > > >> :-D
> > > > >

Re: Discuss: Use DS for karaf bundles

[Łukasz Dywicki]

-1 With current codebase I must say that I can not support this idea. DS is 
more limited than blueprint and custom activators we currently have. I already 
tried to wire some things with DS and it is not possible - ie. making JAAS 
realm with login modules inside is not possible. Starting thread from it or 
wiring in bundle context requires hand crafting or wrappers. Far closer to what 
I would appreciate is Felix Dependency Manager [1][2], which will have similar 
frames as our org.apache.karaf.util (base activator class) but better syntax 
and chances for a bit wider community of users. There is also fresh module 
which supports Java 8 syntax which is much more flexible than creating 
components by hand [3]. Some day, if we will switch to Java 8 it will be 
blessing, for now it is just an extra module.
For sure felix dependency manager is less popular than declarative services 
which are part of osgi spec, however I’m sure it will have even smaller memory 
footprint than DS cause it is still plain Java which does not require XML 
parsing, will be faster to start up, and will offer similar or smaller 
complexity (see troubles with more advanced injections in DS).
I must say that when I saw new Activators in Karaf 4 I was a bit lost, but at 
the end it wasn’t that hard to pick it up and use karaf.util in my own stuff. 
What I do miss for community is lack of documentation and example projects. 
More over in some places it is similar to Felix Dependency Manager which makes 
me wonder if we could use it/join forces instead of reinventing the wheel. For 
sure it is extra dependency which may conflict with users, but may also 
interest people who use Felix DM to come and use Karaf. :-)

[1] 
http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
 

[2] https://github.com/apache/felix/tree/trunk/dependencymanager 

[3] 
https://github.com/apache/felix/tree/trunk/dependencymanager/org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/hello
 


Best regards,
Łukasz Dywicki
--
Apache Karaf Committer & PMC
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org


> Wiadomość napisana przez Jean-Baptiste Onofré  w dniu 17 
> mar 2016, o godz. 20:15:
> 
> -0
> 
> I'm puzzled here:
> - on one hand, I see that it can help for development, improve support of scr 
> for some parts of Karaf (shell commands, etc), so it could be a good move
> - on the other hand, it's a core dependency, as we had for blueprint, so with 
> the same problem: even the minimal distribution will require DS/SCR support.
> 
> Anyway, if we go this way, it will be on a first major release (maybe 5.x as 
> we removed blueprint from 3.x to 4.x).
> 
> Regards
> JB
> 
> On 03/17/2016 04:43 PM, Christian Schneider wrote:
>> We currently use some custom Activator base classes to wire the karaf
>> bundles. The goal of this was to avoid depending on blueprint
>> as it is a quite heavy dependency and makes it harder to use a different
>> blueprint impl or version.
>> 
>> There are some problems with this approach though:
>> - It makes it harder for new people to understand what we are doing
>> - The custom code is more error prone than a proven framework
>> 
>> So I propose to switch our own bundles to use DS to expose and wire
>> services.
>> 
>> There are some advantages:
>> - The DS annotation approach is easier to understand and more self
>> documenting than the custom code
>> - We get rid of the classes in util for the custom code
>> - The scr commands help diagnose problems
>> 
>> The main cost is that we need to always install the felix scr bundle.
>> 
>> To prove that it can work I switched bundle core in a branch
>> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
>> The DS based code works quite nicely.
>> 
>> Btw. I found a small problem with our shell command extender. It only
>> seems to work on all commands or none. If there is any required service
>> missing then none of the commands is installed.
>> This made it hard for me to diagnose problems as I was missing all
>> bundle commands ;-)
>> So while working on the switch I thought about two improvements to the
>> extender:
>> 1. Work on each command individually. So each command can activate as
>> soon as the deps are met
>> 2. Provide a service and commands to diagnose problems like the scr
>> commands
>> 
>> Christian
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net 
> Talend - http://www.talend.com 

Re: Discuss: Use DS for karaf bundles

[Jean-Baptiste Onofré]

The shell core headers don't import blueprint, and the shell feature 
doesn't depend to the blueprint feature.


What you see comes from the shell-compat feature which brings the "old" 
blueprint command extender (you are right, for backward compatibility, 
this feature is installed by default in the Karaf standard distribution).


What I meant is that if you remove the aries-blueprint and shell-compat 
features, Karaf is still running without these dependencies.


Regards
JB

On 03/18/2016 07:24 PM, Milen Dyankov wrote:

This is what I mean:

karaf@root()> bundle:info 44

Apache Karaf :: Shell :: Core (44)

...


karaf@root()> bundle:requirements 44 | grep blueprint
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
org.apache.aries.blueprint.api [11]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
org.apache.aries.blueprint.api [11]



On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré 
wrote:


Hi Milen,

Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint
(blueprint is not defined as a  and so not in the manifest,
even for the command extender).

Regards
JB


On 03/18/2016 07:14 PM, Milen Dyankov wrote:


I personally think DS is pretty much what OSGi Alliance is going to
promote
(together with the enRoute project) and from that perspective if any
component framework's user base is going to grow that would be DS. But if
you guys want to still do it the "hard way" that's fine too. It just means
less people will be able to contribute.

As for things that can not be done with DS, I don't think Christian meant
to say everything must be rewritten! If something needs to be done
differently (activators/tackers/...) than it can/should be. It's not all
or
nothing scenario IMHO.

Finally about Blueprint. I keep reading in posts that Karaf got rid of
Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
depends on Blueprint. So when you say "the bundles in Karaf are
independent"
what exactly do you mean?

Best,
Milen



On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet 
wrote:

I agree with Achim and Lukasz.


Here are the advantages of the current solution:

1/ No additional dependency.  One thing that I really care about is that
the bundles in Karaf are independent.  I.e. they do not rely on an
extender.   The benefit is that you can upgrade the bundles independently
and you don't have an additional bundle which cause all the bundles to be
refreshed / restarted.

2/ Very lightweight. The current framework only consist in 3 classes :
BaseActivator, SingleServiceTracker,
SingleServiceTracker$SingleServiceListener.
   Even the annotations are not included at runtime.

3/ Very fast. No xml parsing, no reflection.  Just the
OSGI-INF/karaf-tracker/ property file which is loaded by the activator.
So
it's really fast at startup.

4/ Very robust. Quite the contrary to what you say, I think this very
small
framework is way more robust than blueprint or DS.  I spent quite some
time
load-testing karaf 4 before the release, using the bundle:load-test
command.

5/ DS exclusively uses the OSGi registry for wiring.  There's no notion
of
"internal" wiring, everything is exposed.  So by default, the
capabilities
/ requirements contain much more than what is needed, with the additional
semantical change where the bundle could be wired to components coming
from
different bundles (check the bundle manifest in your branch).

So yes, the main drawback are : limited scope and not documented, but
given
is has never been written to be used outside karaf, I don't see those as
real problems.   If the concern is users, I'm all for advertising the use
of DS or Blueprint for our users, I don't think they should use our
internal framework which is much more low level.


2016-03-17 16:43 GMT+01:00 Christian Schneider 
:


We currently use some custom Activator base classes to wire the karaf

bundles. The goal of this was to avoid depending on blueprint
as it is a quite heavy dependency and makes it harder to use a different
blueprint impl o

Re: Discuss: Use DS for karaf bundles

[Christian Schneider]

2016-03-18 13:38 GMT+01:00 Guillaume Nodet :

> I agree with Achim and Lukasz.
>
> Here are the advantages of the current solution:
>
> 1/ No additional dependency.  One thing that I really care about is that
> the bundles in Karaf are independent.  I.e. they do not rely on an
> extender.   The benefit is that you can upgrade the bundles independently
> and you don't have an additional bundle which cause all the bundles to be
> refreshed / restarted.
>
Does that refresh happen with DS? Of course the bundles would kind of
restart when you update DS but that is a very
uncommon thing. Normally you only update user bundles.


>
> 2/ Very lightweight. The current framework only consist in 3 classes :
> BaseActivator, SingleServiceTracker,
> SingleServiceTracker$SingleServiceListener.
>  Even the annotations are not included at runtime.
>

I dont think that DS really slows down the startup. In Aries RSA I use DS
for the example bundle
and still get a test time of 1.5s even when spinning up two containers.
You are right though that the startup time improved a lot compared to
blueprint.

>
> 3/ Very fast. No xml parsing, no reflection.  Just the
> OSGI-INF/karaf-tracker/ property file which is loaded by the activator.  So
> it's really fast at startup.
>

As far as I recall the support for karaf commands is implemented using an
extender like in
DS. So I do not fully understand where the difference is.

>
> 4/ Very robust. Quite the contrary to what you say, I think this very small
> framework is way more robust than blueprint or DS.  I spent quite some time
> load-testing karaf 4 before the release, using the bundle:load-test
> command.
>

I did not say that the current solution is not robust. It is just not
proven as much as DS as it is only used in
our environment.


> 5/ DS exclusively uses the OSGi registry for wiring.  There's no notion of
> "internal" wiring, everything is exposed.  So by default, the capabilities
> / requirements contain much more than what is needed, with the additional
> semantical change where the bundle could be wired to components coming from
> different bundles (check the bundle manifest in your branch).
>

That is indeed a bit of a drawback of DS compared to blueprint. I dont
think the current karaf util approach is any better though
as it also does not provide internal DI support and I hope we never create
another DI solution. There are enough out there already :-)

In any case it does not seem like we can reach a consensus so lets keep
everything like it is. Maybe we can talk about that again when
we plan the next major version.

Christian
-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: Discuss: Use DS for karaf bundles

[Jean-Baptiste Onofré]

It's also available on mirror:

http://www.apache.org/dyn/closer.lua/karaf/4.0.4/apache-karaf-minimal-4.0.4.tar.gz

I will add these links on the website.

Regards
JB

On 03/18/2016 07:53 PM, Guillaume Nodet wrote:

You can download it from maven central :
   http://repo1.maven.org/maven2/org/apache/karaf/apache-karaf-minimal/

2016-03-18 19:49 GMT+01:00 Milen Dyankov :


Oh, got it now. Thanks for clearing this up. Btw, how do I get the minimal
distribution?

On Fri, Mar 18, 2016 at 7:33 PM, Jean-Baptiste Onofré 
wrote:


The shell core headers don't import blueprint, and the shell feature
doesn't depend to the blueprint feature.

What you see comes from the shell-compat feature which brings the "old"
blueprint command extender (you are right, for backward compatibility,

this

feature is installed by default in the Karaf standard distribution).

What I meant is that if you remove the aries-blueprint and shell-compat
features, Karaf is still running without these dependencies.

Regards
JB


On 03/18/2016 07:24 PM, Milen Dyankov wrote:


This is what I mean:

karaf@root()> bundle:info 44

Apache Karaf :: Shell :: Core (44)

...


karaf@root()> bundle:requirements 44 | grep blueprint
osgi.wiring.package;



(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))

resolved by:
 osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;



(&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))

resolved by:
 osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;



(&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))

resolved by:
 osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;



(&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))

resolved by:
 osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
org.apache.aries.blueprint.api [11]
osgi.wiring.package;



(&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))

resolved by:
 osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
org.apache.aries.blueprint.api [11]



On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré 
wrote:

Hi Milen,


Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint
(blueprint is not defined as a  and so not in the

manifest,

even for the command extender).

Regards
JB


On 03/18/2016 07:14 PM, Milen Dyankov wrote:

I personally think DS is pretty much what OSGi Alliance is going to

promote
(together with the enRoute project) and from that perspective if any
component framework's user base is going to grow that would be DS. But
if
you guys want to still do it the "hard way" that's fine too. It just
means
less people will be able to contribute.

As for things that can not be done with DS, I don't think Christian
meant
to say everything must be rewritten! If something needs to be done
differently (activators/tackers/...) than it can/should be. It's not

all

or
nothing scenario IMHO.

Finally about Blueprint. I keep reading in posts that Karaf got rid of
Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core"

still

depends on Blueprint. So when you say "the bundles in Karaf are
independent"
what exactly do you mean?

Best,
Milen



On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet 
wrote:

I agree with Achim and Lukasz.



Here are the advantages of the current solution:

1/ No additional dependency.  One thing that I really care about is
that
the bundles in Karaf are independent.  I.e. they do not rely on an
extender.   The benefit is that you can upgrade the bundles
independently
and you don't have an additional bundle which cause all the bundles

to

be
refreshed / restarted.

2/ Very lightweight. The current framework only consist in 3 classes

:

BaseActivator, SingleServiceTracker,
SingleServiceTracker$SingleServiceListener.
Even the annotations are not included at runtime.

3/ Very fast. No xml parsing, no reflection.  Just the
OSGI-INF/karaf-tracker/ property file which is loaded by the

activator.

So
it's really fast at startup.

4/ Very robust. Quite the contrary to what you say, I think this very
small
framework is way more robust than blueprint or DS.  I spent quite

some

time
load-testing karaf 4 before the release, using the bundle:load-test
command.

5/ DS exclusively uses the OSGi registry for wiring.  There's no

notion

of
"internal" wiring, everything is exposed.  So by default, the
capabilities
/ requirements contain much more than what is needed, with the
additional
semantical change where the bundle could be wired to components

coming

from
different bundles (check the bundle manifest in your branch).

So yes, the main drawback are : limited scop

Re: Discuss: Use DS for karaf bundles

[Milen Dyankov]

+1
17 mar 2016 16:44 "Christian Schneider" 
napisał(a):

> We currently use some custom Activator base classes to wire the karaf
> bundles. The goal of this was to avoid depending on blueprint
> as it is a quite heavy dependency and makes it harder to use a different
> blueprint impl or version.
>
> There are some problems with this approach though:
> - It makes it harder for new people to understand what we are doing
> - The custom code is more error prone than a proven framework
>
> So I propose to switch our own bundles to use DS to expose and wire
> services.
>
> There are some advantages:
> - The DS annotation approach is easier to understand and more self
> documenting than the custom code
> - We get rid of the classes in util for the custom code
> - The scr commands help diagnose problems
>
> The main cost is that we need to always install the felix scr bundle.
>
> To prove that it can work I switched bundle core in a branch
> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
> The DS based code works quite nicely.
>
> Btw. I found a small problem with our shell command extender. It only
> seems to work on all commands or none. If there is any required service
> missing then none of the commands is installed.
> This made it hard for me to diagnose problems as I was missing all bundle
> commands ;-)
> So while working on the switch I thought about two improvements to the
> extender:
> 1. Work on each command individually. So each command can activate as soon
> as the deps are met
> 2. Provide a service and commands to diagnose problems like the scr
> commands
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

Re: Discuss: Use DS for karaf bundles

[Guillaume Nodet]

I agree with Achim and Lukasz.

Here are the advantages of the current solution:

1/ No additional dependency.  One thing that I really care about is that
the bundles in Karaf are independent.  I.e. they do not rely on an
extender.   The benefit is that you can upgrade the bundles independently
and you don't have an additional bundle which cause all the bundles to be
refreshed / restarted.

2/ Very lightweight. The current framework only consist in 3 classes :
BaseActivator, SingleServiceTracker,
SingleServiceTracker$SingleServiceListener.
 Even the annotations are not included at runtime.

3/ Very fast. No xml parsing, no reflection.  Just the
OSGI-INF/karaf-tracker/ property file which is loaded by the activator.  So
it's really fast at startup.

4/ Very robust. Quite the contrary to what you say, I think this very small
framework is way more robust than blueprint or DS.  I spent quite some time
load-testing karaf 4 before the release, using the bundle:load-test command.

5/ DS exclusively uses the OSGi registry for wiring.  There's no notion of
"internal" wiring, everything is exposed.  So by default, the capabilities
/ requirements contain much more than what is needed, with the additional
semantical change where the bundle could be wired to components coming from
different bundles (check the bundle manifest in your branch).

So yes, the main drawback are : limited scope and not documented, but given
is has never been written to be used outside karaf, I don't see those as
real problems.   If the concern is users, I'm all for advertising the use
of DS or Blueprint for our users, I don't think they should use our
internal framework which is much more low level.


2016-03-17 16:43 GMT+01:00 Christian Schneider :

> We currently use some custom Activator base classes to wire the karaf
> bundles. The goal of this was to avoid depending on blueprint
> as it is a quite heavy dependency and makes it harder to use a different
> blueprint impl or version.
>
> There are some problems with this approach though:
> - It makes it harder for new people to understand what we are doing
> - The custom code is more error prone than a proven framework
>
> So I propose to switch our own bundles to use DS to expose and wire
> services.
>
> There are some advantages:
> - The DS annotation approach is easier to understand and more self
> documenting than the custom code
> - We get rid of the classes in util for the custom code
> - The scr commands help diagnose problems
>
> The main cost is that we need to always install the felix scr bundle.
>
> To prove that it can work I switched bundle core in a branch
> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
> The DS based code works quite nicely.
>
> Btw. I found a small problem with our shell command extender. It only
> seems to work on all commands or none. If there is any required service
> missing then none of the commands is installed.
> This made it hard for me to diagnose problems as I was missing all bundle
> commands ;-)
> So while working on the switch I thought about two improvements to the
> extender:
> 1. Work on each command individually. So each command can activate as soon
> as the deps are met
> 2. Provide a service and commands to diagnose problems like the scr
> commands
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>


-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Problems due to the endorsed java.lang.Exception

[Daniel Kulp]

Since Karaf is now Java7+ and jaxb-api is also endorsed, you could likely just 
add @javax.xml.bind.annotation.XmlTransient to the getter.

That said, the idea of adding public methods onto JDK level classes screams 
“bad idea” to me.  

Dan



> On Mar 18, 2016, at 1:11 PM, Guillaume Nodet  wrote:
> 
> The getClassContext() method is used in pax-logging to render the exception
> in a nicer way.
> I don't have any problem moving the qualifier to protected or whatever, but
> we'd need to change the code in pax-logging
> 
> 
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
> 
> 
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
> 
> It should not be a big deal, but the current code expect the method to be
> public unfortunately.
> 
> Guillaume
> 
> 
> 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré :
> 
>> Hi Cristiano,
>> 
>> I think you are right, it's probably something existing for a while. I'm
>> just surprised that you encountered now.
>> 
>> Let me check your detailed use case that you sent previously.
>> 
>> Regards
>> JB
>> 
>> 
>> On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
>> 
>>> Hello all,
>>> 
>>> it is some days I was having troubles using CXF services on ServiceMix
>>> (and
>>> it is some days I spam on the mailing list of ServiceMix, Camel and CXF
>>> :-D
>>> ) and I've finally come to the source of my issues which are due to the
>>> "endorsed" java.lang.Exception which is used by Karaf:
>>> 
>>> 
>>> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
>>> 
>>> My problem is due to the fact that this class has a public property,
>>> public Class[] getClassContext() {
>>> return classContext;
>>> }
>>> which is seen by JaxB at runtime inside Karaf which cause it to marshall
>>> the Exception in SOAP services with a wrong XML, an XML which include
>>>  tags.
>>> 
>>> The class in Karaf has not changed since committed by Guillaume Nodet in
>>> 2010, so this issue with CXF has probably always been there.
>>> 
>>> In my opinion, this getter should be private or protected as I guess it is
>>> only used on the nested class method's getThrowableContext (it is a
>>> replacement for the JRE's class, I don't think there are external project
>>> using this modification of the Exception class).
>>> 
>>> 
>>> To confirm my thesis, I've hacked the org.apache.karaf.exception-2.4.0.jar
>>> inside the lib/endorsed folder with a class compiled by myself where I've
>>> changed the method to
>>> private Class[] getClassContext() {
>>> return classContext;
>>> }
>>> and with this hack, Karaf has continued to work (and my CXF service now
>>> works properly).
>>> 
>>> Do you think there are potential side effects in this fix?
>>> Do you need me to open an issue on Jira to handle the problem?
>>> If it is confirmed that the fix of making this method private, do you
>>> think
>>> it could be included soon on the next Karaf Release?
>>> 
>>> Thank you very much to all,
>>> Cristiano
>>> 
>>> 
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 
> 
> 
> 
> -- 
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
> 
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/

-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: Discuss: Use DS for karaf bundles

[Milen Dyankov]

Oh, got it now. Thanks for clearing this up. Btw, how do I get the minimal
distribution?

On Fri, Mar 18, 2016 at 7:33 PM, Jean-Baptiste Onofré 
wrote:

> The shell core headers don't import blueprint, and the shell feature
> doesn't depend to the blueprint feature.
>
> What you see comes from the shell-compat feature which brings the "old"
> blueprint command extender (you are right, for backward compatibility, this
> feature is installed by default in the Karaf standard distribution).
>
> What I meant is that if you remove the aries-blueprint and shell-compat
> features, Karaf is still running without these dependencies.
>
> Regards
> JB
>
>
> On 03/18/2016 07:24 PM, Milen Dyankov wrote:
>
>> This is what I mean:
>>
>> karaf@root()> bundle:info 44
>>
>> Apache Karaf :: Shell :: Core (44)
>>
>> ...
>>
>>
>> karaf@root()> bundle:requirements 44 | grep blueprint
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
>> org.apache.aries.blueprint.core [13]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
>> org.apache.aries.blueprint.core [13]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
>> org.apache.aries.blueprint.core [13]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
>> org.apache.aries.blueprint.api [11]
>> osgi.wiring.package;
>>
>> (&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))
>> resolved by:
>> osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
>> org.apache.aries.blueprint.api [11]
>>
>>
>>
>> On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré 
>> wrote:
>>
>> Hi Milen,
>>>
>>> Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint
>>> (blueprint is not defined as a  and so not in the manifest,
>>> even for the command extender).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 03/18/2016 07:14 PM, Milen Dyankov wrote:
>>>
>>> I personally think DS is pretty much what OSGi Alliance is going to
 promote
 (together with the enRoute project) and from that perspective if any
 component framework's user base is going to grow that would be DS. But
 if
 you guys want to still do it the "hard way" that's fine too. It just
 means
 less people will be able to contribute.

 As for things that can not be done with DS, I don't think Christian
 meant
 to say everything must be rewritten! If something needs to be done
 differently (activators/tackers/...) than it can/should be. It's not all
 or
 nothing scenario IMHO.

 Finally about Blueprint. I keep reading in posts that Karaf got rid of
 Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
 depends on Blueprint. So when you say "the bundles in Karaf are
 independent"
 what exactly do you mean?

 Best,
 Milen



 On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet 
 wrote:

 I agree with Achim and Lukasz.

>
> Here are the advantages of the current solution:
>
> 1/ No additional dependency.  One thing that I really care about is
> that
> the bundles in Karaf are independent.  I.e. they do not rely on an
> extender.   The benefit is that you can upgrade the bundles
> independently
> and you don't have an additional bundle which cause all the bundles to
> be
> refreshed / restarted.
>
> 2/ Very lightweight. The current framework only consist in 3 classes :
> BaseActivator, SingleServiceTracker,
> SingleServiceTracker$SingleServiceListener.
>Even the annotations are not included at runtime.
>
> 3/ Very fast. No xml parsing, no reflection.  Just the
> OSGI-INF/karaf-tracker/ property file which is loaded by the activator.
> So
> it's really fast at startup.
>
> 4/ Very robust. Quite the contrary to what you say, I think this very
> small
> framework is way more robust than blueprint or DS.  I spent quite some
> time
> load-testing karaf 4 before the release, using the bundle:load-test
> command.
>
> 5/ DS exclusively uses the OSGi registry for wiring.  There's no notion
> of
> "internal" wiring, everything is exposed.  So by default, the
> capabilities
> / requirements contain much more than what is needed, with the
> additional
> semantical change where the bundle could be wired to

Re: Problems due to the endorsed java.lang.Exception

[Guillaume Nodet]

The getClassContext() method is used in pax-logging to render the exception
in a nicer way.
I don't have any problem moving the qualifier to protected or whatever, but
we'd need to change the code in pax-logging


https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144


https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67

It should not be a big deal, but the current code expect the method to be
public unfortunately.

Guillaume


2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré :

> Hi Cristiano,
>
> I think you are right, it's probably something existing for a while. I'm
> just surprised that you encountered now.
>
> Let me check your detailed use case that you sent previously.
>
> Regards
> JB
>
>
> On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
>
>> Hello all,
>>
>> it is some days I was having troubles using CXF services on ServiceMix
>> (and
>> it is some days I spam on the mailing list of ServiceMix, Camel and CXF
>> :-D
>> ) and I've finally come to the source of my issues which are due to the
>> "endorsed" java.lang.Exception which is used by Karaf:
>>
>>
>> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
>>
>> My problem is due to the fact that this class has a public property,
>> public Class[] getClassContext() {
>>  return classContext;
>> }
>> which is seen by JaxB at runtime inside Karaf which cause it to marshall
>> the Exception in SOAP services with a wrong XML, an XML which include
>>  tags.
>>
>> The class in Karaf has not changed since committed by Guillaume Nodet in
>> 2010, so this issue with CXF has probably always been there.
>>
>> In my opinion, this getter should be private or protected as I guess it is
>> only used on the nested class method's getThrowableContext (it is a
>> replacement for the JRE's class, I don't think there are external project
>> using this modification of the Exception class).
>>
>>
>> To confirm my thesis, I've hacked the org.apache.karaf.exception-2.4.0.jar
>> inside the lib/endorsed folder with a class compiled by myself where I've
>> changed the method to
>> private Class[] getClassContext() {
>>  return classContext;
>> }
>> and with this hack, Karaf has continued to work (and my CXF service now
>> works properly).
>>
>> Do you think there are potential side effects in this fix?
>> Do you need me to open an issue on Jira to handle the problem?
>> If it is confirmed that the fix of making this method private, do you
>> think
>> it could be included soon on the next Karaf Release?
>>
>> Thank you very much to all,
>> Cristiano
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Discuss: Use DS for karaf bundles

[Ioannis Canellos]

-1: I don't really see any real benefit In changing the current approach to
DS.

There are minor pros and cons in each approach, but the less external
dependencies the better.
Also less is more :-)

-- 
*Ioannis Canellos*

*Blog: http://iocanel.blogspot.com *
*Twitter: iocanel*

Re: Discuss: Use DS for karaf bundles

[Achim Nierbeck]

That's the reason we didn't change to DS in the first place ...
so I don't see any reason for changing.

-1

2016-03-17 16:58 GMT+01:00 Morgan :

> I only see one problem.
> JB wants to keep a normal/default distro where scr could have a place in
> the distro and also a minimal distro without scr so I don't know how you
> would deal with that?
>
>
> On 2016-03-17 16:43, Christian Schneider wrote:
>
>> We currently use some custom Activator base classes to wire the karaf
>> bundles. The goal of this was to avoid depending on blueprint
>> as it is a quite heavy dependency and makes it harder to use a different
>> blueprint impl or version.
>>
>> There are some problems with this approach though:
>> - It makes it harder for new people to understand what we are doing
>> - The custom code is more error prone than a proven framework
>>
>> So I propose to switch our own bundles to use DS to expose and wire
>> services.
>>
>> There are some advantages:
>> - The DS annotation approach is easier to understand and more self
>> documenting than the custom code
>> - We get rid of the classes in util for the custom code
>> - The scr commands help diagnose problems
>>
>> The main cost is that we need to always install the felix scr bundle.
>>
>> To prove that it can work I switched bundle core in a branch
>> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
>> The DS based code works quite nicely.
>>
>> Btw. I found a small problem with our shell command extender. It only
>> seems to work on all commands or none. If there is any required service
>> missing then none of the commands is installed.
>> This made it hard for me to diagnose problems as I was missing all bundle
>> commands ;-)
>> So while working on the switch I thought about two improvements to the
>> extender:
>> 1. Work on each command individually. So each command can activate as
>> soon as the deps are met
>> 2. Provide a service and commands to diagnose problems like the scr
>> commands
>>
>> Christian
>>
>>
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Discuss: Use DS for karaf bundles

[Milen Dyankov]

This is what I mean:

karaf@root()> bundle:info 44

Apache Karaf :: Shell :: Core (44)

...


karaf@root()> bundle:requirements 44 | grep blueprint
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
org.apache.aries.blueprint.api [11]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
   osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
org.apache.aries.blueprint.api [11]



On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré 
wrote:

> Hi Milen,
>
> Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint
> (blueprint is not defined as a  and so not in the manifest,
> even for the command extender).
>
> Regards
> JB
>
>
> On 03/18/2016 07:14 PM, Milen Dyankov wrote:
>
>> I personally think DS is pretty much what OSGi Alliance is going to
>> promote
>> (together with the enRoute project) and from that perspective if any
>> component framework's user base is going to grow that would be DS. But if
>> you guys want to still do it the "hard way" that's fine too. It just means
>> less people will be able to contribute.
>>
>> As for things that can not be done with DS, I don't think Christian meant
>> to say everything must be rewritten! If something needs to be done
>> differently (activators/tackers/...) than it can/should be. It's not all
>> or
>> nothing scenario IMHO.
>>
>> Finally about Blueprint. I keep reading in posts that Karaf got rid of
>> Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
>> depends on Blueprint. So when you say "the bundles in Karaf are
>> independent"
>> what exactly do you mean?
>>
>> Best,
>> Milen
>>
>>
>>
>> On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet 
>> wrote:
>>
>> I agree with Achim and Lukasz.
>>>
>>> Here are the advantages of the current solution:
>>>
>>> 1/ No additional dependency.  One thing that I really care about is that
>>> the bundles in Karaf are independent.  I.e. they do not rely on an
>>> extender.   The benefit is that you can upgrade the bundles independently
>>> and you don't have an additional bundle which cause all the bundles to be
>>> refreshed / restarted.
>>>
>>> 2/ Very lightweight. The current framework only consist in 3 classes :
>>> BaseActivator, SingleServiceTracker,
>>> SingleServiceTracker$SingleServiceListener.
>>>   Even the annotations are not included at runtime.
>>>
>>> 3/ Very fast. No xml parsing, no reflection.  Just the
>>> OSGI-INF/karaf-tracker/ property file which is loaded by the activator.
>>> So
>>> it's really fast at startup.
>>>
>>> 4/ Very robust. Quite the contrary to what you say, I think this very
>>> small
>>> framework is way more robust than blueprint or DS.  I spent quite some
>>> time
>>> load-testing karaf 4 before the release, using the bundle:load-test
>>> command.
>>>
>>> 5/ DS exclusively uses the OSGi registry for wiring.  There's no notion
>>> of
>>> "internal" wiring, everything is exposed.  So by default, the
>>> capabilities
>>> / requirements contain much more than what is needed, with the additional
>>> semantical change where the bundle could be wired to components coming
>>> from
>>> different bundles (check the bundle manifest in your branch).
>>>
>>> So yes, the main drawback are : limited scope and not documented, but
>>> given
>>> is has never been written to be used outside karaf, I don't see those as
>>> real problems.   If the concern is users, I'm all for advertising the use
>>> of DS or Blueprint for our users, I don't think they should use our
>>> internal framework which is much more low level.
>>>
>>>
>>> 2016-03-17 16:43 GMT+01:00 Christian Schneider >> >:
>>>
>>> We currently use some custom Activator base classes to wire the karaf
 bundles. The goal of this was to avoid depending on blueprint
 as it is a quite heavy dependency and makes it harder to use a different
 blueprint impl or version.

 There are some problems with this approach though:
 - It makes it harder for new people to understand what we are doing
 - The custom code is more error prone than a proven framework

 So I propose to switch our ow

Re: Discuss: Use DS for karaf bundles

[David Jencks]

Perhaps no one would be surprised that I think this is a good idea :-)

david jencks

> On Mar 17, 2016, at 9:06 AM, Christian Schneider  
> wrote:
> 
> I see the issue for blueprint as it is quite heavy weight.
> Scr on the other hand is just one bundle.
> 
> Christian
> 
> On 17.03.2016 16:58, Morgan wrote:
>> I only see one problem.
>> JB wants to keep a normal/default distro where scr could have a place in the 
>> distro and also a minimal distro without scr so I don't know how you would 
>> deal with that?
>> 
>> On 2016-03-17 16:43, Christian Schneider wrote:
>>> We currently use some custom Activator base classes to wire the karaf 
>>> bundles. The goal of this was to avoid depending on blueprint
>>> as it is a quite heavy dependency and makes it harder to use a different 
>>> blueprint impl or version.
>>> 
>>> There are some problems with this approach though:
>>> - It makes it harder for new people to understand what we are doing
>>> - The custom code is more error prone than a proven framework
>>> 
>>> So I propose to switch our own bundles to use DS to expose and wire 
>>> services.
>>> 
>>> There are some advantages:
>>> - The DS annotation approach is easier to understand and more self 
>>> documenting than the custom code
>>> - We get rid of the classes in util for the custom code
>>> - The scr commands help diagnose problems
>>> 
>>> The main cost is that we need to always install the felix scr bundle.
>>> 
>>> To prove that it can work I switched bundle core in a branch 
>>> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
>>> The DS based code works quite nicely.
>>> 
>>> Btw. I found a small problem with our shell command extender. It only seems 
>>> to work on all commands or none. If there is any required service missing 
>>> then none of the commands is installed.
>>> This made it hard for me to diagnose problems as I was missing all bundle 
>>> commands ;-)
>>> So while working on the switch I thought about two improvements to the 
>>> extender:
>>> 1. Work on each command individually. So each command can activate as soon 
>>> as the deps are met
>>> 2. Provide a service and commands to diagnose problems like the scr commands
>>> 
>>> Christian
>>> 
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Re: Problems due to the endorsed java.lang.Exception

[Matt Sicker]

What's wrong with the class context from
ReflectionUtil.getCurrentStackTrace() that requires a custom implementation
of Exception?

On 18 March 2016 at 12:11, Guillaume Nodet  wrote:

> The getClassContext() method is used in pax-logging to render the exception
> in a nicer way.
> I don't have any problem moving the qualifier to protected or whatever, but
> we'd need to change the code in pax-logging
>
>
>
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
>
>
>
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
>
> It should not be a big deal, but the current code expect the method to be
> public unfortunately.
>
> Guillaume
>
>
> 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré :
>
> > Hi Cristiano,
> >
> > I think you are right, it's probably something existing for a while. I'm
> > just surprised that you encountered now.
> >
> > Let me check your detailed use case that you sent previously.
> >
> > Regards
> > JB
> >
> >
> > On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
> >
> >> Hello all,
> >>
> >> it is some days I was having troubles using CXF services on ServiceMix
> >> (and
> >> it is some days I spam on the mailing list of ServiceMix, Camel and CXF
> >> :-D
> >> ) and I've finally come to the source of my issues which are due to the
> >> "endorsed" java.lang.Exception which is used by Karaf:
> >>
> >>
> >>
> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
> >>
> >> My problem is due to the fact that this class has a public property,
> >> public Class[] getClassContext() {
> >>  return classContext;
> >> }
> >> which is seen by JaxB at runtime inside Karaf which cause it to marshall
> >> the Exception in SOAP services with a wrong XML, an XML which include
> >>  tags.
> >>
> >> The class in Karaf has not changed since committed by Guillaume Nodet in
> >> 2010, so this issue with CXF has probably always been there.
> >>
> >> In my opinion, this getter should be private or protected as I guess it
> is
> >> only used on the nested class method's getThrowableContext (it is a
> >> replacement for the JRE's class, I don't think there are external
> project
> >> using this modification of the Exception class).
> >>
> >>
> >> To confirm my thesis, I've hacked the
> org.apache.karaf.exception-2.4.0.jar
> >> inside the lib/endorsed folder with a class compiled by myself where
> I've
> >> changed the method to
> >> private Class[] getClassContext() {
> >>  return classContext;
> >> }
> >> and with this hack, Karaf has continued to work (and my CXF service now
> >> works properly).
> >>
> >> Do you think there are potential side effects in this fix?
> >> Do you need me to open an issue on Jira to handle the problem?
> >> If it is confirmed that the fix of making this method private, do you
> >> think
> >> it could be included soon on the next Karaf Release?
> >>
> >> Thank you very much to all,
> >> Cristiano
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 
Matt Sicker 

Re: Problems due to the endorsed java.lang.Exception

[Guillaume Nodet]

I wrote that years ago and nobody complained about it, until today
Adding the @XmlTransient should be a good and quick fix.

The benefit of the custom Exception is that this information is stored
along with the exception. This information is always lost when you need it
to render the exception, as the stack trace may be completely different and
even in a from different thread, which mean you loose the information. So
ReflectionUtil.getCurrentStackTrace() works the same, but the information
is the one of the calling code, not the one of the exception, and that's
useless.

If you look at a stack trace in Karaf, it looks like the following:

org.apache.karaf.shell.support.MultiException: Error installing bundles:

Unable to install bundle foo

at
org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
~[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at org.apache.karaf.bundle.command.Install.execute(Install.java:113)
[12:org.apache.karaf.bundle.core:4.1.0.SNAPSHOT]

at
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:548)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:474)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:363)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:227)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]

at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:?]

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:?]

at java.lang.Thread.run(Thread.java:745) [?:?]

The information in the brackets, at the end of each line, is actually
accurate (bundle id, symbolic name, version).  Without the information
stored in the Exception, I'm not aware of any way to do that unfortunately.

2016-03-18 18:41 GMT+01:00 Matt Sicker :

> What's wrong with the class context from
> ReflectionUtil.getCurrentStackTrace() that requires a custom implementation
> of Exception?
>
> On 18 March 2016 at 12:11, Guillaume Nodet  wrote:
>
> > The getClassContext() method is used in pax-logging to render the
> exception
> > in a nicer way.
> > I don't have any problem moving the qualifier to protected or whatever,
> but
> > we'd need to change the code in pax-logging
> >
> >
> >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
> >
> >
> >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
> >
> > It should not be a big deal, but the current code expect the method to be
> > public unfortunately.
> >
> > Guillaume
> >
> >
> > 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré :
> >
> > > Hi Cristiano,
> > >
> > > I think you are right, it's probably something existing for a while.
> I'm
> > > just surprised that you encountered now.
> > >
> > > Let me check your detailed use case that you sent previously.
> > >
> > > Regards
> > > JB
> > >
> > >
> > > On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
> > >
> > >> Hello all,
> > >>
> > >> it is some days I was having troubles using CXF services on ServiceMix
> > >> (and
> > >> it is some days I spam on the mailing list of ServiceMix, Camel and
> CXF
> > >> :-D
> > >> ) and I've finally come to the source of my issues which are due to
> the
> > >> "endorsed" java.lang.Exception which is used by Karaf:
> > >>
> > >>
> > >>
> >
> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
> > >>
> > >> My problem is due to the fact that this class has a public property,
> > >> public Class[] getClassContext() {
> > >>  return classContext;
> > >> }
> > >> which is seen by JaxB at runtime inside Karaf which cause it to
> marshall
> > >> the Exception in SOAP services with a wrong XML, an XML which include
> > >>  tags.
> > >>
> > >> The class in Karaf has not changed since committed by Guillaume Nodet
> in
> > >> 2010, so this issue with CXF has probably always been there.
> > >>
> > >> In my opinion, this getter should be private or pro

Re: Problems due to the endorsed java.lang.Exception

[James Carman]

That's kind of a nasty trick just to get pretty stack traces.  Is this
really necessary?

On Fri, Mar 18, 2016 at 3:05 PM Guillaume Nodet  wrote:

> I wrote that years ago and nobody complained about it, until today
> Adding the @XmlTransient should be a good and quick fix.
>
> The benefit of the custom Exception is that this information is stored
> along with the exception. This information is always lost when you need it
> to render the exception, as the stack trace may be completely different and
> even in a from different thread, which mean you loose the information. So
> ReflectionUtil.getCurrentStackTrace() works the same, but the information
> is the one of the calling code, not the one of the exception, and that's
> useless.
>
> If you look at a stack trace in Karaf, it looks like the following:
>
> org.apache.karaf.shell.support.MultiException: Error installing bundles:
>
> Unable to install bundle foo
>
> at
>
> org.apache.karaf.shell.support.MultiException.throwIf(MultiException.java:61)
> ~[28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at org.apache.karaf.bundle.command.Install.execute(Install.java:113)
> [12:org.apache.karaf.bundle.core:4.1.0.SNAPSHOT]
>
> at
>
> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at
>
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at
>
> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:548)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:474)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:363)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:227)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
> [28:org.apache.karaf.shell.core:4.1.0.SNAPSHOT]
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:?]
>
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:?]
>
> at java.lang.Thread.run(Thread.java:745) [?:?]
>
> The information in the brackets, at the end of each line, is actually
> accurate (bundle id, symbolic name, version).  Without the information
> stored in the Exception, I'm not aware of any way to do that unfortunately.
>
> 2016-03-18 18:41 GMT+01:00 Matt Sicker :
>
> > What's wrong with the class context from
> > ReflectionUtil.getCurrentStackTrace() that requires a custom
> implementation
> > of Exception?
> >
> > On 18 March 2016 at 12:11, Guillaume Nodet  wrote:
> >
> > > The getClassContext() method is used in pax-logging to render the
> > exception
> > > in a nicer way.
> > > I don't have any problem moving the qualifier to protected or whatever,
> > but
> > > we'd need to change the code in pax-logging
> > >
> > >
> > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
> > >
> > >
> > >
> > >
> >
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
> > >
> > > It should not be a big deal, but the current code expect the method to
> be
> > > public unfortunately.
> > >
> > > Guillaume
> > >
> > >
> > > 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré :
> > >
> > > > Hi Cristiano,
> > > >
> > > > I think you are right, it's probably something existing for a while.
> > I'm
> > > > just surprised that you encountered now.
> > > >
> > > > Let me check your detailed use case that you sent previously.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > >
> > > > On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
> > > >
> > > >> Hello all,
> > > >>
> > > >> it is some days I was having troubles using CXF services on
> ServiceMix
> > > >> (and
> > > >> it is some days I spam on the mailing list of ServiceMix, Camel and
> > CXF
> > > >> :-D
> > > >> ) and I've finally come to the source of my issues which are due to
> > the
> > > >> "endorsed" java.lang.Exception which is used by Karaf:
> > > >>
> > > >>
> > > >>
> > >
> >
> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
> > > >>
> > > >> My problem is due to the fact that this class has a public property,
> > > >> public Class[] getClassContext() {
> > > >>  retu

Re: Discuss: Use DS for karaf bundles

[Jean-Baptiste Onofré]

Hi Milen,

Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint 
(blueprint is not defined as a  and so not in the manifest, 
even for the command extender).


Regards
JB

On 03/18/2016 07:14 PM, Milen Dyankov wrote:

I personally think DS is pretty much what OSGi Alliance is going to promote
(together with the enRoute project) and from that perspective if any
component framework's user base is going to grow that would be DS. But if
you guys want to still do it the "hard way" that's fine too. It just means
less people will be able to contribute.

As for things that can not be done with DS, I don't think Christian meant
to say everything must be rewritten! If something needs to be done
differently (activators/tackers/...) than it can/should be. It's not all or
nothing scenario IMHO.

Finally about Blueprint. I keep reading in posts that Karaf got rid of
Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
depends on Blueprint. So when you say "the bundles in Karaf are independent"
what exactly do you mean?

Best,
Milen



On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet  wrote:


I agree with Achim and Lukasz.

Here are the advantages of the current solution:

1/ No additional dependency.  One thing that I really care about is that
the bundles in Karaf are independent.  I.e. they do not rely on an
extender.   The benefit is that you can upgrade the bundles independently
and you don't have an additional bundle which cause all the bundles to be
refreshed / restarted.

2/ Very lightweight. The current framework only consist in 3 classes :
BaseActivator, SingleServiceTracker,
SingleServiceTracker$SingleServiceListener.
  Even the annotations are not included at runtime.

3/ Very fast. No xml parsing, no reflection.  Just the
OSGI-INF/karaf-tracker/ property file which is loaded by the activator.  So
it's really fast at startup.

4/ Very robust. Quite the contrary to what you say, I think this very small
framework is way more robust than blueprint or DS.  I spent quite some time
load-testing karaf 4 before the release, using the bundle:load-test
command.

5/ DS exclusively uses the OSGi registry for wiring.  There's no notion of
"internal" wiring, everything is exposed.  So by default, the capabilities
/ requirements contain much more than what is needed, with the additional
semantical change where the bundle could be wired to components coming from
different bundles (check the bundle manifest in your branch).

So yes, the main drawback are : limited scope and not documented, but given
is has never been written to be used outside karaf, I don't see those as
real problems.   If the concern is users, I'm all for advertising the use
of DS or Blueprint for our users, I don't think they should use our
internal framework which is much more low level.


2016-03-17 16:43 GMT+01:00 Christian Schneider :


We currently use some custom Activator base classes to wire the karaf
bundles. The goal of this was to avoid depending on blueprint
as it is a quite heavy dependency and makes it harder to use a different
blueprint impl or version.

There are some problems with this approach though:
- It makes it harder for new people to understand what we are doing
- The custom code is more error prone than a proven framework

So I propose to switch our own bundles to use DS to expose and wire
services.

There are some advantages:
- The DS annotation approach is easier to understand and more self
documenting than the custom code
- We get rid of the classes in util for the custom code
- The scr commands help diagnose problems

The main cost is that we need to always install the felix scr bundle.

To prove that it can work I switched bundle core in a branch
https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
The DS based code works quite nicely.

Btw. I found a small problem with our shell command extender. It only
seems to work on all commands or none. If there is any required service
missing then none of the commands is installed.
This made it hard for me to diagnose problems as I was missing all bundle
commands ;-)
So while working on the switch I thought about two improvements to the
extender:
1. Work on each command individually. So each command can activate as

soon

as the deps are met
2. Provide a service and commands to diagnose problems like the scr
commands

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com





--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/







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

Re: Discuss: Use DS for karaf bundles

[Christian Schneider]

I see the issue for blueprint as it is quite heavy weight.
Scr on the other hand is just one bundle.

Christian

On 17.03.2016 16:58, Morgan wrote:

I only see one problem.
JB wants to keep a normal/default distro where scr could have a place 
in the distro and also a minimal distro without scr so I don't know 
how you would deal with that?


On 2016-03-17 16:43, Christian Schneider wrote:
We currently use some custom Activator base classes to wire the karaf 
bundles. The goal of this was to avoid depending on blueprint
as it is a quite heavy dependency and makes it harder to use a 
different blueprint impl or version.


There are some problems with this approach though:
- It makes it harder for new people to understand what we are doing
- The custom code is more error prone than a proven framework

So I propose to switch our own bundles to use DS to expose and wire 
services.


There are some advantages:
- The DS annotation approach is easier to understand and more self 
documenting than the custom code

- We get rid of the classes in util for the custom code
- The scr commands help diagnose problems

The main cost is that we need to always install the felix scr bundle.

To prove that it can work I switched bundle core in a branch 
https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .

The DS based code works quite nicely.

Btw. I found a small problem with our shell command extender. It only 
seems to work on all commands or none. If there is any required 
service missing then none of the commands is installed.
This made it hard for me to diagnose problems as I was missing all 
bundle commands ;-)
So while working on the switch I thought about two improvements to 
the extender:
1. Work on each command individually. So each command can activate as 
soon as the deps are met
2. Provide a service and commands to diagnose problems like the scr 
commands


Christian






--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Discuss: Use DS for karaf bundles

[Christian Schneider]

We currently use some custom Activator base classes to wire the karaf 
bundles. The goal of this was to avoid depending on blueprint
as it is a quite heavy dependency and makes it harder to use a different 
blueprint impl or version.


There are some problems with this approach though:
- It makes it harder for new people to understand what we are doing
- The custom code is more error prone than a proven framework

So I propose to switch our own bundles to use DS to expose and wire 
services.


There are some advantages:
- The DS annotation approach is easier to understand and more self 
documenting than the custom code

- We get rid of the classes in util for the custom code
- The scr commands help diagnose problems

The main cost is that we need to always install the felix scr bundle.

To prove that it can work I switched bundle core in a branch 
https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .

The DS based code works quite nicely.

Btw. I found a small problem with our shell command extender. It only 
seems to work on all commands or none. If there is any required service 
missing then none of the commands is installed.
This made it hard for me to diagnose problems as I was missing all 
bundle commands ;-)
So while working on the switch I thought about two improvements to the 
extender:
1. Work on each command individually. So each command can activate as 
soon as the deps are met

2. Provide a service and commands to diagnose problems like the scr commands

Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Problems due to the endorsed java.lang.Exception

[Jean-Baptiste Onofré]

Hi Cristiano,

I think you are right, it's probably something existing for a while. I'm 
just surprised that you encountered now.


Let me check your detailed use case that you sent previously.

Regards
JB

On 03/18/2016 05:14 PM, Cristiano Costantini wrote:

Hello all,

it is some days I was having troubles using CXF services on ServiceMix (and
it is some days I spam on the mailing list of ServiceMix, Camel and CXF :-D
) and I've finally come to the source of my issues which are due to the
"endorsed" java.lang.Exception which is used by Karaf:

https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java

My problem is due to the fact that this class has a public property,
public Class[] getClassContext() {
 return classContext;
}
which is seen by JaxB at runtime inside Karaf which cause it to marshall
the Exception in SOAP services with a wrong XML, an XML which include
 tags.

The class in Karaf has not changed since committed by Guillaume Nodet in
2010, so this issue with CXF has probably always been there.

In my opinion, this getter should be private or protected as I guess it is
only used on the nested class method's getThrowableContext (it is a
replacement for the JRE's class, I don't think there are external project
using this modification of the Exception class).


To confirm my thesis, I've hacked the org.apache.karaf.exception-2.4.0.jar
inside the lib/endorsed folder with a class compiled by myself where I've
changed the method to
private Class[] getClassContext() {
 return classContext;
}
and with this hack, Karaf has continued to work (and my CXF service now
works properly).

Do you think there are potential side effects in this fix?
Do you need me to open an issue on Jira to handle the problem?
If it is confirmed that the fix of making this method private, do you think
it could be included soon on the next Karaf Release?

Thank you very much to all,
Cristiano



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