Not sure what the exact usage of command-pool is, but given the stack
trace, it could be that a class is loaded from its name (i suspect it comes
from the configuration). In such a case, to make it work in OSGi, the
correct class loader needs to be used, one can't rely on the thread context
class
hi Jurgen,
a quick googling for Redis + OSGi gave me this [1].
Looks like someone is using jedis to connect to his redis server via
blueprint.
Might want to take a look at this.
regards, Achim
[1] -
On 04/28/2015 01:59 PM, Achim Nierbeck wrote: hi Jurgen,
a quick googling for Redis + OSGi gave me this [1].
Looks like someone is using jedis to connect to his redis server via
blueprint.
Might want to take a look at this.
regards, Achim
[1]
-
Seems to be an issue of the Aries Blueprint implementation. To me it seems
that the reference to the service (A1 or A2) is set when the component (X)
is created. It only takes those services into account which exist at that
moment. If later on another service with a higher ranking is added, the
I couldn't get the Apache Commons Pool libary to load under Karaf so I
tried rewriting the app to use BoneCP instead of HikariCP. Bone doesn't
have this dependency.
This appears to work. BoneCP does want to load. Unfortunately I also
have a Redis database which also has the dependency on Apache
Hi Jurgen,
do you have the right imports for it configured on your bundles?
So which bundle doesn't start?
Take a look at the bundle:headers ID of this bundle and check if it
actually imports the package you are looking for.
If not, make sure the bundle does import it.
regards, Achim
I have no idea how Redis uses this library, I haven't read the code. My
code does this:
new JedisPool(new JedisPoolConfig(), redis_driver[0],
Integer.parseInt(redis_driver[1]), 1800, password);
On 04/28/2015 01:41 PM, Guillaume Nodet wrote:
Not sure what the exact usage of command-pool is, but
Hi,
did you think about upgrading to a newer release of Karaf, cause I think
this issue might have been fixed with a newer version of Aries.
regards, Achim
2015-04-28 16:13 GMT+02:00 jkraushaar jochen.kraush...@doubleslash.de:
Seems to be an issue of the Aries Blueprint implementation. To me
Hi
above all, a big thank you.
aries-blueprint is defined line 51 in standard-2.4.1-features.xml
boot features grouping on Karaf 2.4.1 does not work
log:
Regards
JYT
--
View this message in context:
http://karaf.922171.n3.nabble.com/local-broker-xml-at-startup-tp4039960p4040037.html
Oh correct, it's in 2.x, not in 2.3.x. My bad.
I didn't have time to take a look yet.
I will keep you posted.
Regards
JB
On 04/28/2015 04:08 PM, sekaijin wrote:
Hi
above all, a big thank you.
aries-blueprint is defined line 51 in standard-2.4.1-features.xml
boot features grouping on Karaf
Hi Achim,
I checked the release notes of Karaf. According to them, Aries Blueprint was
updated in 3.0.3 to 1.4.2. I would really like to update to this version.
Unfortunately some of our legacy libraries are incompatible with the updates
of the JPA libraries in 3.0.3. :-(
Regards
Jochen
--
Blueprint will stay with the service it selected until this service goes
away. So for example if you would stop A1 and start it again then
blueprint would switch.
This is obviously not what people expect when the ranking is used. So I
would consider this to be either a bug or a good enhancement
I'd love to know how to do that. This page:
https://github.com/sneakybeaky/jedis-osgi
lists this information:
dependency
groupIdredis.clients/groupId
artifactIdcom.ninedemons.jedis/artifactId
version2.1.0-SNAPSHOT/version
/dependency
When I go to maven central website and search for
Getting closer..
after loading that servicemix jedis bundle I got this error while
running my code:
Error executing command: Error executing command on bundles:
Unable to execute command on bundle 113: Unresolved constraint in
bundle nl.redsocks.farm.analyzer [113]: Unable to resolve
Hi,
did you check if the bundle you are looking for is now released?
Cause usually the snapshots are deleted the minute a release is through.
regards, Achim
2015-04-28 14:11 GMT+02:00 Jurgen Voorneveld jurgen.voornev...@redsocks.nl
:
On 04/28/2015 01:59 PM, Achim Nierbeck wrote: hi Jurgen,
Hmm .. I think this is a bug then.
Probably we should always look in both the interface and the class for
the annotations. Can you open an issue for this ?
Christian
On 27.04.2015 20:00, kuvalda wrote:
Hi, Christian!
I tried your blueprint-authz bundle to to authorize in OSGi services and
Hey Achim,
right now I have one bundle that contains the Redis client classes
themselves but not the Apache Commons Pool classes. (I haven't figured
out how to install jedis as a separate bundle from maven yet, errors...)
Those classes are loaded using the import statement in the manifest:
Oh and one, more I think there is a redis OSGi client available from the
servicemix bundles.
Might want to look at that too.
Could be that you need to split your application a lot faster then you
thought :D
regards, Achim
2015-04-28 13:59 GMT+02:00 Achim Nierbeck bcanh...@googlemail.com:
hi
What I wanted to express is that users naively will expect that
blueprint will select the service with the highest ranking. Of course
when reading the spec they will probably guess that service damping
might influence this.
Do you know if we are free to change the current behaviour or if the
I can read the following in the osgi spec, section 121.7.11
The backing service for a reference proxy must not be gotten from the
OSGi service registry until an actual service object is needed, that
is, when an actual method is called on the proxy. If the backing
service becomes unregistered,
Hi,
I will take a look this morning with a simple use case.
I keep you posted.
Regards
JB
On 04/28/2015 08:59 AM, sekaijin wrote:
hello
I, as much as possible, simplified my test.
I unzipped karaf 2.4.1 and I added in system, the feature
I tested with a datasource instead of the broker (less
Thank
I suspect that you are very busy.
A+JYT
--
View this message in context:
http://karaf.922171.n3.nabble.com/local-broker-xml-at-startup-tp4039960p4040051.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Can you try, in featuresBoot, to do:
featuresBoot=(...)(hermes-resource)
I don't remember if we added boot features grouping on Karaf 2.4.
By the way, aries-blueprint doesn't exist on 2.4.
As I said, I will take a look later today.
Regards
JB
On 04/28/2015 08:59 AM, sekaijin wrote:
hello
hello
I, as much as possible, simplified my test.
I unzipped karaf 2.4.1 and I added in system, the feature
I tested with a datasource instead of the broker (less dependency)
I have all placed in a zip
to allow you to reproduce the error
I added
log4j.logger.org.apache.karaf.features = TRACE
in
It may not be what you expect, but thinking it is what no one expects seems a
bit extreme to me. DS has the concept of greedy and reluctant references so
you can specify which behavior you want.
david jencks
On Apr 28, 2015, at 10:26 AM, Christian Schneider ch...@die-schneider.net
wrote:
Hi Christian,
I opened an issue, thanks for your help:
https://issues.apache.org/jira/browse/ARIES-1314
Regards
Jochen
--
View this message in context:
http://karaf.922171.n3.nabble.com/Karaf-3-0-1-does-not-consider-service-ranking-set-by-Blueprint-tp4039991p4040043.html
Sent from the Karaf
26 matches
Mail list logo
