Re: How do I resolve resolution problems in Karaf

2016-09-20 Thread Christian Schneider
The problem is that your example needs an implementation of the dto 
support but you installed the api bundle instead which is not suitable 
for runtime.


On 20.09.2016 13:45, t...@quarendon.net wrote:

I'm really struggling to get my bundles installed in Karaf, so I'd appreciate
some hints on how to diagnose some issues. I'm trying to do a feature:install of
a features.xml file I've written to install my bundles.
My latest is:

missing requirement osgi.wiring.package;
filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.0)(!(version>=2.0.0)))"
[caused by: Unable to resolve osgi.enroute.base.api [62](R 62.0): missing
requirement [osgi.enroute.base.api [62](R 62.0)] osgi.unresolvable;
(&(must.not.resolve=*)(!(must.not.resolve=*)))]]]
The last part (&(must.not.resolve=*)(!(must.not.resolve=*)) is a special 
trick the new api bundles use to make sure they can not be installed. 
You should only use the base api at compile time. For deployment use the 
bundle with the dto implementation. I am not sure which bundle this is 
but the enroute experts can tell you this.
Btw. The same is true for the OSGi spec bundles (core, compendium and 
enterprise).


Christian

My interpretation of this is that I've got conflicting versions of something. I
have no idea what, nor to figure out what the cause is.

Up to now I've always just been using bndtools in eclipse (and the bundles I'm
installing all work fine there), my first experience of Karaf was yesterday, so
beyond what I've read in the docs, I know nothing about what useful commands
there might be to help me diagnose. I don't even know how I would list what I've
currently got installed that might satisfy osgi.enroute.dto.api or
osgi.enroute.base.api.

Any hints would be much appreciated.
This seems to be extraordinarily more complicated that "resolve" in bndtools, or
am I being naive?

Thanks.



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com



Re: scr:details command

2016-09-20 Thread Guillaume Nodet
Could you provide the full command output please ?

2016-09-20 18:13 GMT+02:00 Leschke, Scott :

> *This is the Karaf scr:details command.  It also says that the reference
> is mandatory (Optional : mandatory) and scr:info says Cardinality: 1..1.*
>
>
>
> *So I guess I’m still at how a mandatory reference be unbound but still be
> satisfied?  Hmmm.*
>
>
>
> *From:* David Jencks [mailto:david.a.jen...@gmail.com]
> *Sent:* Tuesday, September 20, 2016 11:05 AM
> *To:* user@karaf.apache.org
> *Subject:* Re: scr:details command
>
>
>
> either
>
> - minimum cardinality 0, so it’s always satisfied
>
> - the component is not satisfied for some other reason so nothing is bound
> to any reference.
>
>
>
> I think this is the karaf scr command so I might be wrong about the
> meaning.
>
>
>
> david jencks
>
>
>
> On Sep 20, 2016, at 8:33 AM, Leschke, Scott  wrote:
>
>
>
> I’m confused. What does it mean if scr:details says:
>
>
>
> State   : satisfied
>
> Service Reference : No Services bound
>
>
>
> How can a reference be satisfied if it’s not bound?
>
>
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


RE: scr:details command

2016-09-20 Thread Leschke, Scott
This is the Karaf scr:details command.  It also says that the reference is 
mandatory (Optional : mandatory) and scr:info says Cardinality: 1..1.

So I guess I’m still at how a mandatory reference be unbound but still be 
satisfied?  Hmmm.

From: David Jencks [mailto:david.a.jen...@gmail.com]
Sent: Tuesday, September 20, 2016 11:05 AM
To: user@karaf.apache.org
Subject: Re: scr:details command

either
- minimum cardinality 0, so it’s always satisfied
- the component is not satisfied for some other reason so nothing is bound to 
any reference.

I think this is the karaf scr command so I might be wrong about the meaning.

david jencks

On Sep 20, 2016, at 8:33 AM, Leschke, Scott 
> wrote:

I’m confused. What does it mean if scr:details says:

State   : satisfied
Service Reference : No Services bound

How can a reference be satisfied if it’s not bound?



Re: scr:details command

2016-09-20 Thread David Jencks
either
- minimum cardinality 0, so it’s always satisfied
- the component is not satisfied for some other reason so nothing is bound to 
any reference.

I think this is the karaf scr command so I might be wrong about the meaning.

david jencks

> On Sep 20, 2016, at 8:33 AM, Leschke, Scott  wrote:
> 
> I’m confused. What does it mean if scr:details says:
>  
> State   : satisfied
> Service Reference : No Services bound
>  
> How can a reference be satisfied if it’s not bound?



scr:details command

2016-09-20 Thread Leschke, Scott
I'm confused. What does it mean if scr:details says:

State   : satisfied
Service Reference : No Services bound

How can a reference be satisfied if it's not bound?


HBase Client Feature ClassNotFoundException

2016-09-20 Thread Alex Soto
Hi,

Have anybody managed to deploy HBase client libraries as a Karaf Feature?

I am following advice from this blog post 
http://canellos6.rssing.com/browser.php?indx=39187173=1=13 
.
Karaf starts normally, but at runtime,  I am getting various class not found 
errors, for example:

java.lang.NoClassDefFoundError: org/apache/htrace/Trace

Best regards,
Alex soto





Re: Resolution problem with osgi.enroute.dto.api

2016-09-20 Thread Guillaume Nodet
In order to use a R5 repository, you can do the following.


http://karaf.apache.org/xmlns/features/v1.4.0; name="test">

https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/index.xml



osgi.wiring.package;filter:="((osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.0)(!(version>=2.0.0)))"




However, using this very simple file leads to the following:


*karaf*@root()> feature:install --verbose --simulate test

Adding features: test/[0,0.0.0]

Changes to perform:

  Region: root

Bundles to install:


https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/org.apache.felix.log/org.apache.felix.log-1.0.1.jar


https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/org.apache.felix.scr/org.apache.felix.scr-2.0.0.jar


https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/org.eclipse.osgi/org.eclipse.osgi-3.10.100.jar


https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/org.knopflerfish.bundle.useradmin/org.knopflerfish.bundle.useradmin-4.1.1.jar


https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/osgi.enroute.dtos.bndlib.provider/osgi.enroute.dtos.bndlib.provider-1.0.0.jar


https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/osgi.promise/osgi.promise-6.0.0.jar

But I don't guarantee the results... nor its usability, it really depends
on the content of the index.xml.

Guillaume


2016-09-20 15:19 GMT+02:00 :

> I'm tracking down a rather odd problem trying to deploy a bundle into
> Karaf. The
> issue appears to be with the osgi.enroute.dto.api package.
>
> I'm getting this resolution error from Karaf:
>
> missing requirement: osgi.wiring.package;
> filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(
> version>=1.0.0)(!(version>=2.0.0)))"
>
> So I don't have anything that provides the osgi.enroute.dto.api package.
>
> I have the Karaf obr festure installed, and it's set up to point to
> https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/
> cnf/distro/index.xml
>
> So I *think* it ought to just find whatever it needs by just looking in
> that
> OBR. Nice.
>
> Looking at the runbundles list in the bndrun file I have, it shows
> "osgi.enroute.dto.bndlib.provider". At a guess this is where bndtools has
> resolved that capability. Indeed, if I look at the MANIFEST for that jar,
> I see
>
> Export-Package: osgi.enroute.dto.api;version="1.0.0"
>
> If I use Karaf to list the information about that JAR though, it shows:
> Requires:package:(&(package=osgi.enroute.dto.api)(version>
> =1.0.0)(!(version>=1.1.0)))
> Karaf is just showing the information in the
> https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/
> cnf/distro/index.xml
> file here.
>
> So, on the one hand, the osgi.enroute.dto.bndlib.provider.jar file says it
> exports the package, but on the other hand the OBR index says that it has a
> requirement on that package.
>
> On the face of it, this seems like a contradiction. Indeed if I install
> that
> bundle into Karaf, it complains of:
> Unsatisfied Requirements:
> [osgi.enroute.dto.bndlib.provider [60](R 60.0)] osgi.wiring.package;
> (&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.
> 0)(!(version>=1.1.0)))
>
> Equally if I create a very simple bundle that just has:
>@Reference private osgi.enroute.dto.api.DTOs dtos;
>
> I don't seem to be able to deploy it within Karaf, bundle:diag shows:
>
> Unsatisfied Requirements:
> [simple.dtousage [63](R 63.0)] osgi.wiring.package;
> (&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.
> 0)(!(version>=2.0.0)))
> [simple.dtousage [63](R 63.0)] osgi.service;
> (objectClass=osgi.enroute.dto.api.DTOs)
>
>
> Is this an issue with the bundle? Or the bnd index? Or with karaf?
> Or am I misinterpreting?
>
> Thanks.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


Re: Resolution problem with osgi.enroute.dto.api

2016-09-20 Thread David Daniel
API bundles are generally marked compile only and should not be deployed at
runtime

On Sep 20, 2016 9:19 AM,  wrote:

> I'm tracking down a rather odd problem trying to deploy a bundle into
> Karaf. The
> issue appears to be with the osgi.enroute.dto.api package.
>
> I'm getting this resolution error from Karaf:
>
> missing requirement: osgi.wiring.package;
> filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(
> version>=1.0.0)(!(version>=2.0.0)))"
>
> So I don't have anything that provides the osgi.enroute.dto.api package.
>
> I have the Karaf obr festure installed, and it's set up to point to
> https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/
> cnf/distro/index.xml
>
> So I *think* it ought to just find whatever it needs by just looking in
> that
> OBR. Nice.
>
> Looking at the runbundles list in the bndrun file I have, it shows
> "osgi.enroute.dto.bndlib.provider". At a guess this is where bndtools has
> resolved that capability. Indeed, if I look at the MANIFEST for that jar,
> I see
>
> Export-Package: osgi.enroute.dto.api;version="1.0.0"
>
> If I use Karaf to list the information about that JAR though, it shows:
> Requires:package:(&(package=osgi.enroute.dto.api)(version>
> =1.0.0)(!(version>=1.1.0)))
> Karaf is just showing the information in the
> https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/
> cnf/distro/index.xml
> file here.
>
> So, on the one hand, the osgi.enroute.dto.bndlib.provider.jar file says it
> exports the package, but on the other hand the OBR index says that it has a
> requirement on that package.
>
> On the face of it, this seems like a contradiction. Indeed if I install
> that
> bundle into Karaf, it complains of:
> Unsatisfied Requirements:
> [osgi.enroute.dto.bndlib.provider [60](R 60.0)] osgi.wiring.package;
> (&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.
> 0)(!(version>=1.1.0)))
>
> Equally if I create a very simple bundle that just has:
>@Reference private osgi.enroute.dto.api.DTOs dtos;
>
> I don't seem to be able to deploy it within Karaf, bundle:diag shows:
>
> Unsatisfied Requirements:
> [simple.dtousage [63](R 63.0)] osgi.wiring.package;
> (&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.
> 0)(!(version>=2.0.0)))
> [simple.dtousage [63](R 63.0)] osgi.service;
> (objectClass=osgi.enroute.dto.api.DTOs)
>
>
> Is this an issue with the bundle? Or the bnd index? Or with karaf?
> Or am I misinterpreting?
>
> Thanks.
>


Resolution problem with osgi.enroute.dto.api

2016-09-20 Thread tom
I'm tracking down a rather odd problem trying to deploy a bundle into Karaf. The
issue appears to be with the osgi.enroute.dto.api package.

I'm getting this resolution error from Karaf:

missing requirement: osgi.wiring.package;
filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.0)(!(version>=2.0.0)))"

So I don't have anything that provides the osgi.enroute.dto.api package.

I have the Karaf obr festure installed, and it's set up to point to 
https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/index.xml

So I *think* it ought to just find whatever it needs by just looking in that
OBR. Nice.

Looking at the runbundles list in the bndrun file I have, it shows
"osgi.enroute.dto.bndlib.provider". At a guess this is where bndtools has
resolved that capability. Indeed, if I look at the MANIFEST for that jar, I see

Export-Package: osgi.enroute.dto.api;version="1.0.0"

If I use Karaf to list the information about that JAR though, it shows:
Requires:package:(&(package=osgi.enroute.dto.api)(version>=1.0.0)(!(version>=1.1.0)))
Karaf is just showing the information in the
https://raw.githubusercontent.com/osgi/osgi.enroute/v1.0.0/cnf/distro/index.xml
file here.

So, on the one hand, the osgi.enroute.dto.bndlib.provider.jar file says it
exports the package, but on the other hand the OBR index says that it has a
requirement on that package.

On the face of it, this seems like a contradiction. Indeed if I install that
bundle into Karaf, it complains of:
Unsatisfied Requirements:
[osgi.enroute.dto.bndlib.provider [60](R 60.0)] osgi.wiring.package;
(&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.0)(!(version>=1.1.0)))

Equally if I create a very simple bundle that just has:
   @Reference private osgi.enroute.dto.api.DTOs dtos;

I don't seem to be able to deploy it within Karaf, bundle:diag shows:

Unsatisfied Requirements:
[simple.dtousage [63](R 63.0)] osgi.wiring.package;
(&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.0)(!(version>=2.0.0)))
[simple.dtousage [63](R 63.0)] osgi.service;
(objectClass=osgi.enroute.dto.api.DTOs)


Is this an issue with the bundle? Or the bnd index? Or with karaf? 
Or am I misinterpreting? 

Thanks.


Re: Creating features.xml files

2016-09-20 Thread Benson Margulies
On Tue, Sep 20, 2016 at 8:19 AM,   wrote:
>
>> On 20 September 2016 at 12:52 Benson Margulies  wrote:
>>
>>
>> I build all my features with the karaf-maven-plugin.
>>
>
> I don't use Maven, I use eclipse and bndtools, hence gradle as my build
> environment. Since I didn't have to do anything at all to get the gradle 
> command
> line build set up, it was just generated for me, I'm reluctant to start 
> manually
> setting up a maven build environment. Ideally I want to just generate a 
> feature
> xml file out of the bndtools environment somehow.

In the simple case, a feature is just a collection of the maven
repository coordinates of a set of bundles that want to travel around
together. The Maven tooling creates these by waking the Maven
dependency graph. It doesn't always work perfectly, since many OSGi
bundles in Maven Central have unhelpful dependencies declared.  I
don't have any experience in gradle plugin creation, so I can't advise
as to the difficulty level here of stirring up something.


Re: How do I resolve resolution problems in Karaf

2016-09-20 Thread Benson Margulies
Tom, if you drop them _as bundles_, karaf works like any other osgi
container -- you have to drop in all the bundles you need. You might
need to set serviceRequirements to disable in
org.apache.karaf.features.cfg if your bundle manifests are not fully
informative on the topic of service capabilities.

If you drop them _as features_, you need to make correct features, and
that's painful if you can't get help from tooling.

On Tue, Sep 20, 2016 at 8:22 AM,   wrote:
> OK, that's really useful, I'll follow some of that up.
>
> As usual I went into this with the naive assumption that since Karaf was an 
> OSGi
> container, I would just be able to drop my bundles in and it would all just
> work. Sadly things aren't quite as simple.
>
>> On 20 September 2016 at 13:19 David Daniel 
>> wrote:
>>
>>
>> Tom integrating karaf development and bndtools development has been tricky
>> but it is getting better.  Karaf development is centered around Mavens
>> build process while bndtools is centered around a custom workspace in cnf.
>> This release bndtools will be supporting maven and you can see the latest
>> post here https://groups.google.com/forum/#!topic/bndtools-users/VcQ2rsb--Pk
>> You can see how to include karaf features in a bndrun file in Christians
>> examples here https://github.com/cschneider/osgi-chat and the new cxf
>> example.  What I do in my build is I include a features.bnd file where I
>> map karaf features to bndrun runrequires/runbundles statements and I
>> include that in my bndrun files.  I have to separately maintain my
>> features.bnd and my features.xml.  I do this so I can build both a single
>> jar deployable and run in karaf and pax-exam.  Although the mixing of the
>> two build processes is hard it is becoming easier by the day.
>>
>> On Tue, Sep 20, 2016 at 7:45 AM,  wrote:
>>
>> > I'm really struggling to get my bundles installed in Karaf, so I'd
>> > appreciate
>> > some hints on how to diagnose some issues. I'm trying to do a
>> > feature:install of
>> > a features.xml file I've written to install my bundles.
>> > My latest is:
>> >
>> > missing requirement osgi.wiring.package;
>> > filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(
>> > version>=1.0.0)(!(version>=2.0.0)))"
>> > [caused by: Unable to resolve osgi.enroute.base.api [62](R 62.0): missing
>> > requirement [osgi.enroute.base.api [62](R 62.0)] osgi.unresolvable;
>> > (&(must.not.resolve=*)(!(must.not.resolve=*)))]]]
>> >
>> > My interpretation of this is that I've got conflicting versions of
>> > something. I
>> > have no idea what, nor to figure out what the cause is.
>> >
>> > Up to now I've always just been using bndtools in eclipse (and the bundles
>> > I'm
>> > installing all work fine there), my first experience of Karaf was
>> > yesterday, so
>> > beyond what I've read in the docs, I know nothing about what useful
>> > commands
>> > there might be to help me diagnose. I don't even know how I would list
>> > what I've
>> > currently got installed that might satisfy osgi.enroute.dto.api or
>> > osgi.enroute.base.api.
>> >
>> > Any hints would be much appreciated.
>> > This seems to be extraordinarily more complicated that "resolve" in
>> > bndtools, or
>> > am I being naive?
>> >
>> > Thanks.
>> >


Re: Creating features.xml files

2016-09-20 Thread tom

> On 20 September 2016 at 12:52 Benson Margulies  wrote:
> 
> 
> I build all my features with the karaf-maven-plugin.
> 

I don't use Maven, I use eclipse and bndtools, hence gradle as my build
environment. Since I didn't have to do anything at all to get the gradle command
line build set up, it was just generated for me, I'm reluctant to start manually
setting up a maven build environment. Ideally I want to just generate a feature
xml file out of the bndtools environment somehow.


Re: How do I resolve resolution problems in Karaf

2016-09-20 Thread David Daniel
Tom integrating karaf development and bndtools development has been tricky
but it is getting better.  Karaf development is centered around Mavens
build process while bndtools is centered around a custom workspace in cnf.
This release bndtools will be supporting maven and you can see the latest
post here https://groups.google.com/forum/#!topic/bndtools-users/VcQ2rsb--Pk
You can see how to include karaf features in a bndrun file in Christians
examples here https://github.com/cschneider/osgi-chat and the new cxf
example.  What I do in my build is I include a features.bnd file where I
map karaf features to bndrun runrequires/runbundles statements and I
include that in my bndrun files.  I have to separately maintain my
features.bnd and my features.xml.  I do this so I can build both a single
jar deployable and run in karaf and pax-exam.  Although the mixing of the
two build processes is hard it is becoming easier by the day.

On Tue, Sep 20, 2016 at 7:45 AM,  wrote:

> I'm really struggling to get my bundles installed in Karaf, so I'd
> appreciate
> some hints on how to diagnose some issues. I'm trying to do a
> feature:install of
> a features.xml file I've written to install my bundles.
> My latest is:
>
> missing requirement osgi.wiring.package;
> filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(
> version>=1.0.0)(!(version>=2.0.0)))"
> [caused by: Unable to resolve osgi.enroute.base.api [62](R 62.0): missing
> requirement [osgi.enroute.base.api [62](R 62.0)] osgi.unresolvable;
> (&(must.not.resolve=*)(!(must.not.resolve=*)))]]]
>
> My interpretation of this is that I've got conflicting versions of
> something. I
> have no idea what, nor to figure out what the cause is.
>
> Up to now I've always just been using bndtools in eclipse (and the bundles
> I'm
> installing all work fine there), my first experience of Karaf was
> yesterday, so
> beyond what I've read in the docs, I know nothing about what useful
> commands
> there might be to help me diagnose. I don't even know how I would list
> what I've
> currently got installed that might satisfy osgi.enroute.dto.api or
> osgi.enroute.base.api.
>
> Any hints would be much appreciated.
> This seems to be extraordinarily more complicated that "resolve" in
> bndtools, or
> am I being naive?
>
> Thanks.
>


Re: How do I resolve resolution problems in Karaf

2016-09-20 Thread Guillaume Nodet
I'm not sure exactly how the "resolve" in bndtools work, but in Karaf, the
resolution
is done on all constraints, including generic capabilities / requirements,
and
including osgi services.

In this very case, you have a bundle that requires the osgi.unresolvable
capability.
Why did you add this requirement on your bundle ?
Try removing it from your bundle manifest.
Also, I'm not sure how that would work in the OSGi framework, as the OSGi
framework
also resolve generic capabilities and requirements.  The only different is
those
flagged with effective:="active" which are ignored by the framework
resolver.
There are some flags in Karaf to disable them too if needed.

Guillaume


2016-09-20 13:45 GMT+02:00 :

> I'm really struggling to get my bundles installed in Karaf, so I'd
> appreciate
> some hints on how to diagnose some issues. I'm trying to do a
> feature:install of
> a features.xml file I've written to install my bundles.
> My latest is:
>
> missing requirement osgi.wiring.package;
> filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(
> version>=1.0.0)(!(version>=2.0.0)))"
> [caused by: Unable to resolve osgi.enroute.base.api [62](R 62.0): missing
> requirement [osgi.enroute.base.api [62](R 62.0)] osgi.unresolvable;
> (&(must.not.resolve=*)(!(must.not.resolve=*)))]]]
>
> My interpretation of this is that I've got conflicting versions of
> something. I
> have no idea what, nor to figure out what the cause is.
>
> Up to now I've always just been using bndtools in eclipse (and the bundles
> I'm
> installing all work fine there), my first experience of Karaf was
> yesterday, so
> beyond what I've read in the docs, I know nothing about what useful
> commands
> there might be to help me diagnose. I don't even know how I would list
> what I've
> currently got installed that might satisfy osgi.enroute.dto.api or
> osgi.enroute.base.api.
>
> Any hints would be much appreciated.
> This seems to be extraordinarily more complicated that "resolve" in
> bndtools, or
> am I being naive?
>
> Thanks.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


Re: Creating features.xml files

2016-09-20 Thread Benson Margulies
I build all my features with the karaf-maven-plugin.

On Sep 20, 2016 3:12 AM,  wrote:

> Up until now I've been developing code using bndtools in eclipse, writing
> bndrun
> files, resolving them, and running my application that way. The resolution
> step
> resolves all the requirements from the set of OBR repositories. All very
> easy
> (well, it is now, once I got over the learning curve :-) )
>
> I'm now trying to deploy those same applications into karaf, and so
> wanting to
> write feature repository XML files the the same thing. So naively I seem
> to want
> to create a feature XML file that is the same as my resolved bndrun file.
> Is
> there an easy way to do this? Is there an easy way to write feature
> repository
> files, or do I have to maintain those separately? It also feels that the
> way I
> have to write the files depends on how I'm deploying. So if I want to
> deploy
> from a maven repository, my bundle references need to be in one form, but
> If I'm
> deploying directly from disk, my bundle references have to be in another
> form.
>
> Is there an easy way to manage the feature xml files?
>
> Thanks.
>


How do I resolve resolution problems in Karaf

2016-09-20 Thread tom
I'm really struggling to get my bundles installed in Karaf, so I'd appreciate
some hints on how to diagnose some issues. I'm trying to do a feature:install of
a features.xml file I've written to install my bundles. 
My latest is:

missing requirement osgi.wiring.package;
filter:="(&(osgi.wiring.package=osgi.enroute.dto.api)(version>=1.0.0)(!(version>=2.0.0)))"
[caused by: Unable to resolve osgi.enroute.base.api [62](R 62.0): missing
requirement [osgi.enroute.base.api [62](R 62.0)] osgi.unresolvable;
(&(must.not.resolve=*)(!(must.not.resolve=*)))]]]

My interpretation of this is that I've got conflicting versions of something. I
have no idea what, nor to figure out what the cause is.

Up to now I've always just been using bndtools in eclipse (and the bundles I'm
installing all work fine there), my first experience of Karaf was yesterday, so
beyond what I've read in the docs, I know nothing about what useful commands
there might be to help me diagnose. I don't even know how I would list what I've
currently got installed that might satisfy osgi.enroute.dto.api or
osgi.enroute.base.api.

Any hints would be much appreciated.
This seems to be extraordinarily more complicated that "resolve" in bndtools, or
am I being naive?

Thanks.


Re: OSGi Log Service?

2016-09-20 Thread Guillaume Nodet
The service is provided by pax-logging.
But I suspect the manifest is missing the capability for this service.
Try adding the following instruction in your bundle

  <_removeheaders>Require-Capability

Cheers,
Guillaume Nodet

2016-09-20 12:49 GMT+02:00 :

> According to the documentation, the OSGi Log service is supported.
>
> I'm trying to install a bundle that uses it, and I get:
>
> missing requirement [bundleid/1.0.0.201609201024] osgi.service;
> filter:="(objectClass=org.osgi.service.log.LogService)";
> effective:=active]]
>
> My use is with DS, so:
>
> @Reference
> private LogService log;
>
>
> To me that says that there isn't an implementation of the LogService
> object that
> it can find to resolve.
>
> Am I misinterpreting?
>
> (Karaf 4.0.6).
>
> Thanks.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


Re: OSGi Log Service?

2016-09-20 Thread jerome
Hi Tom
Did you install any feature providing the LogService? Felix Log service is one 
of the possible implementations
You may précise in your code the optional attributs while defining the 
injection.
Hth
Jérôme

Envoyé de mon smartphone BlackBerry 10 sur le réseau Orange.
  Message d'origine  
De: t...@quarendon.net
Envoyé: mardi 20 septembre 2016 12:49
À: user@karaf.apache.org
Répondre à: user@karaf.apache.org
Objet: OSGi Log Service?

According to the documentation, the OSGi Log service is supported.

I'm trying to install a bundle that uses it, and I get:

missing requirement [bundleid/1.0.0.201609201024] osgi.service;
filter:="(objectClass=org.osgi.service.log.LogService)"; effective:=active]]

My use is with DS, so:

@Reference
private LogService log;


To me that says that there isn't an implementation of the LogService object that
it can find to resolve. 

Am I misinterpreting?

(Karaf 4.0.6).

Thanks.


OSGi Log Service?

2016-09-20 Thread tom
According to the documentation, the OSGi Log service is supported.

I'm trying to install a bundle that uses it, and I get:

missing requirement [bundleid/1.0.0.201609201024] osgi.service;
filter:="(objectClass=org.osgi.service.log.LogService)"; effective:=active]]

My use is with DS, so:

@Reference
private LogService log;


To me that says that there isn't an implementation of the LogService object that
it can find to resolve. 

Am I misinterpreting?

(Karaf 4.0.6).

Thanks.


Re: Deploying an application from jenkins for test

2016-09-20 Thread tom
> you can use Pax Exam[1] for that and start Karaf embedded, this will give
> you a clean state for every run.

Initially I want to do it for testing, but I then want to deploy a "snapshot"
and "release" version of the actual application for general internal demo use. I
currently already have an integration test suite, but what it doesn't test is
the deployment into karaf, so I want to deploy it for testing in a way that is
as close to the real thing as possible.

> The other way would be to have a Karaf with Jolokia running and deploy via
> JMX, I once created a sample for that [2].

As I say, my question was really one of what the transport is for the bundles.
One way of the other I invoke the equivalent of "feature:add-repo", then
"feature:install", my question is what are the URLs, where does karaf actually
pull stuff from. To use mvn repositories I need to find a way of turning off the
caching, which so far I've failed to do. Pushing the files on to the remote
machine using SCP and then addressing them with "file:///" URLs seems another
way, but it seems over complicated to push them. Addressing the artifacts in
jenkins directly is another way, but it seems like I'm going to have to write
something bespoke to create a feature repository with the correct URLs in from
some kind of template (substituting the correct build number in all of the
URLs).

Just hoping there might be a known best way to do this kind of thing, save me
figuring it out!

Thanks.


Creating features.xml files

2016-09-20 Thread tom
Up until now I've been developing code using bndtools in eclipse, writing bndrun
files, resolving them, and running my application that way. The resolution step
resolves all the requirements from the set of OBR repositories. All very easy
(well, it is now, once I got over the learning curve :-) )

I'm now trying to deploy those same applications into karaf, and so wanting to
write feature repository XML files the the same thing. So naively I seem to want
to create a feature XML file that is the same as my resolved bndrun file. Is
there an easy way to do this? Is there an easy way to write feature repository
files, or do I have to maintain those separately? It also feels that the way I
have to write the files depends on how I'm deploying. So if I want to deploy
from a maven repository, my bundle references need to be in one form, but If I'm
deploying directly from disk, my bundle references have to be in another form. 

Is there an easy way to manage the feature xml files?

Thanks.


Re: Deploying an application from jenkins for test

2016-09-20 Thread Achim Nierbeck
Hi,

you can use Pax Exam[1] for that and start Karaf embedded, this will give
you a clean state for every run.
The other way would be to have a Karaf with Jolokia running and deploy via
JMX, I once created a sample for that [2].

regards, Achim

[1] - https://ops4j1.jira.com/wiki/display/PAXEXAM4/Pax+Exam
[2] -
https://github.com/ANierbeck/Karaf-Microservices-Tooling/tree/master/karaf-deployer-maven-plugin

2016-09-20 9:05 GMT+02:00 :

> What's the best way of deploying an application from a CI build such as
> Jenkins,
> into Karaf, for the purposes of testing?
>
> I was hoping to set something up so that I have a jenkins job that builds
> my
> application and then deploys the built application to a test instance on
> karaf.
> The karaf would be running on a separate machine, so I would most likely
> write a
> simple piece of java, either as an ANT task or similar that uses the JMX
> management bean interface to interact with karaf (seems more reliable than
> trying to script the shell interface and detect errors).
>
> My question really is what the best was of transferring things was.
> Naively I
> assumed that I would publish the artifacts into artifactory as snapshots
> and
> then pull them from there using mvn: URLs, but maybe I just don't know
> enough
> about how maven repositories work, as I'm getting into difficulties with
> the
> artifacts being cached, so that what is deployed is what has just been
> built.
>
> I could probably pull them directly from jenkins using the
> "lastSuccessfulBuild/artifacts" URLs, and maybe that the best way?
>
> Any thoughts?
> Thanks.
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master


Re: Karaf, gogo shell?

2016-09-20 Thread tom
I started using Karaf yesterday. Version 4.0.6.

Not aware of shell-compat. What does it do? I can't see it mentioned in any
documentation. 

Naively tried installing it. Doesn't seem to change my ability to run a gogo
shell command that I can see?


> On 19 September 2016 at 17:08 Benson Margulies  wrote:
> 
> 
> What version of karaf?
> 
> Did you install the shell-compat feature, which is required for gogo commands?
> 
> 
> On Mon, Sep 19, 2016 at 12:06 PM,   wrote:
> > I'm trying to get started with Karaf, and am having a few issues.
> >
> > I have created a simple OSGi enroute project using bndtools in eclipse. I
> > have
> > created a feature.xml file for it and have installed it in karaf. So far so
> > good.
> >
> > The default project that bndtools generates includes a gogo command. It's
> > just a
> > "hello world".
> >
> > When I run this within eclipse under the normal OSGi environment there, I
> > can
> > run my command from the gogo shell.
> >
> > Naively I tried doing the same from within the karaf shell. No joy.
> >
> > I feel I'm back to square one in terms of diagnostics. Tools I used to rely
> > on
> > like "lb", "inspect capabilities" and so on don't exist as far as I can
> > tell, so
> > I can't really tell what might be going wrong.
> > "bundle:diag" shows no unsatisfied requirements though.
> >
> > Should I expect such a command to work?
> >
> > Thanks.