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 |
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
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
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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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,
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
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
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:
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
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
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
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
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
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
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
28 matches
Mail list logo