I'm trying to configure ServletContextListener for Servlet with whiteboard
extender via blueprint in my bundle, karaf version 4.0.4.
ServletMapping and ListenerMapping are used.
The problem is that ServletMapping and ListenerMapping services are
registered in random order, so when ServletMapping
You can add those bundles as libraries
https://github.com/apache/karaf/blob/master/assemblies/apache-karaf/pom.xml#L185-L200
2016-03-01 18:46 GMT+01:00 David Daniel :
> How do I let the validator know that I am exposing javax.validation as a
> system package. My
For jpa and jdbc we already use the new spec packages. Aries JPA and pax
jdbc use these bundles in their respective features.
Christian
2016-03-01 14:18 GMT+01:00 Mike Rumpf :
> Fair enough for ds. But in the case of the jpa/jdbc packages it really
> depends on the
How do I let the validator know that I am exposing javax.validation as a
system package. My error is
Caused by: org.osgi.service.resolver.ResolutionException: Unable to resolve
root: missing requirement [root] osgi.identity;
osgi.identity=org.glassfish.jersey.core.jersey-server;
I currently only have capabilities and requirements in my bundles manifest
and will be adding them to my features. Thank you for the example. I have
been making progress and the validation has been useful. I thought I was
good because everything runs in pax exam and my old way of building a
Hi, all,
The problem was solved, it was the 9000 TCP port that was blocked by some
FPM application. After I stopped the service, the D-OSGI worked fine.
It was very useful for me to review the logs under each container_a
and container_b, inside data/log/karaf.log. Each log has a lot of
Capabalities are evaluated in both directions. That works fine in my
environment.
A Feature example with capability could look like this:
Did you try to add the log dependency as in above example?
Can you post your feature definition?
Mike
David Daniel wrote
> I think I have figured out
I think I have figured out where I was going wrong. If I include framework
as a prerequisite then it gives me an error message that I believe is more
accurate.
[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.0.4:assembly
(default-assembly) on project
Fair enough for ds. But in the case of the jpa/jdbc packages it really
depends on the implementation though. For my setup the jdbc package (namely
the DataSourceFactory class) is not provided by the service provider sadly.
So I have to rely on the designated bundle.
Mike
Guillaume Nodet-2
You may want to not align compile time dependencies (the maven deps) with
the runtime dependencies (bundles listed in features).
You can safely depend on the overall compendium jar at build time, this can
ease the build a bit.
At runtime, you should depend on a feature which will provide the DS
Of course I read that before. However for development you will need the ds
annotation classes which are not part of the scr bundle. You will nee the
part of the compendium bundle to make it work.
I just configured a JPA/JDBC for hibernate/postgres solution in karaf. The
same applies here: I
Have you read this one:
http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages
Christian Schneider posted the link already above
If you have a look at
maggu2810 wrote
> It has been some time ago, I had to use the Equinox Event Admin and DS
> implementation.
> That bundles (I have not checked other versions) missing the APIs -
> they contain only the implementation. So I have to create a splitted
> compendium myself to get them working in Karaf.
The correct way is to work with feature dependencies, e.g.
(in the \src\main\feature\feature.xml)
Than the resolver will be able to resolve the missing dependencies. However
from my experience setting the *prerequisite* property to *true *will lead
to various build errors. (Don't know if you
14 matches
Mail list logo