Mohammad, things changed slightly in karaf 4.
Check this page: http://aries.apache.org/modules/jpaproject.html.
--
View this message in context:
http://karaf.922171.n3.nabble.com/Bundle-is-waiting-for-namespace-handlers-http-aries-apache-org-xmlns-jpa-v1-0-0-tp4042275p4042371.html
Sent from t
One-by-one, I get three interesting things.
1: I need to install the first few features in an unexpected order due
to a mistake I'll correct.
2: Karaf 'reboots' after I install the DS feature, but that might be
because I didn't actually install scr.
3: As soon as I install the last feature, I get
That's not a reboot, it's just a restart of the shell, so one of your
bundles you installed does
trigger a restart of the shell bundle.
regards, Achim
2015-09-07 13:54 GMT+02:00 Benson Margulies :
> One-by-one, I get three interesting things.
>
> 1: I need to install the first few features in a
So I fixed my dependency order on bundles, and pretty much reproduced
the same set of stuff.
I have one more thing to try, which is to put the cfg files for my
services into place.
karaf@root()> feature:repo-add
file:/Users/benson/.m2/repository/org/apache/cxf/karaf/apache-cxf/3.1.2/apache-cxf-3.
Ok, so let's try to narrow this down a bit.
At least concerning the SCR feature I'd say it's most likely due to an
dependency on the eventadmin feature, which is know to cause a "refresh" on
the shell features.
Therefore maybe an early eventadmin feature install could make this one
disappear.
For
On Mon, Sep 7, 2015 at 8:14 AM, Achim Nierbeck wrote:
> Ok, so let's try to narrow this down a bit.
> At least concerning the SCR feature I'd say it's most likely due to an
> dependency on the eventadmin feature, which is know to cause a "refresh" on
> the shell features.
> Therefore maybe an earl
frontloading eventadmin did not stop the shell from restarting or all
the backtraces about, apparently, missing pieces of blueprint.
In an effort to narrow this down, I installed only the features needed
to get to the last two (the DS feature and the 'null pointer feature')
-- that eliminated thre
If installing the scr feature triggers to refresh the cxf feature, it must
be one of the scr bundles contained.
Most likely a might be able to sole that
for the scr feature.
regards, Achim
2015-09-07 14:41 GMT+02:00 Benson Margulies :
> frontloading eventadmin did not stop the shell from
David, I note that the use of an @Requirement leads to a
Require-Capability in the manifest. In one case, I need to consume a
service which is registered by a boring old Activator class in a
bundle I do not control, and which does not have the corresponding
Provide-Capability. I haven't seen a wiri
The felix-resolver does actually look for those Require-Capabilities and
throws an error if they can't be met.
Now karaf uses this resolver to resolve all features, and therefore will
run into the same issue when installing a feature as installing a bundle.
regards, Achim
2015-09-07 15:04 GMT+02
On Mon, Sep 7, 2015 at 8:48 AM, Achim Nierbeck wrote:
> If installing the scr feature triggers to refresh the cxf feature, it must
> be one of the scr bundles contained.
> Most likely a might be able to sole that for
> the scr feature.
Achim, did you mean my feature that uses DS or the stoc
Achim and David,
I am not currently using the most recent felix resolver; that requires
building the trunk of Karaf with a patch.
Over on the Karaf list, I'm pestering Achim with the following situation:
I have, now, a working version of my system which is 100% blueprint.
(I did solve the proble
As I already said in the other thread,
make sure you don't provide the compendium jar it'll colide with a bunch of
other jars already providing the
needed packages ...
regards, Achim
2015-09-07 15:09 GMT+02:00 Benson Margulies :
> On Mon, Sep 7, 2015 at 8:48 AM, Achim Nierbeck
> wrote:
> > If
hmm, must have overseen that sentence:
The onl difference in
> bundle inventory from blueprint to DS is the addition of the
> compendium jar, which is not even loaded by loading up CXF.
actually it's no good idea to include that, and afaik all of the felix
bundles already provide all of the nee
Oh ... and use the scr feature it's known to work with Karaf.
regards, Achim
2015-09-07 15:26 GMT+02:00 Achim Nierbeck :
> As I already said in the other thread,
> make sure you don't provide the compendium jar it'll colide with a bunch
> of other jars already providing the
> needed packages ...
On Mon, Sep 7, 2015 at 9:25 AM, Achim Nierbeck wrote:
> hmm, must have overseen that sentence:
>
>> The onl difference in
>> bundle inventory from blueprint to DS is the addition of the
>> compendium jar, which is not even loaded by loading up CXF.
>
>
> actually it's no good idea to include that
On Mon, Sep 7, 2015 at 9:28 AM, Benson Margulies wrote:
> On Mon, Sep 7, 2015 at 9:25 AM, Achim Nierbeck
> wrote:
>> hmm, must have overseen that sentence:
>>
>>> The onl difference in
>>> bundle inventory from blueprint to DS is the addition of the
>>> compendium jar, which is not even loaded
When you figure out how to add providers and services to cxf without
blueprint please follow up. It would be helpful to me as well.
Thanks for all your great questions,
David
On 2015-09-07 09:31, Benson Margulies wrote:
> On Mon, Sep 7, 2015 at 9:28 AM, Benson Margulies wrote:
> On Mon,
I got it with a ton of help from other people on the felix list. The
CXF part is trivial.
1: Make a component with no services:
@Component(configurationPid = "com.basistech.ws.worker",
configurationPolicy = ConfigurationPolicy.REQUIRE,
/* No services; we're here to register ourself wi
19 matches
Mail list logo
