Problems due to the endorsed java.lang.Exception

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

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

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 no

Re: Discuss: Use DS for karaf bundles

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

Re: Discuss: Use DS for karaf bundles

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 t

Re: Discuss: Use DS for karaf bundles

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 ben

Re: Discuss: Use DS for karaf bundles

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

Re: Discuss: Use DS for karaf bundles

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

Re: Discuss: Use DS for karaf bundles

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

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

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

Re: Discuss: Use DS for karaf bundles

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

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

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

Re: Discuss: Use DS for karaf bundles

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

Re: Discuss: Use DS for karaf bundles

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 s

Re: Discuss: Use DS for karaf bundles

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

Re: Discuss: Use DS for karaf bundles

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

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

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

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

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,

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

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 t

Re: Discuss: Use DS for karaf bundles

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 goi

Re: Discuss: Use DS for karaf bundles

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

Discuss: Use DS for karaf bundles

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 i

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

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 havi