Re: missing requirement [org.apache.karaf.features.core/4.0.5] osgi.wiring.package; filter:="(osgi.wiring.package=org.eclipse.equinox.region.management)

2016-06-30 Thread Allan C.
Please ignore this. It's working after I've updated the xml namespace from 1.0.0 to 1.3.0. Regards, Allan C. On Fri, Jul 1, 2016 at 8:15 AM, Allan C. wrote: > Hi, > > I am trying to get my feature installed but encountered this exception: > > 08:10:49,424 | ERROR |

missing requirement [org.apache.karaf.features.core/4.0.5] osgi.wiring.package; filter:="(osgi.wiring.package=org.eclipse.equinox.region.management)

2016-06-30 Thread Allan C.
Hi, I am trying to get my feature installed but encountered this exception: 08:10:49,424 | ERROR | ShellUtil:149 | 44 | Exception caught while executing command org.osgi.service.resolver.ResolutionException: Unable to resolve org.apache.karaf.features.core/4.0.5: missing requirement

Re: Different log level for different Karaf Bundles

2016-06-30 Thread Debraj Manna
My bundles were using different loggers. So created a logger category in the pax-logging as mentioned by JB. Bengt's solution also looks interesting I will give it a try. On Thu, Jun 30, 2016 at 6:18 PM, Jean-Baptiste Onofré wrote: > Yes, it's what I said: create new sift

Re: Reasons that triggers IllegalStateException: Invalid BundleContext

2016-06-30 Thread Cristiano Costantini
Hello all and thank you! Well, I cannot easily copy the stack because it comes from a server I'm connected to in VPN and remote desktop, and I cannot make copy so I've copied the first line of the stack from one of my searches for info on the web. Interestingly, we use Spring-DM, so we don't use

Re: Reasons that triggers IllegalStateException: Invalid BundleContext

2016-06-30 Thread Nick Baker
A more complete stack trace would help us point you to the offending code. I can say that I usually see this when a Service is still held by someone when it should have been removed from "play" by a ServiceTracker or other similar mechanism. -Nick From: Cristiano Costantini

pax-jdbc-dbcp2 and oracle connection pooling

2016-06-30 Thread dpravin
Hello, We are exploring to use pax-jdbc component/utility for managing database connections. My environment is, Jboss Fuse 6.2.1 pax-jdbc 0.9.0 Oracle - 11.2.0.4.0 Installed following features from pax-jdbc, >features:install transaction jndi pax-jdbc-oracle pax-jdbc-pool-dbcp2

version 4.0.6

2016-06-30 Thread Leschke, Scott
I was wondering if there is an ETA on the next version of Karaf. Might we still see it today or will it be delayed a bit. Not trying to be pushy, just doing some planning. Scott

Re: Reasons that triggers IllegalStateException: Invalid BundleContext

2016-06-30 Thread Jean-Baptiste Onofré
Hi Cristiano, I bet you have a refresh that cause the bundle context you are using doesn't exist anymore (recreated). Regards JB On 06/30/2016 04:57 PM, Cristiano Costantini wrote: Hello All, I'n our application it happen sometime to find in situations where we get the "Invalid

Re: bundles starting automatically

2016-06-30 Thread Jean-Baptiste Onofré
Hi Laci, yes, the feature resolver can deal with the bundle startup now. Take a look in etc/org.apache.karaf.features.cfg, you have a property to control the resolver behavior. Generally speaking, the resolver does it for a reason (maybe a refresh), so, I would check what it does using -v

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread Scott Lewis
Also to consider: ECF provides an impl of the OSGi R6 Remote Service/Remote Service Admin specifications [1] with pluggable distribution providers [2]. Our Jax-RS provider [3] uses/is based upon CXF (or Jersey). Scott [1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project [2]

Re: Reasons that triggers IllegalStateException: Invalid BundleContext

2016-06-30 Thread Tim Ward
Hi Cristiano, That exception means that you are trying to use a bundle context which is no longer valid because the bundle has been stopped. There are all sorts of ways that code can end up hanging on to a Bundle Context when it shouldn't, and it may be caused by something as simple as a race

Reasons that triggers IllegalStateException: Invalid BundleContext

2016-06-30 Thread Cristiano Costantini
Hello All, I'n our application it happen sometime to find in situations where we get the "Invalid BundleContext" exception: java.lang.IllegalStateException: Invalid BundleContext. at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:453) What are the potential

Re: Log4j NTEventLogAppender in Karaf 4.0.5

2016-06-30 Thread Achim Nierbeck
Hi Bengt, newer versions of Pax-Logging don't use log4j2 per default so this should still work ... the underlying impl is still log4j 1 unless someone changed it on a minor version update ... regards, Achim 2016-06-30 16:23 GMT+02:00 Bengt Rodehav : > Thanks JB, > > Tried

Re: Log4j NTEventLogAppender in Karaf 4.0.5

2016-06-30 Thread Bengt Rodehav
Thanks JB, Tried it though and no diffference. When investigating this it seems like newer versions of pax-logging uses log4j2. Unfortunately the NTEventLogAppender is incompatible with log4j2. I've found the project log4jna that seems to target this. Unfortunately I cannot find a released

bundles starting automatically

2016-06-30 Thread Laci Gaspar
Hi we have several bundles (features) installed in karaf 4.0.5. I noticed that if I stop some of them and after that install a new feature, the stopped bundles start automatically. If I remember correctly this didn't happen in karaf 2.x. Is it possible to configure the features so that they

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread James Carman
Consider using CXF. Very well tested. On Thu, Jun 30, 2016 at 8:46 AM Artur Lojewski wrote: > OK, > > thanks both of you for your response! I forgot to mention that I am using > the 'OSGi JAX-RS Connector' v5.3.1 from EclipseSource. > > So one can use the config admin to set

Re: Log4j NTEventLogAppender in Karaf 4.0.5

2016-06-30 Thread Jean-Baptiste Onofré
In Karaf 4, the dll should go in lib/ext. Regards JB On 06/30/2016 02:16 PM, Bengt Rodehav wrote: I have a feeling that I need to put the NTEventLogAppender.amd4.dll in another directory in Karaf 4.0.5 then in Karaf 2.4.1. I have always put it in the directory %KARAF_HOME%/lib which works for

Re: Different log level for different Karaf Bundles

2016-06-30 Thread Jean-Baptiste Onofré
Yes, it's what I said: create new sift appender. Regards JB On 06/30/2016 02:33 PM, Bengt Rodehav wrote: You can do this by using MDC combined with filters (I implemented that in Pax logging a few years back). E g if you use this root logger: log4j.rootLogger=INFO, stdout, info, error,

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread Artur Lojewski
OK, thanks both of you for your response! I forgot to mention that I am using the 'OSGi JAX-RS Connector' v5.3.1 from EclipseSource. So one can use the config admin to set the 'root' path as follows: /config:property-set -p com.eclipsesource.jaxrs.connector root /foo/ This works for root paths

Re: Different log level for different Karaf Bundles

2016-06-30 Thread James Carman
Are you perhaps looking for the "additivity" flag? https://logging.apache.org/log4j/1.2/manual.html On Thu, Jun 30, 2016 at 8:33 AM Bengt Rodehav wrote: > You can do this by using MDC combined with filters (I implemented that in > Pax logging a few years back). > > E g if

Re: Different log level for different Karaf Bundles

2016-06-30 Thread Bengt Rodehav
You can do this by using MDC combined with filters (I implemented that in Pax logging a few years back). E g if you use this root logger: log4j.rootLogger=INFO, stdout, info, error, bundle, context, osgi:* And you define the "bundle" log as follows:

Re: Log4j NTEventLogAppender in Karaf 4.0.5

2016-06-30 Thread Bengt Rodehav
I have a feeling that I need to put the NTEventLogAppender.amd4.dll in another directory in Karaf 4.0.5 then in Karaf 2.4.1. I have always put it in the directory %KARAF_HOME%/lib which works for Karaf 2.4.1. Where should DLL's be put in Karaf 4.0.5? /Bengt 2016-06-29 17:37 GMT+02:00 Bengt

Re: Different log level for different Karaf Bundles

2016-06-30 Thread Jean-Baptiste Onofré
Then it's different sift appenders that you have to define. Generally speaking, you don't need sift for what you want: if your bundles use different loggers, then, just create the logger category in the pax-logging config. Regards JB On 06/30/2016 01:56 PM, Debraj Manna wrote: Yeah if I

Re: Different log level for different Karaf Bundles

2016-06-30 Thread Debraj Manna
Yeah if I enable sifting appender let's say with a config and add it to rootLogger log4j.appender.sift.threshold=DEBUG Then this will make log level DEBUG for all bundles. I am trying to ask is let's say I have two bundles1 & bundles2 and I want bundle1 's log level to be DEBUG and bundle2 log

Re: Different log level for different Karaf Bundles

2016-06-30 Thread Jean-Baptiste Onofré
Hi, I don't see the sift appender enable for the root logger. You should have: log4j.rootLogger=DEBUG, async, sift, osgi:* Regards JB On 06/30/2016 08:23 AM, Debraj Manna wrote: In |Karaf 3.0.5| running under |Servicemix 6.1.0| my |org.ops4j.pax.logging.cfg| looks like below:- |# Root

Re: JAX-RS Annotations and Apache Karaf 4.0.5

2016-06-30 Thread Jean-Baptiste Onofré
Hi Artur, /services is the CXF context. To change it, you have to change the CXF config in etc/org.apache.cxf.osgi.cfg: org.apache.cxf.servlet.context=/services Regards JB On 06/30/2016 07:28 AM, Artur Lojewski wrote: Hi, I am implementing a REST service with Apache Karaf 4.0.5 with

Apache Karaf feature prerequisite

2016-06-30 Thread Patrik Strömvall
I have the follow pseudo-feature: http://karaf.apache.org/xmlns/features/v1.3.0; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.3.0 http://karaf.apache.org/xmlns/features/v1.3.0;>...BundleC1... C...BundleA1... C

Different log level for different Karaf Bundles

2016-06-30 Thread Debraj Manna
In Karaf 3.0.5 running under Servicemix 6.1.0 my org.ops4j.pax.logging.cfg looks like below:- # Root logger log4j.rootLogger=DEBUG, async, osgi:* log4j.throwableRenderer=org.apache.log4j.OsgiThrowableRenderer # To avoid flooding the log when using DEBUG level on an ssh connection and doing