Getting the maven plugin to fill in versions of bundles

[Benson Margulies]

Folks,

I had this idea that I could set up a template in a
src/main/feature.xml and have the karaf-maven-plugin fill in the
versions. This idea is suggested, but not precisely promised, by the
documentation.

Something like:

mvn:org.ops4j.pax.logging/pax-logging-api/

and the version would appear. I know I can put in a property
reference, but I want the version number as resolved by maven from the
dependency graph. Is there a way that I am missing?

--benson

Re: karaf build

[Benson Margulies]

I suggest that you actually look at the RAT output file and see of
what it complains.

On Fri, Oct 14, 2016 at 8:30 AM, Christian Schneider
 wrote:
> I just ran this with no problems.
>
> git checkout karaf-4.0.7
> mvn clean install -DskipTests
>
> mvn -v
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
> 2014-12-14T18:29:23+01:00)
> Maven home: /home/cschneider/java/apache-maven-3.2.5
> Java version: 1.8.0_92, vendor: Oracle Corporation
> Java home: /home/cschneider/java/jdk1.8.0_92/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.8.0-22-generic", arch: "amd64", family: "unix"
>
>
> So you can experiment with a maven 3.2.
> You should also check that you have the jdk not jre and that it is the
> oracle one.
>
> Christian
>
>
>
> On 14.10.2016 14:09, Thomas Termin wrote:
>
> @Jean-Baptiste
> mvn clean install -DskipTests results in:
>
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 7.785 s
> [INFO] Finished at: 2016-10-14T14:06:08+02:00
> [INFO] Final Memory: 76M/383M
> [INFO]
> 
> [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.11:check
> (default) on project karaf: Too many files with unapproved license: 3 See
> RAT report in: /local/tterm/apache-karaf-4.0.7/target/karaf-4.0.7.rat ->
> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>
> @Christian
> Apache Maven 3.3.9
>
> java version "1.7.0_65"
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) Server VM (build 24.65-b04, mixed mode)
>
> and
>
> java version "1.8.0_40"
> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
> Java HotSpot(TM) Server VM (build 25.40-b25, mixed mode)
>
> Regards,
> Thomas
>
>
> On Fri, Oct 14, 2016 at 1:53 PM, Christian Schneider
>  wrote:
>>
>> What java and maven versions do you use?
>>
>> Christian
>>
>>
>> On 14.10.2016 13:47, Thomas Termin wrote:
>>>
>>> Hello,
>>>
>>> why is it not possible to build the karaf source code? If I download the
>>> src for 4.0.7 or checkout the tag and try to build karaf with mvn
>>> -Pfastinstall I always get the output below. It seems that there are missing
>>> dependencies on apache.commons. What do I wrong?
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile
>>> (default-compile) on project karaf-maven-plugin: Compilation failure:
>>> Compilation failure:
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency30Helper.java:[22,46]
>>> package org.apache.commons.lang.reflect does not exist
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency30Helper.java:[22,1]
>>> static import only from classes and interfaces
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency31Helper.java:[50,46]
>>> package org.apache.commons.lang.reflect does not exist
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency31Helper.java:[50,1]
>>> static import only from classes and interfaces
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency30Helper.java:[22,46]
>>> package org.apache.commons.lang.reflect does not exist
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency30Helper.java:[22,1]
>>> static import only from classes and interfaces
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency31Helper.java:[50,46]
>>> package org.apache.commons.lang.reflect does not exist
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency31Helper.java:[50,1]
>>> static import only from classes and interfaces
>>> [ERROR]
>>> /local/tterm/apache-karaf-4.0.7/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/utils/Dependency30Helper.java:[95,25]
>>> cannot find symbol
>>> [ERROR] symbol:   method
>>> invokeMethod(org.apache.maven.project.ProjectBuildingRequest,java.lang.String,org.sonatype.aether.RepositorySystemSession)
>>> [ERROR] location: class org.apache.karaf.tooling.utils.Dependency30Helper

Re: Scripting installation of features - Command not found: feature:repo-add (was Re: feature:repo-add -i broken in 4.0.4?)

[Benson Margulies]

Have you considered just making a karaf assembly?

On Oct 8, 2016 11:22 AM, "emets...@gmail.com"  wrote:

> Hi Guillaume,
>
> After digging a bit more, the apparent disparity between the client and the
> interactive console seems to be related to timing:
>
> bin/start && \
> bin/client -r 10 -d 5  "feature:repo-add -i
> mvn:edu.amherst.acdc/acrepo-karaf/LATEST/xml/features" && \
> sleep 20 && \
> bin/stop
>
> Adding a `sleep` before stopping the console allows the bundles to be
> started!  I assumed that `feature:repo-add -i` was blocking until
> everything
> was installed, but I was mistaken?  Or maybe calling bin/stop so quickly
> aborts the preservation of the bundle state?
>
> In any case, adding the sleep is allowing everything to come up nicely.
>
> Thanks,
> Elliot
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/feature-repo-add-i-broken-in-4-0-4-tp4046143p4048280.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>

Re: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:36 AM, Guillaume Nodet <gno...@apache.org> wrote:
>
>
> 2016-09-29 16:22 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet <gno...@apache.org>
>> wrote:
>> > Manually maintaining the feature set is not something you should do.
>> > Please raise a JIRA and attach a test case if you can produce one (an
>> > integration test for the plugin would be awesome) : that's not really
>> > supported I think.
>> > As a workaround, I would suggest you force the  rosapi-worker-flinx-sdk
>> > to
>> > be in the startup stage.
>>
>> OK, can you tell me how to do that in the configuration of the
>> karaf-maven-plugin?
>
>
>> 
>> rosapi-worker-flinx-sdk
>> 
>
>
>>
>> >
>> > You really need this dependency as a prerequisite, right ?  The only
>> > real
>> > use case is for URL handlers used inside feature definitions.  Anything
>> > related to the wiring (packages, services, etc...) does not need to be a
>> > prerequisite.
>>
>> As I tried to explain, this results from a mistake. We have a few
>> bundles with activators that try to obtain services from other
>> bundles, without properly accounting for indefinite startup order. I
>> have code changes in train to use DS properly to fix this; these
>> bundles were written some time ago when we barely understood OSGi.
>>
>> My foray into prerequisites is entirely a matter of trying to work
>> around until the DS changes are in place. I am making a small
>> experiment with start-level now since the prerequisite approach seems
>> a bit, well, fraught.
>>
>> I will try to find time to make you a test case, it does appear as if
>> it takes a somewhat complex collection of features and dependencies to
>> elicit this problem, so it might take me a while.
>>
>> I might be able to describe the situation in a way that sheds some
>> light for you in the interim:
>>
>> Feature Q declares feature R as a prerequisite.
>>
>> Feature R declares Feature S as an ordinary dependency
>> (S).
>>
>> Feature S includes a bundle that imports javax.servlet, but does not
>> include a bundle that exports javax.servlet. Instead, it normally gets
>> that package from pax-jetty, which is not declared as a feature
>> dependency at all. It's just included in the assembly.
>>
>> Maybe I should ask this question: if _all_ I need to control is
>> startup order, and not wiring order, is 'prerequisite' even what I'm
>> supposed to do?
>
>
> Definitely not.  I'm not even sure that would work during the boot because
> the bundles part of the prerequisite feature may not even start if the start
> level is too high.
> So if you're problem is start order of the bundles, use the start level on
> bundles.
>
> Fwiw, if feature S requires javax.servlet, it would be better to add that
> bundle as a xxx or have a  dependency="true">http.  There's very few valid reason why a
> feature should not be transitively closed.

I will close this thread for now (as far as I am concerned) by merely
observing that when you use the maven plugin to build your features,
there are many opportunities to fail to do this.  Thanks again for all
the help.


>
>>
>>
>> Thanks,
>>
>> benson
>>
>>
>>
>>
>>
>> >
>> >
>> > 2016-09-29 16:08 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>> >>
>> >> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré
>> >> <j...@nanthrax.net>
>> >> wrote:
>> >> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is
>> >> > all
>> >> > the
>> >> > rest.
>> >> >
>> >> > I would recommend to group all dependency features in stage1 and the
>> >> > rest in
>> >> > stage2.
>> >>
>> >> How can I do that while still using the karaf-maven-plugin to write
>> >> this file for me? Do I have to give up and manually maintain that
>> >> property?
>> >>
>> >> Would the syntax be (a,b,c,d),e,g,f?
>> >>
>> >> thanks,
>> >> benson
>> >>
>> >>
>> >>
>> >> >
>> >> > Regards
>> >> > JB
>> >> >
>> >> >
>> >> > On 09/29/2016 03:54 PM, Benson Margulies wrote:
>> >> >>

Re: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:12 AM, Guillaume Nodet <gno...@apache.org> wrote:
> Manually maintaining the feature set is not something you should do.
> Please raise a JIRA and attach a test case if you can produce one (an
> integration test for the plugin would be awesome) : that's not really
> supported I think.
> As a workaround, I would suggest you force the  rosapi-worker-flinx-sdk to
> be in the startup stage.

OK, can you tell me how to do that in the configuration of the
karaf-maven-plugin?

>
> You really need this dependency as a prerequisite, right ?  The only real
> use case is for URL handlers used inside feature definitions.  Anything
> related to the wiring (packages, services, etc...) does not need to be a
> prerequisite.

As I tried to explain, this results from a mistake. We have a few
bundles with activators that try to obtain services from other
bundles, without properly accounting for indefinite startup order. I
have code changes in train to use DS properly to fix this; these
bundles were written some time ago when we barely understood OSGi.

My foray into prerequisites is entirely a matter of trying to work
around until the DS changes are in place. I am making a small
experiment with start-level now since the prerequisite approach seems
a bit, well, fraught.

I will try to find time to make you a test case, it does appear as if
it takes a somewhat complex collection of features and dependencies to
elicit this problem, so it might take me a while.

I might be able to describe the situation in a way that sheds some
light for you in the interim:

Feature Q declares feature R as a prerequisite.

Feature R declares Feature S as an ordinary dependency (S).

Feature S includes a bundle that imports javax.servlet, but does not
include a bundle that exports javax.servlet. Instead, it normally gets
that package from pax-jetty, which is not declared as a feature
dependency at all. It's just included in the assembly.

Maybe I should ask this question: if _all_ I need to control is
startup order, and not wiring order, is 'prerequisite' even what I'm
supposed to do?

Thanks,

benson





>
>
> 2016-09-29 16:08 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>> > Actually, you are using multi-stage: stage1 is (wrap) and stage2 is all
>> > the
>> > rest.
>> >
>> > I would recommend to group all dependency features in stage1 and the
>> > rest in
>> > stage2.
>>
>> How can I do that while still using the karaf-maven-plugin to write
>> this file for me? Do I have to give up and manually maintain that
>> property?
>>
>> Would the syntax be (a,b,c,d),e,g,f?
>>
>> thanks,
>> benson
>>
>>
>>
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 09/29/2016 03:54 PM, Benson Margulies wrote:
>> >>
>> >> Hi JB,
>> >>
>> >> I let the maven plugin write org.apache.karaf.features.cfg, so I don't
>> >> know, to be honest, if I'm using multi-stage.
>> >>
>> >> _Without_ the failing prerequisites, I have the following content of
>> >> org.apache.karaf.features.cfg. I'm using the property editor feature
>> >> to turn off capability enforcement.
>> >>
>> >>
>> >> rosapi-all-sdks is just a bag of  declarations for other
>> >> features. Things break when I try to make one of them a prerequisite
>> >> of another. My problem is really to prevent the activation of a few
>> >> bundles until another bundle is safely under control, and I am hoping
>> >> for a workaround in the interim until we can really fix this with DS
>> >> in a few weeks.
>> >>
>> >>
>> >> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
>> >> #Thu Sep 29 09:49:19 EDT 2016
>> >> featuresBootAsynchronous=false
>> >> serviceRequirements=disable
>> >> featuresBoot = \
>> >> (wrap), \
>> >> log, \
>> >> rosapi-front-end-anvils-transport, \
>> >> bean-validation-support, \
>> >> rosapi-worker-common, \
>> >> ssh, \
>> >> rosapi-front-end-logstash-request-tracker, \
>> >> rosapi-front-end-service, \
>> >> aries-blueprint, \
>> >> feature, \
>> >> jaas, \
>> >> diagnostic, \
>> >> rosapi-worker-download-text-extraction-component, \
>> >> rosapi-front-end-null-request-tracker, \
>> >> bundl

Re: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:05 AM, Jean-Baptiste Onofré <j...@nanthrax.net> 
wrote:
> Actually, you are using multi-stage: stage1 is (wrap) and stage2 is all the
> rest.
>
> I would recommend to group all dependency features in stage1 and the rest in
> stage2.

How can I do that while still using the karaf-maven-plugin to write
this file for me? Do I have to give up and manually maintain that
property?

Would the syntax be (a,b,c,d),e,g,f?

thanks,
benson



>
> Regards
> JB
>
>
> On 09/29/2016 03:54 PM, Benson Margulies wrote:
>>
>> Hi JB,
>>
>> I let the maven plugin write org.apache.karaf.features.cfg, so I don't
>> know, to be honest, if I'm using multi-stage.
>>
>> _Without_ the failing prerequisites, I have the following content of
>> org.apache.karaf.features.cfg. I'm using the property editor feature
>> to turn off capability enforcement.
>>
>>
>> rosapi-all-sdks is just a bag of  declarations for other
>> features. Things break when I try to make one of them a prerequisite
>> of another. My problem is really to prevent the activation of a few
>> bundles until another bundle is safely under control, and I am hoping
>> for a workaround in the interim until we can really fix this with DS
>> in a few weeks.
>>
>>
>> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
>> #Thu Sep 29 09:49:19 EDT 2016
>> featuresBootAsynchronous=false
>> serviceRequirements=disable
>> featuresBoot = \
>> (wrap), \
>> log, \
>> rosapi-front-end-anvils-transport, \
>> bean-validation-support, \
>> rosapi-worker-common, \
>> ssh, \
>> rosapi-front-end-logstash-request-tracker, \
>> rosapi-front-end-service, \
>> aries-blueprint, \
>> feature, \
>> jaas, \
>> diagnostic, \
>> rosapi-worker-download-text-extraction-component, \
>> rosapi-front-end-null-request-tracker, \
>> bundle, \
>> rosapi-all-sdks, \
>> rosapi-front-end-local-usage-tracker, \
>> package, \
>> scr, \
>> rosapi-common, \
>> cxf-jaxrs, \
>> rosette-api, \
>> rosapi-front-end-embedded-transport, \
>> system, \
>> shell, \
>> shell-compat, \
>> config
>> featuresRepositories = \
>> mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
>> mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
>> mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
>> mvn:org.apache.karaf.features/framework/4.0.6/xml/features
>>
>>
>> On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>>
>>> Hi Benson,
>>>
>>> do you use multi-stage in featuresBoot ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 09/29/2016 03:33 PM, Benson Margulies wrote:
>>>>
>>>>
>>>> Folks,
>>>>
>>>> I build an assembly in which all the feature are boot features,
>>>> because they are all going to be used.
>>>>
>>>> When I try to make one of them a prerequisite of another, I get a
>>>> wiring error, because, apparently, the dependency tree at the package
>>>> level is not being respected in wiring the bundles.
>>>>
>>>> All of this is a temporary stopgap until some components get correct
>>>> DS @Reference dependencies, which some of them lack.
>>>>
>>>> Questions: Am I making an error using boot features? I realize that
>>>> this report lacks specificity. I could try to build up a model on
>>>> github.
>>>>
>>>> TIA,
>>>> benson
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Prerequisites amongst boot features

[Benson Margulies]

On Thu, Sep 29, 2016 at 10:04 AM, Benson Margulies <ben...@basistech.com> wrote:
> rosapi-worker-flinx-sdk


to be clear, rosapi-worker-flinx-sdk is the name of the feature that I
listed as a prerequisite of another feature.

And the featuresBoot when this failure is happening is:

featuresBoot = \
log, \
rosapi-front-end-anvils-transport, \
bean-validation-support, \
rosapi-worker-common, \
ssh, \
rosapi-front-end-logstash-request-tracker, \
rosapi-front-end-service, \
aries-blueprint, \
feature, \
jaas, \
diagnostic, \
rosapi-worker-download-text-extraction-component, \
rosapi-front-end-null-request-tracker, \
bundle, \
rosapi-all-sdks, \
rosapi-front-end-local-usage-tracker, \
package, \
scr, \
rosapi-common, \
cxf-jaxrs, \
rosette-api, \
rosapi-front-end-embedded-transport, \
system, \
shell, \
shell-compat, \
config, \
wrap

Re: Prerequisites amongst boot features

[Benson Margulies]

And it hangs. It never reaches command level, and it never exits.

If I force a javax.servlet bundle into the situation, I start getting
similar complaints about the package that contains the DS annotations.


➜ rosapi1.5-master git:(dummy) ✗ assemblies/full-test/target/assembly/bin/karaf
2016-09-29 10:03:04,585 | ERROR | pool-6-thread-1  |
org.apache.karaf.features.internal.service.BootFeaturesInstaller |
org.apache.karaf.features.core - 4.0.6 | Error installing boot
features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity;
osgi.identity=rosapi-worker-flinx-sdk; type=karaf.feature; version=0;
filter:="(&(osgi.identity=rosapi-worker-flinx-sdk)(type=karaf.feature)(version>=0.0.0))"
[caused by: Unable to resolve rosapi-worker-flinx-sdk/1.5.0.SNAPSHOT:
missing requirement [rosapi-worker-flinx-sdk/1.5.0.SNAPSHOT]
osgi.identity; osgi.identity=rosapi-common; type=karaf.feature [caused
by: Unable to resolve rosapi-common/1.5.0.SNAPSHOT: missing
requirement [rosapi-common/1.5.0.SNAPSHOT] osgi.identity;
osgi.identity=io.dropwizard.metrics.servlets; type=osgi.bundle;
version="[3.1.2,3.1.2]"; resolution:=mandatory [caused by: Unable to
resolve io.dropwizard.metrics.servlets/3.1.2: missing requirement
[io.dropwizard.metrics.servlets/3.1.2] osgi.wiring.package;
filter:="(&(osgi.wiring.package=javax.servlet)(version>=2.5.0)(!(version>=4.0.0)))"]]]
at 
org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:259)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[6:org.apache.karaf.features.core:4.0.6]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

On Thu, Sep 29, 2016 at 9:56 AM, Guillaume Nodet <gno...@apache.org> wrote:
> Would you mind pasting the stack trace of the error you have please ?
>
>
> 2016-09-29 15:54 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> Hi JB,
>>
>> I let the maven plugin write org.apache.karaf.features.cfg, so I don't
>> know, to be honest, if I'm using multi-stage.
>>
>> _Without_ the failing prerequisites, I have the following content of
>> org.apache.karaf.features.cfg. I'm using the property editor feature
>> to turn off capability enforcement.
>>
>>
>> rosapi-all-sdks is just a bag of  declarations for other
>> features. Things break when I try to make one of them a prerequisite
>> of another. My problem is really to prevent the activation of a few
>> bundles until another bundle is safely under control, and I am hoping
>> for a workaround in the interim until we can really fix this with DS
>> in a few weeks.
>>
>>
>> #Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
>> #Thu Sep 29 09:49:19 EDT 2016
>> featuresBootAsynchronous=false
>> serviceRequirements=disable
>> featuresBoot = \
>> (wrap), \
>> log, \
>> rosapi-front-end-anvils-transport, \
>> bean-validation-support, \
>> rosapi-worker-common, \
>> ssh, \
>> rosapi-front-end-logstash-request-tracker, \
>> rosapi-front-end-service, \
>> aries-blueprint, \
>> feature, \
>> jaas, \
>> diagnostic, \
>> rosapi-worker-download-text-extraction-component, \
>> rosapi-front-end-null-request-tracker, \
>> bundle, \
>> rosapi-all-sdks, \
>> rosapi-front-end-local-usage-tracker, \
>> package, \
>> scr, \
>> rosapi-common, \
>> cxf-jaxrs, \
>> rosette-api, \
>> rosapi-front-end-embedded-transport, \
>> 

Re: Prerequisites amongst boot features

[Benson Margulies]

Hi JB,

I let the maven plugin write org.apache.karaf.features.cfg, so I don't
know, to be honest, if I'm using multi-stage.

_Without_ the failing prerequisites, I have the following content of
org.apache.karaf.features.cfg. I'm using the property editor feature
to turn off capability enforcement.


rosapi-all-sdks is just a bag of  declarations for other
features. Things break when I try to make one of them a prerequisite
of another. My problem is really to prevent the activation of a few
bundles until another bundle is safely under control, and I am hoping
for a workaround in the interim until we can really fix this with DS
in a few weeks.


#Modified by org.apache.karaf.tools.utils.KarafPropertiesFile
#Thu Sep 29 09:49:19 EDT 2016
featuresBootAsynchronous=false
serviceRequirements=disable
featuresBoot = \
(wrap), \
log, \
rosapi-front-end-anvils-transport, \
bean-validation-support, \
rosapi-worker-common, \
ssh, \
rosapi-front-end-logstash-request-tracker, \
rosapi-front-end-service, \
aries-blueprint, \
feature, \
jaas, \
diagnostic, \
rosapi-worker-download-text-extraction-component, \
rosapi-front-end-null-request-tracker, \
bundle, \
rosapi-all-sdks, \
rosapi-front-end-local-usage-tracker, \
package, \
scr, \
rosapi-common, \
cxf-jaxrs, \
rosette-api, \
rosapi-front-end-embedded-transport, \
system, \
shell, \
shell-compat, \
config
featuresRepositories = \
mvn:com.basistech.ws/rosapi-features/1.5.0-SNAPSHOT/xml/features, \
mvn:org.apache.karaf.features/standard/4.0.6/xml/features, \
mvn:org.apache.cxf.karaf/apache-cxf/3.1.4/xml/features, \
mvn:org.apache.karaf.features/framework/4.0.6/xml/features


On Thu, Sep 29, 2016 at 9:47 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Hi Benson,
>
> do you use multi-stage in featuresBoot ?
>
> Regards
> JB
>
>
> On 09/29/2016 03:33 PM, Benson Margulies wrote:
>>
>> Folks,
>>
>> I build an assembly in which all the feature are boot features,
>> because they are all going to be used.
>>
>> When I try to make one of them a prerequisite of another, I get a
>> wiring error, because, apparently, the dependency tree at the package
>> level is not being respected in wiring the bundles.
>>
>> All of this is a temporary stopgap until some components get correct
>> DS @Reference dependencies, which some of them lack.
>>
>> Questions: Am I making an error using boot features? I realize that
>> this report lacks specificity. I could try to build up a model on
>> github.
>>
>> TIA,
>> benson
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Prerequisites amongst boot features

[Benson Margulies]

Folks,

I build an assembly in which all the feature are boot features,
because they are all going to be used.

When I try to make one of them a prerequisite of another, I get a
wiring error, because, apparently, the dependency tree at the package
level is not being respected in wiring the bundles.

All of this is a temporary stopgap until some components get correct
DS @Reference dependencies, which some of them lack.

Questions: Am I making an error using boot features? I realize that
this report lacks specificity. I could try to build up a model on
github.

TIA,
benson

Karaf 4.0.6 / pax-exam 4.8.0 hangs

[Benson Margulies]

Folks,

Since we upgraded to 4.0.6 of Karaf, our integration tests sometimes
hang. The karaf log is uninformative.

Here is a thread-dump of Karaf,

https://gist.github.com/benson-basis/99c51ad89c2358a08b7255b7d20db47a

And here is one of the surefire JVM that is supposed to test it.

If anyone has any ideas as to what causes the clog, I'd be most grateful.

--benson

Re: Creating features.xml files

[Benson Margulies]

On Tue, Sep 20, 2016 at 8:19 AM,  <t...@quarendon.net> wrote:
>
>> On 20 September 2016 at 12:52 Benson Margulies <ben...@basistech.com> 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

[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

[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.
>

Re: Karaf, gogo shell?

[Benson Margulies]

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.

Re: configuration admin files with property references in the values: how's it done?

[Benson Margulies]

Never mind, I worked out for myself that fileinstall does the job.


On Fri, Sep 16, 2016 at 11:17 AM, Benson Margulies <ben...@basistech.com> wrote:
> I've been asked to try an experiment in moving some of the code we run
> in Karaf into a minimal Felix container deployment. I've run into one
> snag: Some of my .cfg files in Karaf take advantage of writing values
> that contain system property references, like
> ${karaf.etc}/something/something.
>
> I had a quick look around in Karaf source, but I failed to find the
> implementation of this, which would appear to need to be an
> alternative ConfigurationAdmin or at least Felix confadmin persistence
> manager. If someone could give me a pointer, I'd be grateful.

configuration admin files with property references in the values: how's it done?

[Benson Margulies]

I've been asked to try an experiment in moving some of the code we run
in Karaf into a minimal Felix container deployment. I've run into one
snag: Some of my .cfg files in Karaf take advantage of writing values
that contain system property references, like
${karaf.etc}/something/something.

I had a quick look around in Karaf source, but I failed to find the
implementation of this, which would appear to need to be an
alternative ConfigurationAdmin or at least Felix confadmin persistence
manager. If someone could give me a pointer, I'd be grateful.

Re: DS and immediate and configurationPolicy == REQUIRE

[Benson Margulies]

On Wed, Sep 14, 2016 at 5:21 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> Well there’s also references…. but if all the required references (using 
> possible target filter properties from the configuration) are satisfied then 
> it should start up when the configuration event arrives.  At least it will 
> create the manager and look around for the references.
>
>
> Note that the service registration is done before the “immediate” component 
> instance creation so that if there’s a “waiting reference” the component 
> instance creation will be done as a result of that reference’s getService 
> call rather than due to the “immediate” setting.  A few years ago this caused 
> lots of deadlocks but I haven’t seen any for a long time.

This is all good news. I have a set of microservices; each one is an
@Component, no one calls for them by @Reference, they don't even list
any service interfaces. I have been asked to make it easier to
configure the overall package to run only a subset.

>
> david jencks
>
>> On Sep 14, 2016, at 2:15 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I'm hoping I know the answer to the following:
>>
>> Assume a DS component with immediate=true and configurationPolicy=REQUIRE.
>>
>> When Karaf starts up, there's no config on the pid. The component won't 
>> start.
>>
>> If I then use the ConfigurationAdmin service to dynamically define
>> some configuration, will it?
>

Re: Invalid Bundle Context errors with 4.0.6, unpredictably

[Benson Margulies]

I don't know of any reason for a refresh. The structure is always that
I have a Karaf assembly; the test launches it and then tests web
services that it publishes. No test involves any updating or deploying
features or bundles.


On Wed, Sep 14, 2016 at 2:59 PM, Guillaume Nodet <gno...@apache.org> wrote:
> If your test deploys certain bundles such as eventadmin, it can cause
> pax-logging-api to be refreshed, which in turn cause almost all bundles to
> be refreshed, which can cause such problems.
> If that's the case, you should consider deploying eventamin at the startup
> stage somehow to avoid the refreshes..
>
> 2016-09-14 20:54 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> Folks,
>>
>> One of my pax-exam tests _sometimes_ fails with the backtrace below;
>> to be more precise, it hangs after showing this backtrace on the
>> console.
>>
>> It seems as if this only happens when all of my ITs run; if I tell
>> failsafe to just run one, it seems never to happen.
>>
>> Any ideas?
>>
>> TIA
>>
>>
>> 2016-09-14 14:46:52,074 | WARN  | pool-6-thread-1  | Activator
>>| 6 - org.apache.karaf.features.core - 4.0.6 | Error
>> starting activator
>> java.lang.IllegalStateException: Invalid BundleContext.
>> at
>> org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)[org.apache.felix.framework-5.4.0.jar:]
>> at
>> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)[org.apache.felix.framework-5.4.0.jar:]
>> at
>> org.apache.karaf.util.tracker.BaseActivator.registerMBean(BaseActivator.java:293)[6:org.apache.karaf.features.core:4.0.6]
>> at
>> org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:265)[6:org.apache.karaf.features.core:4.0.6]
>> at
>> org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:236)[6:org.apache.karaf.features.core:4.0.6]
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60]
>> at
>> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60]
>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
>
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Invalid Bundle Context errors with 4.0.6, unpredictably

[Benson Margulies]

Folks,

One of my pax-exam tests _sometimes_ fails with the backtrace below;
to be more precise, it hangs after showing this backtrace on the
console.

It seems as if this only happens when all of my ITs run; if I tell
failsafe to just run one, it seems never to happen.

Any ideas?

TIA


2016-09-14 14:46:52,074 | WARN  | pool-6-thread-1  | Activator
   | 6 - org.apache.karaf.features.core - 4.0.6 | Error
starting activator
java.lang.IllegalStateException: Invalid BundleContext.
at 
org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:511)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.karaf.util.tracker.BaseActivator.registerMBean(BaseActivator.java:293)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:265)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:236)[6:org.apache.karaf.features.core:4.0.6]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Re: Running Karaf assembly from Maven

[Benson Margulies]

Jens, Karaf is going to fork a new java process. So launching maven with
debugging won't give you debugging inside of Karaf.


On Wed, Sep 14, 2016 at 8:42 AM, Jens Reimann <jreim...@redhat.com> wrote:

> Well that defies the purpose of starting maven in debug mode in the first
> place.
>
> With Eclipse you can start Maven directly in the debugger, so that the
> Maven task you are running is getting debugged. The Karaf plugin seems to
> run the OSGi container directly in the Maven plugin, so it can be debugged
> as well.
>
> Starting some shell script forks another process and this is no longer
> debuggable in that same session.
>
> Sure you can set up remote debugging and everything that comes with that.
> But having a direct debugger without the need to set this all up is way
> easier.
>
> On Wed, Sep 14, 2016 at 2:30 PM, Benson Margulies <ben...@basistech.com>
> wrote:
>
>> Run the exec-maven-plugin to run the 'karaf debug' command if you can't
>> configure eclipse to just run a shell command.
>>
>>
>> On Wed, Sep 14, 2016 at 8:16 AM, Jens Reimann <jreim...@redhat.com>
>> wrote:
>>
>>> Sure, that could be workaround. If there would be a way to run karaf
>>> from maven, then such a workaround would not be possible and full IDE
>>> integration would be available.
>>>
>>> Which brings me back to my original question if such a thing is
>>> possible. And if, then how?
>>>
>>> On Wed, Sep 14, 2016 at 2:00 PM, Achim Nierbeck <bcanh...@googlemail.com
>>> > wrote:
>>>
>>>> call karaf debug and attach eclipse to the opened port is an
>>>> alternative
>>>>
>>>> 2016-09-14 13:57 GMT+02:00 Jens Reimann <jreim...@redhat.com>:
>>>>
>>>>> Yes, that is then not executed by the Eclipse maven runner .. just a
>>>>> shell script. So debugging will not be set up.
>>>>>
>>>>> On Wed, Sep 14, 2016 at 1:44 PM, Benson Margulies <
>>>>> ben...@basistech.com> wrote:
>>>>>
>>>>>> Some problem with typing:
>>>>>>
>>>>>> target/assembly/bin/karaf
>>>>>>
>>>>>> ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 14, 2016 at 6:48 AM, Benson Margulies <
>>>>>> ben...@basistech.com> wrote:
>>>>>>
>>>>>>> Is your goal to start one up and then run tests against it? If so, I
>>>>>>> have some other suggestions.
>>>>>>>
>>>>>>> On Wed, Sep 14, 2016 at 5:17 AM, Jens Reimann <jreim...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> There seems to be a goal for maven "karaf:run" which can run a
>>>>>>>> single bundle. But is there some way to run a karaf assembly, directly 
>>>>>>>> from
>>>>>>>> maven.
>>>>>>>>
>>>>>>>> Thanks for your help
>>>>>>>>
>>>>>>>> Jens
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jens Reimann
>>>>>>>> Senior Software Engineer / EMEA ENG Middleware
>>>>>>>> Werner-von-Siemens-Ring 14
>>>>>>>> 85630 Grasbrunn
>>>>>>>> Germany
>>>>>>>> phone: +49 89 2050 71286
>>>>>>>> 
>>>>>>>> _
>>>>>>>>
>>>>>>>> Red Hat GmbH, www.de.redhat.com,
>>>>>>>> Registered seat: Grasbrunn, Commercial register: Amtsgericht
>>>>>>>> Muenchen, HRB 153243,
>>>>>>>> Managing Directors: Paul Argiry, Charles Cachera, Michael
>>>>>>>> Cunningham, Michael O'Neill
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jens Reimann
>>>>> Senior Software Engineer / EMEA ENG Middleware
>>>>> Werner-von-Siemens-Ring 14
>>>>> 85630 Grasbrunn
>>>>> Germany
>>>>> phone: +49 89 2050 71286
>>>>> 

Re: Running Karaf assembly from Maven

[Benson Margulies]

Run the exec-maven-plugin to run the 'karaf debug' command if you can't
configure eclipse to just run a shell command.


On Wed, Sep 14, 2016 at 8:16 AM, Jens Reimann <jreim...@redhat.com> wrote:

> Sure, that could be workaround. If there would be a way to run karaf from
> maven, then such a workaround would not be possible and full IDE
> integration would be available.
>
> Which brings me back to my original question if such a thing is possible.
> And if, then how?
>
> On Wed, Sep 14, 2016 at 2:00 PM, Achim Nierbeck <bcanh...@googlemail.com>
> wrote:
>
>> call karaf debug and attach eclipse to the opened port is an alternative
>>
>> 2016-09-14 13:57 GMT+02:00 Jens Reimann <jreim...@redhat.com>:
>>
>>> Yes, that is then not executed by the Eclipse maven runner .. just a
>>> shell script. So debugging will not be set up.
>>>
>>> On Wed, Sep 14, 2016 at 1:44 PM, Benson Margulies <ben...@basistech.com>
>>> wrote:
>>>
>>>> Some problem with typing:
>>>>
>>>> target/assembly/bin/karaf
>>>>
>>>> ?
>>>>
>>>>
>>>>
>>>> On Wed, Sep 14, 2016 at 6:48 AM, Benson Margulies <ben...@basistech.com
>>>> > wrote:
>>>>
>>>>> Is your goal to start one up and then run tests against it? If so, I
>>>>> have some other suggestions.
>>>>>
>>>>> On Wed, Sep 14, 2016 at 5:17 AM, Jens Reimann <jreim...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> There seems to be a goal for maven "karaf:run" which can run a single
>>>>>> bundle. But is there some way to run a karaf assembly, directly from 
>>>>>> maven.
>>>>>>
>>>>>> Thanks for your help
>>>>>>
>>>>>> Jens
>>>>>>
>>>>>> --
>>>>>> Jens Reimann
>>>>>> Senior Software Engineer / EMEA ENG Middleware
>>>>>> Werner-von-Siemens-Ring 14
>>>>>> 85630 Grasbrunn
>>>>>> Germany
>>>>>> phone: +49 89 2050 71286
>>>>>> 
>>>>>> _
>>>>>>
>>>>>> Red Hat GmbH, www.de.redhat.com,
>>>>>> Registered seat: Grasbrunn, Commercial register: Amtsgericht
>>>>>> Muenchen, HRB 153243,
>>>>>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
>>>>>> Michael O'Neill
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Jens Reimann
>>> Senior Software Engineer / EMEA ENG Middleware
>>> Werner-von-Siemens-Ring 14
>>> 85630 Grasbrunn
>>> Germany
>>> phone: +49 89 2050 71286
>>> 
>>> _
>>>
>>> Red Hat GmbH, www.de.redhat.com,
>>> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
>>> HRB 153243,
>>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
>>> Michael O'Neill
>>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
>
>
> --
> Jens Reimann
> Senior Software Engineer / EMEA ENG Middleware
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
> phone: +49 89 2050 71286
> 
> _
>
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
> 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> Michael O'Neill
>

Re: Running Karaf assembly from Maven

[Benson Margulies]

Some problem with typing:

target/assembly/bin/karaf

?



On Wed, Sep 14, 2016 at 6:48 AM, Benson Margulies <ben...@basistech.com>
wrote:

> Is your goal to start one up and then run tests against it? If so, I have
> some other suggestions.
>
> On Wed, Sep 14, 2016 at 5:17 AM, Jens Reimann <jreim...@redhat.com> wrote:
>
>> Hi,
>>
>> There seems to be a goal for maven "karaf:run" which can run a single
>> bundle. But is there some way to run a karaf assembly, directly from maven.
>>
>> Thanks for your help
>>
>> Jens
>>
>> --
>> Jens Reimann
>> Senior Software Engineer / EMEA ENG Middleware
>> Werner-von-Siemens-Ring 14
>> 85630 Grasbrunn
>> Germany
>> phone: +49 89 2050 71286
>> 
>> _
>>
>> Red Hat GmbH, www.de.redhat.com,
>> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
>> HRB 153243,
>> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
>> Michael O'Neill
>>
>
>

Re: Running Karaf assembly from Maven

[Benson Margulies]

Is your goal to start one up and then run tests against it? If so, I have
some other suggestions.

On Wed, Sep 14, 2016 at 5:17 AM, Jens Reimann  wrote:

> Hi,
>
> There seems to be a goal for maven "karaf:run" which can run a single
> bundle. But is there some way to run a karaf assembly, directly from maven.
>
> Thanks for your help
>
> Jens
>
> --
> Jens Reimann
> Senior Software Engineer / EMEA ENG Middleware
> Werner-von-Siemens-Ring 14
> 85630 Grasbrunn
> Germany
> phone: +49 89 2050 71286
> 
> _
>
> Red Hat GmbH, www.de.redhat.com,
> Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB
> 153243,
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
> Michael O'Neill
>

Doc on embedded mode?

[Benson Margulies]

Folks, other than the reference at the very beginning of
https://karaf.apache.org/manual/latest/, is there any doc on how to go
about embedding Karaf? If not, off to the source code, of course.

thanks

Re: Component configuration pid

[Benson Margulies]

On Fri, Sep 9, 2016 at 10:00 PM, David Jencks 
wrote:

> Well, either
> 1. you didn’t actually succeed in creating a bundle with a different pid
> for your component.  Look in the (I hope generated) xml configuration in
> the bundle you’ve created and see if it’s what you expect.
> 2. you didn’t actually succeed in deploying your updated bundle.  If your
> new bundle has a different version than the old one you should be able to
> distinguish which one is actually activated.
> 3. karaf’s scr:info is flakier than I think possible.
>
> I really don’t think (3) is plausible.
>

At least in 4.0.4, the Karaf scr:info command is very confusing. The Felix
command scr:details that comes along with scr itself is much more
informative. I am not, however, prepared to contradict your view.

>
> david jencks
>
> On Sep 9, 2016, at 7:20 AM, Leschke, Scott  wrote:
>
> I have a component on which I’ve changed the configuration pid. I made the
> change and redeployed the bundle in which it resides. The pid doesn’t get
> updated though (as shown by scr:info).  How do I go about getting the pid
> to update?  I see no provision in SCR for deleting or refreshing the
> component in some way.
>
> Scott
>
>
>

Re: Can't uninstall shell-compat?

[Benson Margulies]

I agree that the error message could use some help here.

I'll eventually build an assembly to set how 'help scr' is doing
without shell-compat.


On Mon, Sep 5, 2016 at 3:29 PM, Guillaume Nodet <gno...@apache.org> wrote:
> The wording of the message is slightly wrong.
> It should be "Feature named 'shell-compat/4.0.6' is not required" but it
> would not be much more clear.
> In short, the fact that a feature is installed does not mean you can
> "uninstall" it.
> You can only uninstall features you have explicitly installed.
> And btw, this does not mean that it will be uninstalled, this will be the
> case only if it's not required by another feature.
>
> If you want to get a better picture of what happens, you can use the
> "requirement-list" command that will print all the input requirements for
> the feature service (and resolver).  All those requirements will be
> fulfilled at any time after calling "feature:install" or "feature:uninstall"
> (or "requirement-add", "requirement-remove").  You can also add requirements
> on bundles, services, etc...
>
> So to get back to the initial problem, "feature:uninstall" does not go
> through the list of bundles and uninstalling them anymore.  It removes the
> requirement from the list of input requirements and run the resolver again.
> If the feature is not needed anymore, its bundles will be uninstalled.
>
>
>
> 2016-09-05 21:01 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> I install shell-compat by including 'standard' in my assembly.
>>
>> If I try to uninstall it, I get the following complaint that it is not
>> installed.
>>
>> karaf@root>feature:uninstall shell-compat/4.0.6
>> 2016-09-05 14:59:20,611 | ERROR | nsole user karaf | ShellUtil
>>| 191 - org.apache.karaf.shell.core - 4.0.6 | Exception
>> caught while executing command
>> java.lang.IllegalArgumentException: Feature named 'shell-compat/4.0.6'
>> is not installed
>> at
>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.uninstallFeatures(FeaturesServiceImpl.java:997)[6:org.apache.karaf.features.core:4.0.6]
>> at
>> org.apache.karaf.features.command.UninstallFeatureCommand.doExecute(UninstallFeatureCommand.java:54)[178:org.apache.karaf.features.command:4.0.6]
>> at
>> org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:37)[178:org.apache.karaf.features.command:4.0.6]
>> at
>> org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:83)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:480)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:406)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:182)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:119)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:94)[191:org.apache.karaf.shell.core:4.0.6]
>> at
>> org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:274)[191:org.apache.karaf.shell.core:4.0.6]
>> at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
>
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>

Can't uninstall shell-compat?

[Benson Margulies]

I install shell-compat by including 'standard' in my assembly.

If I try to uninstall it, I get the following complaint that it is not
installed.

karaf@root>feature:uninstall shell-compat/4.0.6
2016-09-05 14:59:20,611 | ERROR | nsole user karaf | ShellUtil
   | 191 - org.apache.karaf.shell.core - 4.0.6 | Exception
caught while executing command
java.lang.IllegalArgumentException: Feature named 'shell-compat/4.0.6'
is not installed
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.uninstallFeatures(FeaturesServiceImpl.java:997)[6:org.apache.karaf.features.core:4.0.6]
at 
org.apache.karaf.features.command.UninstallFeatureCommand.doExecute(UninstallFeatureCommand.java:54)[178:org.apache.karaf.features.command:4.0.6]
at 
org.apache.karaf.features.command.FeaturesCommandSupport.execute(FeaturesCommandSupport.java:37)[178:org.apache.karaf.features.command:4.0.6]
at 
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:83)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:480)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:406)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:182)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:119)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:94)[191:org.apache.karaf.shell.core:4.0.6]
at 
org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:274)[191:org.apache.karaf.shell.core:4.0.6]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Re: Is blueprint missing from the 'minimal' feature?

[Benson Margulies]

Hmm. At one point, the Felix scr command NPE'd without shell-compat. I
guess I'll try it again in 4.0.6.

On the other hand, I'm probably stuck with blueprint sooner or later
due to some other dependencies, so perhaps I should let this go.

Thanks.
benson


On Mon, Sep 5, 2016 at 1:14 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Yes shell-compat is the feature to use to support gogo commands and "old
> style" Karaf commands (which were using blueprint). Afair gogo commands also
> work directly in shell console without compat.
>
> Regards
> JB
>
> Regards
> JB
>
> On Sep 5, 2016, at 19:02, Benson Margulies <ben...@basistech.com> wrote:
>>
>> shell-compat, via the shell 'console', depends on blueprint. Proof
>> below. shell does not. Minimal includes shell, not shell-compat. This
>> is sad, as shell-compat is required to make gogo commands work right.
>> But it explains my confusion, as I thought that shell-compat was in
>> 'minimal' and I was wrong.
>>
>> The details are as follows:
>>
>> [caused by: Unable to resolve org.apache.karaf.shell.console/4.0.6:
>> missing requirement [org.apache.karaf.shell.console/4.0.6]
>> osgi.wiring.package;
>>
>> filter:="(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))"]]
>>
>> The MANIFEST.MF for the 4.0.6 version of
>> org.apache.karaf.shell.console. It has a Bundle-Blueprint and here is
>> a fragment.
>>
>> org.apache.k
>>  araf.shell.console;version="4.0.6";uses:="org.apache.felix.service.comm
>>  and,org.apache.karaf.shell.commands,org.osgi.framework,org.osgi.service
>>  .blueprint.container,org.slf4j"
>>
>>
>> On
>> Mon, Sep 5, 2016 at 11:49 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>>
>>>  It's maybe because your bundles require blueprint (or a feature
>>> dependency),
>>>  no ?
>>>
>>>  If you use the karaf-service-maven-plugin with the Karaf shell
>>> annotations,
>>>  it doesn't use blueprint.
>>>
>>>  Regards
>>>  JB
>>>
>>>  On 09/05/2016 05:46 PM, Benson Margulies wrote:
>>>>
>>>>
>>>>  That error I sent is from karaf 4.0.6. it seems to me to be saying that
>>>>  the shell requires blueprint. Am I misreading it?
>>>>
>>>>
>>>>  On Sep 5, 2016 11:21 AM, "Jean-Baptiste Onofré" <j...@nanthrax.net
>>>>  <mailto:j...@nanthrax.net>> wrote:
>>>>
>>>>  Hi Benson,
>>>>
>>>>  on Karaf 4, shell doesn't depend to blueprint anymore.
>>>>
>>>>  Regards
>>>>  JB
>>>>
>>>>
>>>> On 09/05/2016 05:07 PM, Benson Margulies wrote:
>>>>
>>>>  Achim, Yes, I understand the principle. What I don't understand
>>>>  is how
>>>>  anyone uses 'minimal'. Minimal includes shell, and shell
>>>> requires
>>>>  blueprint, and blueprint isn't 'minimal'. Or is the idea that
>>>> no
>>>>  one
>>>>  should try to use minimal, it's just a building block for
>>>>  standard and
>>>>  others?
>>>>
>>>>
>>>>  On Mon, Sep 5, 2016 at 11:05 AM, Achim Nierbeck
>>>>  <bcanh...@googlemail.com <mailto:bcanh...@googlemail.com>>
>>>> wrote:
>>>>
>>>>  yep it's minimal so only the minimal required bundles are
>>>>  there.
>>>>  Blueprint is part of standard, as that isn't minimal
>>>> anymore
>>>>  ...
>>>>
>>>>  regards, Achiim
>>>>
>>>>
>>>>  2016-09-05 16:45 GMT+02:00 Benson Margulies
>>>>  <ben...@basistech.com <mailto:ben...@basistech.com>>:
>>>>
>>>>
>>>>
>>>>  Folks,
>>>>
>>>>
>>>> When I try to run an assembly that lists 'minimal' as a
>>>>  boot feature,
>>>>  I get this error, indicating that (If I read it
>>>>  correctly) the shell
>>>>  requires blueprint. Is this intended? I can switch to
>>>>  'standard'
>>>>  easily enough.
>>>>
>>>

Re: Is blueprint missing from the 'minimal' feature?

[Benson Margulies]

shell-compat, via the shell 'console', depends on blueprint. Proof
below. shell does not. Minimal includes shell, not shell-compat. This
is sad, as shell-compat is required to make gogo commands work right.
But it explains my confusion, as I thought that shell-compat was in
'minimal' and I was wrong.

The details are as follows:

[caused by: Unable to resolve org.apache.karaf.shell.console/4.0.6:
missing requirement [org.apache.karaf.shell.console/4.0.6]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))"]]

The MANIFEST.MF for the 4.0.6 version of
org.apache.karaf.shell.console. It has a Bundle-Blueprint and here is
a fragment.

org.apache.k
 araf.shell.console;version="4.0.6";uses:="org.apache.felix.service.comm
 and,org.apache.karaf.shell.commands,org.osgi.framework,org.osgi.service
 .blueprint.container,org.slf4j"


On Mon, Sep 5, 2016 at 11:49 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> It's maybe because your bundles require blueprint (or a feature dependency),
> no ?
>
> If you use the karaf-service-maven-plugin with the Karaf shell annotations,
> it doesn't use blueprint.
>
> Regards
> JB
>
> On 09/05/2016 05:46 PM, Benson Margulies wrote:
>>
>> That error I sent is from karaf 4.0.6. it seems to me to be saying that
>> the shell requires blueprint. Am I misreading it?
>>
>>
>> On Sep 5, 2016 11:21 AM, "Jean-Baptiste Onofré" <j...@nanthrax.net
>> <mailto:j...@nanthrax.net>> wrote:
>>
>> Hi Benson,
>>
>> on Karaf 4, shell doesn't depend to blueprint anymore.
>>
>> Regards
>> JB
>>
>> On 09/05/2016 05:07 PM, Benson Margulies wrote:
>>
>> Achim, Yes, I understand the principle. What I don't understand
>> is how
>> anyone uses 'minimal'. Minimal includes shell, and shell requires
>> blueprint, and blueprint isn't 'minimal'. Or is the idea that no
>> one
>> should try to use minimal, it's just a building block for
>> standard and
>> others?
>>
>>
>> On Mon, Sep 5, 2016 at 11:05 AM, Achim Nierbeck
>> <bcanh...@googlemail.com <mailto:bcanh...@googlemail.com>> wrote:
>>
>> yep it's minimal so only the minimal required bundles are
>> there.
>> Blueprint is part of standard, as that isn't minimal anymore
>> ...
>>
>> regards, Achiim
>>
>>
>> 2016-09-05 16:45 GMT+02:00 Benson Margulies
>> <ben...@basistech.com <mailto:ben...@basistech.com>>:
>>
>>
>>
>> Folks,
>>
>> When I try to run an assembly that lists 'minimal' as a
>> boot feature,
>> I get this error, indicating that (If I read it
>> correctly) the shell
>> requires blueprint. Is this intended? I can switch to
>> 'standard'
>> easily enough.
>>
>>
>> 2016-09-05 10:42:36,560 | ERROR | pool-6-thread-1  |
>> BootFeaturesInstaller| 6 -
>> org.apache.karaf.features.core
>> - 4.0.6 | Error installing boot features
>> org.osgi.service.resolver.ResolutionException: Unable to
>> resolve root:
>> missing requirement [root] osgi.identity;
>> osgi.identity=rosapi-front-end-service;
>> type=karaf.feature;
>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>
>>
>> filter:="(&(osgi.identity=rosapi-front-end-service)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>> [caused by: Unable to resolve
>> rosapi-front-end-service/1.2.6.SNAPSHOT:
>> missing requirement
>> [rosapi-front-end-service/1.2.6.SNAPSHOT]
>> osgi.identity;
>> osgi.identity=org.apache.karaf.shell.console;
>> type=osgi.fragment; version="[4.0.6,4.0.6]";
>> resolution:=mandatory
>> [caused by: Unable to resolve
>> org.apache.karaf.shell.console/4.0.6:
>> missing requirement [org.apache.karaf.shell.console/4.0.6]
>> osgi.wiring.package;
>>
>>
>> filter:="(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))"]]

Re: Is blueprint missing from the 'minimal' feature?

[Benson Margulies]

That error I sent is from karaf 4.0.6. it seems to me to be saying that the
shell requires blueprint. Am I misreading it?

On Sep 5, 2016 11:21 AM, "Jean-Baptiste Onofré" <j...@nanthrax.net> wrote:

> Hi Benson,
>
> on Karaf 4, shell doesn't depend to blueprint anymore.
>
> Regards
> JB
>
> On 09/05/2016 05:07 PM, Benson Margulies wrote:
>
>> Achim, Yes, I understand the principle. What I don't understand is how
>> anyone uses 'minimal'. Minimal includes shell, and shell requires
>> blueprint, and blueprint isn't 'minimal'. Or is the idea that no one
>> should try to use minimal, it's just a building block for standard and
>> others?
>>
>>
>> On Mon, Sep 5, 2016 at 11:05 AM, Achim Nierbeck <bcanh...@googlemail.com>
>> wrote:
>>
>>> yep it's minimal so only the minimal required bundles are there.
>>> Blueprint is part of standard, as that isn't minimal anymore ...
>>>
>>> regards, Achiim
>>>
>>>
>>> 2016-09-05 16:45 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>>
>>>>
>>>> Folks,
>>>>
>>>> When I try to run an assembly that lists 'minimal' as a boot feature,
>>>> I get this error, indicating that (If I read it correctly) the shell
>>>> requires blueprint. Is this intended? I can switch to 'standard'
>>>> easily enough.
>>>>
>>>>
>>>> 2016-09-05 10:42:36,560 | ERROR | pool-6-thread-1  |
>>>> BootFeaturesInstaller| 6 - org.apache.karaf.features.core
>>>> - 4.0.6 | Error installing boot features
>>>> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
>>>> missing requirement [root] osgi.identity;
>>>> osgi.identity=rosapi-front-end-service; type=karaf.feature;
>>>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>>>
>>>> filter:="(&(osgi.identity=rosapi-front-end-service)(type=
>>>> karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>>>> [caused by: Unable to resolve rosapi-front-end-service/1.2.6.SNAPSHOT:
>>>> missing requirement [rosapi-front-end-service/1.2.6.SNAPSHOT]
>>>> osgi.identity; osgi.identity=org.apache.karaf.shell.console;
>>>> type=osgi.fragment; version="[4.0.6,4.0.6]"; resolution:=mandatory
>>>> [caused by: Unable to resolve org.apache.karaf.shell.console/4.0.6:
>>>> missing requirement [org.apache.karaf.shell.console/4.0.6]
>>>> osgi.wiring.package;
>>>>
>>>> filter:="(&(osgi.wiring.package=org.apache.aries.blueprint)(
>>>> version>=1.5.0)(!(version>=2.0.0)))"]]
>>>> at org.apache.felix.resolver.ResolutionError.toException(Resolutio
>>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Apache Member
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>>> &
>>> Project Lead
>>> blog <http://notizblog.nierbeck.de/>
>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>
>>> Software Architect / Project Manager / Scrum Master
>>>
>>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Is blueprint missing from the 'minimal' feature?

[Benson Margulies]

Achim, Yes, I understand the principle. What I don't understand is how
anyone uses 'minimal'. Minimal includes shell, and shell requires
blueprint, and blueprint isn't 'minimal'. Or is the idea that no one
should try to use minimal, it's just a building block for standard and
others?


On Mon, Sep 5, 2016 at 11:05 AM, Achim Nierbeck <bcanh...@googlemail.com> wrote:
> yep it's minimal so only the minimal required bundles are there.
> Blueprint is part of standard, as that isn't minimal anymore ...
>
> regards, Achiim
>
>
> 2016-09-05 16:45 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> Folks,
>>
>> When I try to run an assembly that lists 'minimal' as a boot feature,
>> I get this error, indicating that (If I read it correctly) the shell
>> requires blueprint. Is this intended? I can switch to 'standard'
>> easily enough.
>>
>>
>> 2016-09-05 10:42:36,560 | ERROR | pool-6-thread-1  |
>> BootFeaturesInstaller| 6 - org.apache.karaf.features.core
>> - 4.0.6 | Error installing boot features
>> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
>> missing requirement [root] osgi.identity;
>> osgi.identity=rosapi-front-end-service; type=karaf.feature;
>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>
>> filter:="(&(osgi.identity=rosapi-front-end-service)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>> [caused by: Unable to resolve rosapi-front-end-service/1.2.6.SNAPSHOT:
>> missing requirement [rosapi-front-end-service/1.2.6.SNAPSHOT]
>> osgi.identity; osgi.identity=org.apache.karaf.shell.console;
>> type=osgi.fragment; version="[4.0.6,4.0.6]"; resolution:=mandatory
>> [caused by: Unable to resolve org.apache.karaf.shell.console/4.0.6:
>> missing requirement [org.apache.karaf.shell.console/4.0.6]
>> osgi.wiring.package;
>>
>> filter:="(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))"]]
>> at org.apache.felix.resolver.ResolutionError.toException(Resolutio
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>

Is blueprint missing from the 'minimal' feature?

[Benson Margulies]

Folks,

When I try to run an assembly that lists 'minimal' as a boot feature,
I get this error, indicating that (If I read it correctly) the shell
requires blueprint. Is this intended? I can switch to 'standard'
easily enough.


2016-09-05 10:42:36,560 | ERROR | pool-6-thread-1  |
BootFeaturesInstaller| 6 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity;
osgi.identity=rosapi-front-end-service; type=karaf.feature;
version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
filter:="(&(osgi.identity=rosapi-front-end-service)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
[caused by: Unable to resolve rosapi-front-end-service/1.2.6.SNAPSHOT:
missing requirement [rosapi-front-end-service/1.2.6.SNAPSHOT]
osgi.identity; osgi.identity=org.apache.karaf.shell.console;
type=osgi.fragment; version="[4.0.6,4.0.6]"; resolution:=mandatory
[caused by: Unable to resolve org.apache.karaf.shell.console/4.0.6:
missing requirement [org.apache.karaf.shell.console/4.0.6]
osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))"]]
at org.apache.felix.resolver.ResolutionError.toException(Resolutio

Re: What does effective:=active mean?

[Benson Margulies]

THANK YOU ALL!

On Wed, Aug 31, 2016 at 7:15 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Yes, it's what we agreed for 4.0.0.
>
> Regards
> JB
>
> On 08/31/2016 04:14 PM, Guillaume Nodet wrote:
>>
>> You can always disable service requirements globally by setting
>>   serviceRequirements = disable
>> in the etc/org.apache.karaf.features.cfg config file.
>>
>>
>> 2016-08-31 15:34 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net
>> <mailto:j...@nanthrax.net>>:
>>
>>
>> Hi Benson,
>>
>> I agree: we had a long discussion with Guillaume about that in the
>> past ;)
>>
>> As a workaround, you can use the feature capability definition (and
>> it can be done at runtime using feature:* commands). So your DS
>> components don't have to change.
>>
>> Regards
>> JB
>>
>>
>> On 08/31/2016 03:30 PM, Benson Margulies wrote:
>>
>> Gentlemen,
>>
>> Thank you very much for the help. I want to offer a small
>> argument for
>> an option to turn all this off in a CFG file, before I get to work
>> using the solutions you've offered.
>>
>> One of the virtues of DS is that you can mix-and-match: a DS
>> component
>> can transparently use non-DS services. This resolver feature
>> disables
>> that nice transparency by requiring any service used in a DS
>> component
>> to be accounted for in a Provide-Capability. So you might accept
>> the
>> proposition that this resolver enforcement is not so good for
>> everyone.
>>
>> --benson
>>
>>
>>
>>
>> On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet
>> <gno...@apache.org <mailto:gno...@apache.org>> wrote:
>>
>>
>>
>> 2016-08-31 15:00 GMT+02:00 Benson Margulies
>> <ben...@basistech.com <mailto:ben...@basistech.com>>:
>>
>>
>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré
>> <j...@nanthrax.net <mailto:j...@nanthrax.net>>
>>
>> wrote:
>>
>> So, I will explain a new time (for the third time ;)).
>>
>>
>> JB,
>>
>> I apologize for not being awake when this came through
>> before.
>>
>> I just want to make sure that I am completely following
>> this. The
>> resolver is requiring that some bundle mentions the
>> service in a
>> Provide-Capability -- NOT that the service is actually
>> running?
>>
>>
>>
>> The resolver looks at the bundle manifest. It runs before
>> they are installed
>> / started, so it can't really look at if they are running or
>> not.
>>
>>
>>
>> The service in question is provided by an 'old' OSGi
>> bundle that does
>> not bother to do a Provide-Capability for it; it's not a
>> service, just
>> a service launched the old-fashioned way.
>>
>> Is there some thread you can point me to that offers
>> suggestions for
>> dealing with this? I would rather not have to go add
>> Provide-Capability manifest entries for all my
>> dynamically created
>> OSGi services. Is there an option in a cfg file or a
>> feature.xml that
>> turns this back off?
>>
>>
>>
>> This could be done for karaf 4.1 with a new xsd.
>>
>>
>>
>> Perhaps I can persuade BND not to list them as
>> requirements.
>>
>>
>>
>> Yeah, that's definitely the easiest way, you can easily
>> remove the
>> Require-Capability header, or disable the service
>> requirements, depending on
>> how they are generated.
>>
>>
>>
>>
>> Thanks,
>> benson
>>
>>
>>
>> When you are using features XML with namespace 1.3
>> or 1.4, the feature
>> resolver us

Re: What does effective:=active mean?

[Benson Margulies]

Gentlemen,

Thank you very much for the help. I want to offer a small argument for
an option to turn all this off in a CFG file, before I get to work
using the solutions you've offered.

One of the virtues of DS is that you can mix-and-match: a DS component
can transparently use non-DS services. This resolver feature disables
that nice transparency by requiring any service used in a DS component
to be accounted for in a Provide-Capability. So you might accept the
proposition that this resolver enforcement is not so good for
everyone.

--benson




On Wed, Aug 31, 2016 at 6:13 AM, Guillaume Nodet <gno...@apache.org> wrote:
>
>
> 2016-08-31 15:00 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>> > So, I will explain a new time (for the third time ;)).
>>
>> JB,
>>
>> I apologize for not being awake when this came through before.
>>
>> I just want to make sure that I am completely following this. The
>> resolver is requiring that some bundle mentions the service in a
>> Provide-Capability -- NOT that the service is actually running?
>
>
> The resolver looks at the bundle manifest. It runs before they are installed
> / started, so it can't really look at if they are running or not.
>
>>
>>
>> The service in question is provided by an 'old' OSGi bundle that does
>> not bother to do a Provide-Capability for it; it's not a service, just
>> a service launched the old-fashioned way.
>>
>> Is there some thread you can point me to that offers suggestions for
>> dealing with this? I would rather not have to go add
>> Provide-Capability manifest entries for all my dynamically created
>> OSGi services. Is there an option in a cfg file or a feature.xml that
>> turns this back off?
>
>
> This could be done for karaf 4.1 with a new xsd.
>
>>
>>
>> Perhaps I can persuade BND not to list them as requirements.
>
>
> Yeah, that's definitely the easiest way, you can easily remove the
> Require-Capability header, or disable the service requirements, depending on
> how they are generated.
>
>
>>
>>
>> Thanks,
>> benson
>>
>>
>> >
>> > When you are using features XML with namespace 1.3 or 1.4, the feature
>> > resolver uses the service enforcement. It means that it checks the
>> > service
>> > capability in the bundles. The service requirement is basically a bundle
>> > that needs a service "A" at runtime. So the resolver will check the
>> > features
>> > containing the bundle providing such capability (exposing the service).
>> > It's
>> > what the effective:=active mean.
>> >
>> > The corresponding MANIFEST header is:
>> >
>> > 
>> > osgi.service;effective:=active;objectClass=myService
>> > 
>> >
>> > On the other hand, the requirement header looks like:
>> >
>> > 
>> > osgi.service;effective:=active;filter:="(objectClass=aService)"
>> > 
>> >
>> >
>> > Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
>> > enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug
>> > has
>> > been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to
>> > 4.0.6,
>> > the feature resolver is now "active" for your features XML and check the
>> > service enforcement.
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 08/31/2016 02:31 PM, Benson Margulies wrote:
>> >>
>> >> I just tried the experiment of moving our platform from 4.0.4 to
>> >> 4.0.6, changing nothing but the karaf version. I received in return a
>> >> resolution error that I've never seen the like of before, complaining
>> >> that a particular service is missing with 'effective:=active'.
>> >>
>> >> Since Karaf does not come to command level when this sort of thing
>> >> goes wrong, it is not obvious to me how to gain any insight into what
>> >> is wrong. The service reference itself is very strange;
>> >> 'RosetteBundleWarmup' a DS reference like:
>> >>
>> >> @Reference(target = "(component-name=name-matching)")
>> >> public void setWarmup(RosetteBundleWarmup warmup) {
>> >> this.componentWarmup = warmup;
>> >> }
>> >>
>> >> and I don't see the component-name filter in the error message. It's
>> >>

Re: What does effective:=active mean?

[Benson Margulies]

On Wed, Aug 31, 2016 at 5:50 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> So, I will explain a new time (for the third time ;)).

JB,

I apologize for not being awake when this came through before.

I just want to make sure that I am completely following this. The
resolver is requiring that some bundle mentions the service in a
Provide-Capability -- NOT that the service is actually running?

The service in question is provided by an 'old' OSGi bundle that does
not bother to do a Provide-Capability for it; it's not a service, just
a service launched the old-fashioned way.

Is there some thread you can point me to that offers suggestions for
dealing with this? I would rather not have to go add
Provide-Capability manifest entries for all my dynamically created
OSGi services. Is there an option in a cfg file or a feature.xml that
turns this back off?

Perhaps I can persuade BND not to list them as requirements.

Thanks,
benson


>
> When you are using features XML with namespace 1.3 or 1.4, the feature
> resolver uses the service enforcement. It means that it checks the service
> capability in the bundles. The service requirement is basically a bundle
> that needs a service "A" at runtime. So the resolver will check the features
> containing the bundle providing such capability (exposing the service). It's
> what the effective:=active mean.
>
> The corresponding MANIFEST header is:
>
> 
> osgi.service;effective:=active;objectClass=myService
> 
>
> On the other hand, the requirement header looks like:
>
> 
> osgi.service;effective:=active;filter:="(objectClass=aService)"
> 
>
>
> Unfortunately, in Karaf 4.0.3, 4.0.4, 4.0.5, the service enforcement was
> enabled for features xmlns 1.3.0 NOT for 1.4.0 (it was a bug). This bug has
> been fixed in Karaf 4.0.6. That's why when you upgraded from 4.0.4 to 4.0.6,
> the feature resolver is now "active" for your features XML and check the
> service enforcement.
>
> Regards
> JB
>
>
> On 08/31/2016 02:31 PM, Benson Margulies wrote:
>>
>> I just tried the experiment of moving our platform from 4.0.4 to
>> 4.0.6, changing nothing but the karaf version. I received in return a
>> resolution error that I've never seen the like of before, complaining
>> that a particular service is missing with 'effective:=active'.
>>
>> Since Karaf does not come to command level when this sort of thing
>> goes wrong, it is not obvious to me how to gain any insight into what
>> is wrong. The service reference itself is very strange;
>> 'RosetteBundleWarmup' a DS reference like:
>>
>> @Reference(target = "(component-name=name-matching)")
>> public void setWarmup(RosetteBundleWarmup warmup) {
>> this.componentWarmup = warmup;
>> }
>>
>> and I don't see the component-name filter in the error message. It's
>> also new to me that DS @Reference is even visible to resolution at the
>> time that boot features are being resolved.
>>
>>
>> 2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1  |
>> BootFeaturesInstaller| 6 - org.apache.karaf.features.core
>> - 4.0.6 | Error installing boot features
>> org.osgi.service.resolver.ResolutionException: Unable to resolve root:
>> missing requirement [root] osgi.identity;
>> osgi.identity=rosapi-all-sdks; type=karaf.feature;
>> version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
>>
>> filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
>> [caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
>> requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
>> osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
>> by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
>> missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
>> osgi.identity; osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
>> type=osgi.bundle;
>> version="[1.2.6.v2016083117,1.2.6.v2016083117]";
>> resolution:=mandatory [caused by: Unable to resolve
>> com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117:
>> missing requirement
>> [com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117]
>> osgi.service;
>> filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
>> effective:=active]]]
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

What does effective:=active mean?

[Benson Margulies]

I just tried the experiment of moving our platform from 4.0.4 to
4.0.6, changing nothing but the karaf version. I received in return a
resolution error that I've never seen the like of before, complaining
that a particular service is missing with 'effective:=active'.

Since Karaf does not come to command level when this sort of thing
goes wrong, it is not obvious to me how to gain any insight into what
is wrong. The service reference itself is very strange;
'RosetteBundleWarmup' a DS reference like:

@Reference(target = "(component-name=name-matching)")
public void setWarmup(RosetteBundleWarmup warmup) {
this.componentWarmup = warmup;
}

and I don't see the component-name filter in the error message. It's
also new to me that DS @Reference is even visible to resolution at the
time that boot features are being resolved.


2016-08-31 08:25:36,304 | ERROR | pool-6-thread-1  |
BootFeaturesInstaller| 6 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity;
osgi.identity=rosapi-all-sdks; type=karaf.feature;
version="[1.2.6.SNAPSHOT,1.2.6.SNAPSHOT]";
filter:="(&(osgi.identity=rosapi-all-sdks)(type=karaf.feature)(version>=1.2.6.SNAPSHOT)(version<=1.2.6.SNAPSHOT))"
[caused by: Unable to resolve rosapi-all-sdks/1.2.6.SNAPSHOT: missing
requirement [rosapi-all-sdks/1.2.6.SNAPSHOT] osgi.identity;
osgi.identity=rosapi-worker-rni-rnt-sdk; type=karaf.feature [caused
by: Unable to resolve rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT:
missing requirement [rosapi-worker-rni-rnt-sdk/1.2.6.SNAPSHOT]
osgi.identity; osgi.identity=com.basistech.ws.rosapi-worker-rni-rnt-sdk;
type=osgi.bundle;
version="[1.2.6.v2016083117,1.2.6.v2016083117]";
resolution:=mandatory [caused by: Unable to resolve
com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117:
missing requirement
[com.basistech.ws.rosapi-worker-rni-rnt-sdk/1.2.6.v2016083117]
osgi.service; 
filter:="(objectClass=com.basistech.rosette.osgi.RosetteBundleWarmup)";
effective:=active]]]

Re: RESTful web service in Karaf using CXF and blueprint

[Benson Margulies]

Christian, you might recall that I got into problems with
configuration issues, and you plan to address the issues I ran into in
2.0. I can dig that mail up again if you don't still have it. Thus
'not ready yet.'

On Mon, Aug 15, 2016 at 1:30 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Hi Benson,
>
> would be great to get some feedback about your experiences using dOSGi. As
> we are approaching the 2.0 version now is the best time to get important
> features in.
>
> Christian
>
> 2016-08-15 19:24 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>
>> Correct. I tried the dOSGi stuff, and it wasn't really ready to do
>> what I needed to do.
>>
>> On Mon, Aug 15, 2016 at 1:17 PM, David Jencks <david.a.jen...@gmail.com>
>> wrote:
>> > Just to see if I understand what you are doing, this approach does not
>> > involve the osgi service registry in any way for the REST service
>> > implementation object?  You are directly registering the component instance
>> > with CXF, and there is no need for it to expose any service interfaces at
>> > all?
>> >
>> > thanks
>> > david jencks
>> >
>> >> On Aug 15, 2016, at 10:10 AM, Benson Margulies <ben...@basistech.com>
>> >> wrote:
>> >>
>> >> I do this by making DS @Activate methods call the CXF API to publish
>> >> REST services.
>> >>
>> >>
>> >> On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis <sle...@composent.com>
>> >> wrote:
>> >>> Hi Marc,
>> >>>
>> >>> The OSGi Remote Services specification (and the associated Remote
>> >>> Service
>> >>> Admin sepc) defines a standardized way to export OSGi services for
>> >>> remote
>> >>> access.   The specification is defined in a way that allows the use of
>> >>> arbitrary distribution providers that are responsible for making the
>> >>> OSGi
>> >>> service accessible from outside of the OSGi process.
>> >>>
>> >>> ECF [1] has an implementation of these specs that supports many
>> >>> distribution
>> >>> providers [2], including two that I'm working on now that supports any
>> >>> Jax-RS implementation (i.e. both CXF and Jersey).   These two
>> >>> distribution
>> >>> providers are here [3] and I'm finalizing them for an initial release.
>> >>> Note that for these providers, in addition to specifying jax-rs
>> >>> resources
>> >>> via OSGi services, the jax-rs configuration (e.g.
>> >>> MessageBodyReader/Writers,
>> >>> Features, etc) can also be specified via OSGi services.
>> >>>
>> >>> Scott
>> >>>
>> >>> [1] https://wiki.eclipse.org/ECF
>> >>> [2] https://wiki.eclipse.org/Distribution_Providers
>> >>> [3] https://github.com/ECF/JaxRSProviders
>> >>>
>> >>> On 8/15/2016 8:21 AM, Marc Durand wrote:
>> >>>>
>> >>>> Hello,
>> >>>> I was following Christian's tutorial here:
>> >>>>
>> >>>>
>> >>>> http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>> >>>>
>> >>>> And I also found come blog posts from JB that show how to deploy
>> >>>> RESTful
>> >>>> services using blueprint.
>> >>>>
>> >>>> What I couldn't find was an example on how to deploy a RESTful
>> >>>> service
>> >>>> where
>> >>>> the resource class is an OSGi service (to take advantage of SCR
>> >>>> references
>> >>>> to other services in the resource class).  I was able to do it by
>> >>>> using a
>> >>>>  element instead of a  element in the blueprint
>> >>>> file.  Is
>> >>>> this approach correct or will it lead to other problems down the
>> >>>> road?
>> >>>>
>> >>>> Thanks!
>> >>>> Marc
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> View this message in context:
>> >>>>
>> >>>> http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
>> >>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>> >>>
>> >>>
>> >>>
>> >
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com

Re: RESTful web service in Karaf using CXF and blueprint

[Benson Margulies]

Correct. I tried the dOSGi stuff, and it wasn't really ready to do
what I needed to do.

On Mon, Aug 15, 2016 at 1:17 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> Just to see if I understand what you are doing, this approach does not 
> involve the osgi service registry in any way for the REST service 
> implementation object?  You are directly registering the component instance 
> with CXF, and there is no need for it to expose any service interfaces at all?
>
> thanks
> david jencks
>
>> On Aug 15, 2016, at 10:10 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I do this by making DS @Activate methods call the CXF API to publish
>> REST services.
>>
>>
>> On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis <sle...@composent.com> wrote:
>>> Hi Marc,
>>>
>>> The OSGi Remote Services specification (and the associated Remote Service
>>> Admin sepc) defines a standardized way to export OSGi services for remote
>>> access.   The specification is defined in a way that allows the use of
>>> arbitrary distribution providers that are responsible for making the OSGi
>>> service accessible from outside of the OSGi process.
>>>
>>> ECF [1] has an implementation of these specs that supports many distribution
>>> providers [2], including two that I'm working on now that supports any
>>> Jax-RS implementation (i.e. both CXF and Jersey).   These two distribution
>>> providers are here [3] and I'm finalizing them for an initial release.
>>> Note that for these providers, in addition to specifying jax-rs resources
>>> via OSGi services, the jax-rs configuration (e.g. MessageBodyReader/Writers,
>>> Features, etc) can also be specified via OSGi services.
>>>
>>> Scott
>>>
>>> [1] https://wiki.eclipse.org/ECF
>>> [2] https://wiki.eclipse.org/Distribution_Providers
>>> [3] https://github.com/ECF/JaxRSProviders
>>>
>>> On 8/15/2016 8:21 AM, Marc Durand wrote:
>>>>
>>>> Hello,
>>>> I was following Christian's tutorial here:
>>>>
>>>> http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>>>>
>>>> And I also found come blog posts from JB that show how to deploy RESTful
>>>> services using blueprint.
>>>>
>>>> What I couldn't find was an example on how to deploy a RESTful service
>>>> where
>>>> the resource class is an OSGi service (to take advantage of SCR references
>>>> to other services in the resource class).  I was able to do it by using a
>>>>  element instead of a  element in the blueprint file.  Is
>>>> this approach correct or will it lead to other problems down the road?
>>>>
>>>> Thanks!
>>>> Marc
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
>>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>

Re: RESTful web service in Karaf using CXF and blueprint

[Benson Margulies]

I do this by making DS @Activate methods call the CXF API to publish
REST services.


On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis  wrote:
> Hi Marc,
>
> The OSGi Remote Services specification (and the associated Remote Service
> Admin sepc) defines a standardized way to export OSGi services for remote
> access.   The specification is defined in a way that allows the use of
> arbitrary distribution providers that are responsible for making the OSGi
> service accessible from outside of the OSGi process.
>
> ECF [1] has an implementation of these specs that supports many distribution
> providers [2], including two that I'm working on now that supports any
> Jax-RS implementation (i.e. both CXF and Jersey).   These two distribution
> providers are here [3] and I'm finalizing them for an initial release.
> Note that for these providers, in addition to specifying jax-rs resources
> via OSGi services, the jax-rs configuration (e.g. MessageBodyReader/Writers,
> Features, etc) can also be specified via OSGi services.
>
> Scott
>
> [1] https://wiki.eclipse.org/ECF
> [2] https://wiki.eclipse.org/Distribution_Providers
> [3] https://github.com/ECF/JaxRSProviders
>
> On 8/15/2016 8:21 AM, Marc Durand wrote:
>>
>> Hello,
>> I was following Christian's tutorial here:
>>
>> http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>>
>> And I also found come blog posts from JB that show how to deploy RESTful
>> services using blueprint.
>>
>> What I couldn't find was an example on how to deploy a RESTful service
>> where
>> the resource class is an OSGi service (to take advantage of SCR references
>> to other services in the resource class).  I was able to do it by using a
>>  element instead of a  element in the blueprint file.  Is
>> this approach correct or will it lead to other problems down the road?
>>
>> Thanks!
>> Marc
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
>

Re: How do mvn: urls end up in classpaths in Karaf 4.0.5?

[Benson Margulies]

One other factoid:

When I don't use "#methodname" to select a method, I do see a few of
these IllegalStateExceptions go by for things like configadmin and
sshd. They don't even result in log traffic. When I use the #, that
adds a guice jar file, and the result is a fail.


On Mon, Aug 15, 2016 at 10:34 AM, Benson Margulies <ben...@basistech.com> wrote:
> Folks,
>
> I just upgraded my build to use pax-exam 4.9.1. And I got a very
> strange problem.
>
> If I run a single function test method:
>
>   mvn 
> -Dit.test=com.basistech.ws.itest.AnvilsRealComponentIT"#complexEntityRouting"
>
> my code dies, because an mvn: URL leaks out.
>
> This happens when Guice is referencing one of its classes, and the
> class load fails.
>
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm
> throws an IllegalStateException due to getting an mvn: URL as the
> class source location. Does anyone have any clues as to what to look
> at here?
>
>
> java.lang.Thread.State: RUNNABLE
>  at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)
>  at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
>  at java.net.URL.toExternalForm(URL.java:922)
>  at java.net.URL.toString(URL.java:908)
>  at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:675)
>  at java.lang.ClassLoader.defineClass(ClassLoader.java:759)
>  at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)
>  at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)
>  at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)
>  at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>  at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>  at 
> com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:166)
>  at 
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
>  - locked <0x2409> (a com.google.inject.internal.InheritingState)
>  at com.google.inject.Guice.createInjector(Guice.java:96)
>  at com.google.inject.Guice.createInjector(Guice.java:73)
>  at com.google.inject.Guice.createInjector(Guice.java:62)
>  at 
> com.basistech.rosette.relax.RelationshipAnnotatorFactory.initializeInternal(RelationshipAnnotatorFactory.java:130)
>  - locked <0x23da> (a 
> com.basistech.rosette.relax.RelationshipAnnotatorFactory)
>  at 
> com.basistech.rosette.relax.RelationshipAnnotatorFactory.initialize(RelationshipAnnotatorFactory.java:111)
>  at 
> com.basistech.relax.osgi.impl.RelaxComponentService$Factory.(RelaxComponentService.java:121)
>  at 
> com.basistech.relax.osgi.impl.RelaxComponentService.createFactory(RelaxComponentService.java:85)
>  at 
> com.basistech.rosette.osgi.util.AbstractComponentService.createFactory(AbstractComponentService.java:47)
>  at 
> com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.configureOneFactory(AbstractWorkerDocumentComponentService.java:82)
>  at 
> com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.init(AbstractWorkerDocumentComponentService.java:57)
>  at com.basistech.ws.worker.core.Worker.configureComponent(Worker.java:223)
>  at com.basistech.ws.worker.core.Worker.lambda$activate$12(Worker.java:179)
>  a

How do mvn: urls end up in classpaths in Karaf 4.0.5?

[Benson Margulies]

Folks,

I just upgraded my build to use pax-exam 4.9.1. And I got a very
strange problem.

If I run a single function test method:

  mvn 
-Dit.test=com.basistech.ws.itest.AnvilsRealComponentIT"#complexEntityRouting"

my code dies, because an mvn: URL leaks out.

This happens when Guice is referencing one of its classes, and the
class load fails.

org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm
throws an IllegalStateException due to getting an mvn: URL as the
class source location. Does anyone have any clues as to what to look
at here?


java.lang.Thread.State: RUNNABLE
 at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)
 at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
 at java.net.URL.toExternalForm(URL.java:922)
 at java.net.URL.toString(URL.java:908)
 at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:675)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:759)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)
 at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)
 at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 at 
com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:166)
 at 
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
 - locked <0x2409> (a com.google.inject.internal.InheritingState)
 at com.google.inject.Guice.createInjector(Guice.java:96)
 at com.google.inject.Guice.createInjector(Guice.java:73)
 at com.google.inject.Guice.createInjector(Guice.java:62)
 at 
com.basistech.rosette.relax.RelationshipAnnotatorFactory.initializeInternal(RelationshipAnnotatorFactory.java:130)
 - locked <0x23da> (a com.basistech.rosette.relax.RelationshipAnnotatorFactory)
 at 
com.basistech.rosette.relax.RelationshipAnnotatorFactory.initialize(RelationshipAnnotatorFactory.java:111)
 at 
com.basistech.relax.osgi.impl.RelaxComponentService$Factory.(RelaxComponentService.java:121)
 at 
com.basistech.relax.osgi.impl.RelaxComponentService.createFactory(RelaxComponentService.java:85)
 at 
com.basistech.rosette.osgi.util.AbstractComponentService.createFactory(AbstractComponentService.java:47)
 at 
com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.configureOneFactory(AbstractWorkerDocumentComponentService.java:82)
 at 
com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.init(AbstractWorkerDocumentComponentService.java:57)
 at com.basistech.ws.worker.core.Worker.configureComponent(Worker.java:223)
 at com.basistech.ws.worker.core.Worker.lambda$activate$12(Worker.java:179)
 a

Re: transitive dependencies of feature descriptors

[Benson Margulies]

On Fri, Aug 5, 2016 at 8:41 AM, Daniel McGreal <d.j.mcgr...@gmail.com>
wrote:

> Hi,
> I tend to prefer setting scope of the dependencies to ‘provided’, either
> in the 'aggregator’ or by using dependencyManagement in features. This
> means you can stack the features files without having to re-exclude the
> transitives you’re not interested in.
> Best, Dan.
>

I'm experimenting with this. it can get a little messy when someone else
has done a bad job on the same task.

If some OSGi bundle has a mixture of OSGi and non-OSGi dependencies (and
I've seen this in servicemix), and I mark it provided, I have to then
redeclare the OSGi dependences at scope compile. It may be the least messy
solution.

thanks.




>
> On 5 Aug 2016, at 13:33, Benson Margulies <ben...@basistech.com> wrote:
>
>
>
> On Fri, Aug 5, 2016 at 8:32 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
>
>> You mean that you use the karaf-maven-plugin to generate the features.xml
>> ?
>>
>
> JB,
>
> Yes, I always use the plugin.
> Regards, benson
>
>
>
>>
>> Regards
>> JB
>>
>> On 08/05/2016 02:28 PM, Benson Margulies wrote:
>>
>>> JB,
>>>
>>> The jar files incorporated in the uber jar show up in the dependency
>>> graph and thus reappear in as 'wrap:' bundles in features.
>>>
>>> If project X declares a dependency on feature F, then the dependencies
>>> of feature F are considered as bundles in project X's feature, because
>>> they are part of project X's overall dependency graph. the
>>> karaf-maven-plugin does not filter them out, even though F is accounted
>>> for as an aggregated feature.
>>>
>>> Regards,
>>> benson
>>>
>>>
>>> On Fri, Aug 5, 2016 at 8:09 AM, Jean-Baptiste Onofré <j...@nanthrax.net
>>> <mailto:j...@nanthrax.net>> wrote:
>>>
>>> Hi Benson,
>>>
>>> honestly, I don't understand your point ;)
>>>
>>> You have an "uber" bundle containing packages, and this bundle is in
>>> a feature.
>>>
>>> This feature can be used as an inner feature.
>>>
>>> So what's the point ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/05/2016 02:03 PM, Benson Margulies wrote:
>>>
>>> Folks, I wonder if someone else has found a way out of this.
>>>
>>> Consider a project that builds an OSGi bundle by aggregating some
>>> non-OSGi jar Maven dependencies. Those dependencies are in the
>>> dependency tree of the resulting bundle.
>>>
>>> Now, consider what happens if you generate a feature to contain
>>> that
>>> bundle. You can carefully exclude artifactIds to ensure that
>>> these
>>> embedded jars do not show up in the feature.xml as 'wrap'
>>> bundles.
>>>
>>> However, there are still in the dependency graph of the feature
>>> itself.
>>>
>>> So, when you write a dependency _on the feature_ to incorporate
>>> that
>>> feature in a larger system, now the non-OSGi bundles are back in
>>> the
>>> picture. You then have to write Maven  for them all
>>> over again.
>>>
>>> If I wrote a patch to the karaf-maven-plugin to exclude
>>> non-feature
>>> dependencies of features, would some committer commit it?
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org <mailto:jbono...@apache.org>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

Re: transitive dependencies of feature descriptors

[Benson Margulies]

On Fri, Aug 5, 2016 at 8:32 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> You mean that you use the karaf-maven-plugin to generate the features.xml ?
>

JB,

Yes, I always use the plugin.
Regards, benson



>
> Regards
> JB
>
> On 08/05/2016 02:28 PM, Benson Margulies wrote:
>
>> JB,
>>
>> The jar files incorporated in the uber jar show up in the dependency
>> graph and thus reappear in as 'wrap:' bundles in features.
>>
>> If project X declares a dependency on feature F, then the dependencies
>> of feature F are considered as bundles in project X's feature, because
>> they are part of project X's overall dependency graph. the
>> karaf-maven-plugin does not filter them out, even though F is accounted
>> for as an aggregated feature.
>>
>> Regards,
>> benson
>>
>>
>> On Fri, Aug 5, 2016 at 8:09 AM, Jean-Baptiste Onofré <j...@nanthrax.net
>> <mailto:j...@nanthrax.net>> wrote:
>>
>> Hi Benson,
>>
>> honestly, I don't understand your point ;)
>>
>> You have an "uber" bundle containing packages, and this bundle is in
>> a feature.
>>
>> This feature can be used as an inner feature.
>>
>> So what's the point ?
>>
>> Regards
>> JB
>>
>>
>> On 08/05/2016 02:03 PM, Benson Margulies wrote:
>>
>> Folks, I wonder if someone else has found a way out of this.
>>
>> Consider a project that builds an OSGi bundle by aggregating some
>> non-OSGi jar Maven dependencies. Those dependencies are in the
>> dependency tree of the resulting bundle.
>>
>> Now, consider what happens if you generate a feature to contain
>> that
>> bundle. You can carefully exclude artifactIds to ensure that these
>> embedded jars do not show up in the feature.xml as 'wrap' bundles.
>>
>> However, there are still in the dependency graph of the feature
>> itself.
>>
>> So, when you write a dependency _on the feature_ to incorporate
>> that
>> feature in a larger system, now the non-OSGi bundles are back in
>> the
>> picture. You then have to write Maven  for them all
>> over again.
>>
>> If I wrote a patch to the karaf-maven-plugin to exclude
>> non-feature
>> dependencies of features, would some committer commit it?
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org <mailto:jbono...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: transitive dependencies of feature descriptors

[Benson Margulies]

JB,

The jar files incorporated in the uber jar show up in the dependency graph
and thus reappear in as 'wrap:' bundles in features.

If project X declares a dependency on feature F, then the dependencies of
feature F are considered as bundles in project X's feature, because they
are part of project X's overall dependency graph. the karaf-maven-plugin
does not filter them out, even though F is accounted for as an aggregated
feature.

Regards,
benson


On Fri, Aug 5, 2016 at 8:09 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Hi Benson,
>
> honestly, I don't understand your point ;)
>
> You have an "uber" bundle containing packages, and this bundle is in a
> feature.
>
> This feature can be used as an inner feature.
>
> So what's the point ?
>
> Regards
> JB
>
>
> On 08/05/2016 02:03 PM, Benson Margulies wrote:
>
>> Folks, I wonder if someone else has found a way out of this.
>>
>> Consider a project that builds an OSGi bundle by aggregating some
>> non-OSGi jar Maven dependencies. Those dependencies are in the
>> dependency tree of the resulting bundle.
>>
>> Now, consider what happens if you generate a feature to contain that
>> bundle. You can carefully exclude artifactIds to ensure that these
>> embedded jars do not show up in the feature.xml as 'wrap' bundles.
>>
>> However, there are still in the dependency graph of the feature itself.
>>
>> So, when you write a dependency _on the feature_ to incorporate that
>> feature in a larger system, now the non-OSGi bundles are back in the
>> picture. You then have to write Maven  for them all over
>> again.
>>
>> If I wrote a patch to the karaf-maven-plugin to exclude non-feature
>> dependencies of features, would some committer commit it?
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

transitive dependencies of feature descriptors

[Benson Margulies]

Folks, I wonder if someone else has found a way out of this.

Consider a project that builds an OSGi bundle by aggregating some non-OSGi
jar Maven dependencies. Those dependencies are in the dependency tree of
the resulting bundle.

Now, consider what happens if you generate a feature to contain that
bundle. You can carefully exclude artifactIds to ensure that these embedded
jars do not show up in the feature.xml as 'wrap' bundles.

However, there are still in the dependency graph of the feature itself.

So, when you write a dependency _on the feature_ to incorporate that
feature in a larger system, now the non-OSGi bundles are back in the
picture. You then have to write Maven  for them all over again.

If I wrote a patch to the karaf-maven-plugin to exclude non-feature
dependencies of features, would some committer commit it?

Re: More entropy on bundle startup.

[Benson Margulies]

We use DS for most of our services, but we have a few down at the
activator level.

I appreciate that the fixes to the bugs involve service tracking. The
problem is _finding_ the bugs.

Yes we use featuresBoot.

featuresBootAsynchronous=false



On Thu, Jul 14, 2016 at 9:56 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> You are using featuresBoot?  Do you have featuresBootAsynchronous=false in
> your org.apache.karaf.features.cfg file?
>
>
> On Thu, Jul 14, 2016 at 9:33 AM Benson Margulies <ben...@basistech.com>
> wrote:
>>
>> I don't think so, no. I do not do any dynamic installation. I use the
>> Maven plugin to make an assembly with all the features I need. I then
>> observe that the startup order is not deterministic from machine to
>> machine, and it is particularly prone to change when I stop and start
>> the container without clearing out the data directory.
>>
>>
>> On Thu, Jul 14, 2016 at 1:39 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>> > Hi Benson,
>> >
>> > I guess you are using the deploy folder, so the fileinstall deployer,
>> > right
>> > ?
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 07/13/2016 10:56 PM, Benson Margulies wrote:
>> >>
>> >> Folks,
>> >>
>> >> We've had a couple of incidents of latent problems stemming from
>> >> invalid assumptions on bundle start order. Everything seems to be
>> >> fine, then some trivial change reveals that we've failed to ensure
>> >> that service 'a' is available before component 'b' needs it. by and
>> >> large, we use DS to get this right, but there are a few cases where it
>> >> does not serve.
>> >>
>> >> I am wondering: is there some way to get _more_ randomness out of the
>> >> startup process, to shake out mistakes like this?
>> >>
>> >> thanks,
>> >> benson
>> >>
>> >
>> > --
>> > Jean-Baptiste Onofré
>> > jbono...@apache.org
>> > http://blog.nanthrax.net
>> > Talend - http://www.talend.com

Re: More entropy on bundle startup.

[Benson Margulies]

I don't think so, no. I do not do any dynamic installation. I use the
Maven plugin to make an assembly with all the features I need. I then
observe that the startup order is not deterministic from machine to
machine, and it is particularly prone to change when I stop and start
the container without clearing out the data directory.


On Thu, Jul 14, 2016 at 1:39 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Hi Benson,
>
> I guess you are using the deploy folder, so the fileinstall deployer, right
> ?
>
> Regards
> JB
>
>
> On 07/13/2016 10:56 PM, Benson Margulies wrote:
>>
>> Folks,
>>
>> We've had a couple of incidents of latent problems stemming from
>> invalid assumptions on bundle start order. Everything seems to be
>> fine, then some trivial change reveals that we've failed to ensure
>> that service 'a' is available before component 'b' needs it. by and
>> large, we use DS to get this right, but there are a few cases where it
>> does not serve.
>>
>> I am wondering: is there some way to get _more_ randomness out of the
>> startup process, to shake out mistakes like this?
>>
>> thanks,
>> benson
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

More entropy on bundle startup.

[Benson Margulies]

Folks,

We've had a couple of incidents of latent problems stemming from
invalid assumptions on bundle start order. Everything seems to be
fine, then some trivial change reveals that we've failed to ensure
that service 'a' is available before component 'b' needs it. by and
large, we use DS to get this right, but there are a few cases where it
does not serve.

I am wondering: is there some way to get _more_ randomness out of the
startup process, to shake out mistakes like this?

thanks,
benson

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

SIgh. I can't repro the problem that's interesting to you, and the
more CXF-ish problem  needs to be chased at CXF.


On Wed, Jul 6, 2016 at 12:29 PM, Benson Margulies <ben...@basistech.com> wrote:
> If I can repro it, I'll endeavor to produce.
>
>
> On Wed, Jul 6, 2016 at 12:25 PM, David Jencks <david.a.jen...@gmail.com> 
> wrote:
>> I’m wondering what the DS implementation bundle is getting it’s Config Admin 
>> packages from in each case.
>>
>> thanks
>> david jencks
>>
>>> On Jul 6, 2016, at 9:20 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> I can dump a bunch of wiring. But I'd have to repro the problem.
>>> which, after being quite reproducible for some time, has gone into
>>> hiding to be replaced by a different problem. Just what bundle's
>>> wiring are you interested in?
>>>
>>>
>>> On Wed, Jul 6, 2016 at 12:18 PM, David Jencks <david.a.jen...@gmail.com> 
>>> wrote:
>>>> There has been another report of a similar problem that I haven’t been 
>>>> able to reproduce (outside karaf).  Does Karaf provide any way of looking 
>>>> at the bundle wiring?  I’d like to see how the DS bundle is wired in the 
>>>> working and non working cases.  I’m wondering if in the non working case 
>>>> DS gets wired correctly to config admin.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>> On Jul 6, 2016, at 9:10 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>>
>>>>> com.basistech.worker.service.cfg exists.
>>>>>
>>>>> And when I stopped and started karaf, the component got itself activated.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks <david.a.jen...@gmail.com> 
>>>>> wrote:
>>>>>> You have configuration policy require and there is no component 
>>>>>> configuration shown, so the configuration is missing.
>>>>>>
>>>>>> If at least one matching configuration were available to DS you’d see 
>>>>>> one component configuration for each configuration, and then you could 
>>>>>> tell if the references were satisfied or not from the references section 
>>>>>> of the component configuration.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies <ben...@basistech.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>>>>>> clues?
>>>>>>>
>>>>>>>
>>>>>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>>>>>> Component Details
>>>>>>> Name: com.basistech.ws.worker.service.WorkerService
>>>>>>> State   : UNSATISFIED
>>>>>>> Properties  :
>>>>>>>  service=worker
>>>>>>> References
>>>>>>>
>>>>>>> -
>>>>>>>
>>>>>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>>>>>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>>>>>>> Component Description:
>>>>>>> Name: com.basistech.ws.worker.service.WorkerService
>>>>>>> Default State: enabled
>>>>>>> Activation: immediate
>>>>>>> Configuration Policy: require
>>>>>>> Activate Method: activate
>>>>>>> Deactivate Method: deactivate
>>>>>>> Modified Method: -
>>>>>>> Configuration Pid: [com.basistech.worker.service]
>>>>>>> Services:
>>>>>>>com.basistech.ws.common.WebServiceAvailable
>>>>>>> Service Scope: singleton
>>>>>>> Reference: CxfTransport
>>>>>>>  Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>>>>>>  Cardinality: 1..1
>>>>>>>  Policy: static
>>>>>>>  Policy option: reluctant
>>>>>>>  Reference Scope: bundle
>>>>>>> Reference: Metrics
>>>>>>>  Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>>>>>>  Cardinality: 1..1
>>>>>>>  Policy: static
>>>>>>>  Policy option: reluctant
>>>>>>>  Reference Scope: bundle
>>>>>>> Reference: Worker
>>>>>>>  Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>>>>>>  Cardinality: 1..1
>>>>>>>  Policy: static
>>>>>>>  Policy option: reluctant
>>>>>>>  Reference Scope: bundle
>>>>>>> Properties:
>>>>>>>  service = worker
>>>>>>
>>>>
>>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

If I can repro it, I'll endeavor to produce.


On Wed, Jul 6, 2016 at 12:25 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> I’m wondering what the DS implementation bundle is getting it’s Config Admin 
> packages from in each case.
>
> thanks
> david jencks
>
>> On Jul 6, 2016, at 9:20 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I can dump a bunch of wiring. But I'd have to repro the problem.
>> which, after being quite reproducible for some time, has gone into
>> hiding to be replaced by a different problem. Just what bundle's
>> wiring are you interested in?
>>
>>
>> On Wed, Jul 6, 2016 at 12:18 PM, David Jencks <david.a.jen...@gmail.com> 
>> wrote:
>>> There has been another report of a similar problem that I haven’t been able 
>>> to reproduce (outside karaf).  Does Karaf provide any way of looking at the 
>>> bundle wiring?  I’d like to see how the DS bundle is wired in the working 
>>> and non working cases.  I’m wondering if in the non working case DS gets 
>>> wired correctly to config admin.
>>>
>>> thanks
>>> david jencks
>>>
>>>> On Jul 6, 2016, at 9:10 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> com.basistech.worker.service.cfg exists.
>>>>
>>>> And when I stopped and started karaf, the component got itself activated.
>>>>
>>>>
>>>>
>>>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks <david.a.jen...@gmail.com> 
>>>> wrote:
>>>>> You have configuration policy require and there is no component 
>>>>> configuration shown, so the configuration is missing.
>>>>>
>>>>> If at least one matching configuration were available to DS you’d see one 
>>>>> component configuration for each configuration, and then you could tell 
>>>>> if the references were satisfied or not from the references section of 
>>>>> the component configuration.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies <ben...@basistech.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>>>>> clues?
>>>>>>
>>>>>>
>>>>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>>>>> Component Details
>>>>>> Name: com.basistech.ws.worker.service.WorkerService
>>>>>> State   : UNSATISFIED
>>>>>> Properties  :
>>>>>>  service=worker
>>>>>> References
>>>>>>
>>>>>> -
>>>>>>
>>>>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>>>>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>>>>>> Component Description:
>>>>>> Name: com.basistech.ws.worker.service.WorkerService
>>>>>> Default State: enabled
>>>>>> Activation: immediate
>>>>>> Configuration Policy: require
>>>>>> Activate Method: activate
>>>>>> Deactivate Method: deactivate
>>>>>> Modified Method: -
>>>>>> Configuration Pid: [com.basistech.worker.service]
>>>>>> Services:
>>>>>>com.basistech.ws.common.WebServiceAvailable
>>>>>> Service Scope: singleton
>>>>>> Reference: CxfTransport
>>>>>>  Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>>>>>  Cardinality: 1..1
>>>>>>  Policy: static
>>>>>>  Policy option: reluctant
>>>>>>  Reference Scope: bundle
>>>>>> Reference: Metrics
>>>>>>  Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>>>>>  Cardinality: 1..1
>>>>>>  Policy: static
>>>>>>  Policy option: reluctant
>>>>>>  Reference Scope: bundle
>>>>>> Reference: Worker
>>>>>>  Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>>>>>  Cardinality: 1..1
>>>>>>  Policy: static
>>>>>>  Policy option: reluctant
>>>>>>  Reference Scope: bundle
>>>>>> Properties:
>>>>>>  service = worker
>>>>>
>>>
>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

It's the same karaf. I fear that in Karaf 4.0.4 there is a coin being
flipped to decide which set of gogo commands to use. I do not know how
to get Karaf to use the real SCR command and not its own by changing
what I type, maybe there's a way. It's another bundle start order
business.



On Wed, Jul 6, 2016 at 12:24 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> Is that the same karaf?  The first scr:list looks like the new format and the 
> second like the really old format.  There have been some shenanigans where 
> karaf thought they knew better than DS how to write a gogo command, so maybe 
> only the command is the wrong one rather than the DS implementation, but 
> something appears really different on restart.
>
> david jencks
>
>> On Jul 6, 2016, at 9:18 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> Here's how I got into this.
>>
>> I have this Karaf assembly. If I start if just after it is built, it
>> works fine. If I stop and restart it, it fails, because the CXF HTTP
>> transport does not start in time.
>>
>> So, I added @References to ensure that the transport starts first.
>> Then, I hit the problem reported in this thread: a component refuses
>> to start for lack of a configuration pid whose file is sitting right
>> there.
>>
>> If I delete the karaf data directory again, everything is fine.
>>
>> scr:list goes:
>>
>> karaf@root>scr:list
>> BundleId Component Name Default State
>>Component Id State  PIDs (Factory PID)
>> [  44]   com.basistech.ws.common.InitializeS3FSService  enabled
>>[   1] [active  ]
>> [  44]   com.basistech.ws.common.metrics.MetricsRegistryServiceImpl  enabled
>>[   2] [active  ] com.basistech.ws.metrics
>> [  45]   com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
>> enabled
>>[  19] [active  ] com.basistech.ws.transport.http
>> ...
>>
>>
>> If I stop and start again,
>>
>> scr:list switches format to:
>>
>> karaf@root>scr:list
>> ID | State   | Component Name
>> ---
>> -1 | UNSATISFIED |
>> com.basistech.ws.logstashrequesttracker.impl.LogstashRequestTracker
>> 1  | ACTIVE  | com.basistech.ws.common.InitializeS3FSService
>> 2  | ACTIVE  | com.basistech.ws.common.metrics.MetricsRegistryServiceImpl
>> 3  | ACTIVE  |
>> com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
>> 4  | ACTIVE  |
>> com.basistech.ws.frontend.transport.anvils.impl.RosapiDnsResolver
>> 5  | ACTIVE  | com.basistech.ws.embeddedworker.impl.EmbeddedTransport
>> 6  | ACTIVE  | com.basistech.ws.usage.impl.LocalUsageTracker
>> ...
>>
>> (That first component is supposed to be unsatisfied) All my components
>> appear to be alive.
>>
>> and
>>
>> But a swath of my CXF services stop working, even though their
>> components are activated and they have made the call to start the
>> service.
>>
>>
>> On Wed, Jul 6, 2016 at 12:10 PM, Benson Margulies <ben...@basistech.com> 
>> wrote:
>>> com.basistech.worker.service.cfg exists.
>>>
>>> And when I stopped and started karaf, the component got itself activated.
>>>
>>>
>>>
>>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks <david.a.jen...@gmail.com> 
>>> wrote:
>>>> You have configuration policy require and there is no component 
>>>> configuration shown, so the configuration is missing.
>>>>
>>>> If at least one matching configuration were available to DS you’d see one 
>>>> component configuration for each configuration, and then you could tell if 
>>>> the references were satisfied or not from the references section of the 
>>>> component configuration.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>>
>>>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>>>> clues?
>>>>>
>>>>>
>>>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>>>> Component Details
>>>>> Name: com.basistech.ws.worker.service.WorkerService
>>>>> State   : UNSATISFIED
>>>>> Properties  :
>>>>>   service=worker
>>>&g

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

I can dump a bunch of wiring. But I'd have to repro the problem.
which, after being quite reproducible for some time, has gone into
hiding to be replaced by a different problem. Just what bundle's
wiring are you interested in?


On Wed, Jul 6, 2016 at 12:18 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> There has been another report of a similar problem that I haven’t been able 
> to reproduce (outside karaf).  Does Karaf provide any way of looking at the 
> bundle wiring?  I’d like to see how the DS bundle is wired in the working and 
> non working cases.  I’m wondering if in the non working case DS gets wired 
> correctly to config admin.
>
> thanks
> david jencks
>
>> On Jul 6, 2016, at 9:10 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> com.basistech.worker.service.cfg exists.
>>
>> And when I stopped and started karaf, the component got itself activated.
>>
>>
>>
>> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks <david.a.jen...@gmail.com> 
>> wrote:
>>> You have configuration policy require and there is no component 
>>> configuration shown, so the configuration is missing.
>>>
>>> If at least one matching configuration were available to DS you’d see one 
>>> component configuration for each configuration, and then you could tell if 
>>> the references were satisfied or not from the references section of the 
>>> component configuration.
>>>
>>> thanks
>>> david jencks
>>>
>>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>>> clues?
>>>>
>>>>
>>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>>> Component Details
>>>> Name: com.basistech.ws.worker.service.WorkerService
>>>> State   : UNSATISFIED
>>>> Properties  :
>>>>   service=worker
>>>> References
>>>>
>>>> -
>>>>
>>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>>>> Component Description:
>>>> Name: com.basistech.ws.worker.service.WorkerService
>>>> Default State: enabled
>>>> Activation: immediate
>>>> Configuration Policy: require
>>>> Activate Method: activate
>>>> Deactivate Method: deactivate
>>>> Modified Method: -
>>>> Configuration Pid: [com.basistech.worker.service]
>>>> Services:
>>>> com.basistech.ws.common.WebServiceAvailable
>>>> Service Scope: singleton
>>>> Reference: CxfTransport
>>>>   Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>>>   Cardinality: 1..1
>>>>   Policy: static
>>>>   Policy option: reluctant
>>>>   Reference Scope: bundle
>>>> Reference: Metrics
>>>>   Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>>>   Cardinality: 1..1
>>>>   Policy: static
>>>>   Policy option: reluctant
>>>>   Reference Scope: bundle
>>>> Reference: Worker
>>>>   Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>>>   Cardinality: 1..1
>>>>   Policy: static
>>>>   Policy option: reluctant
>>>>   Reference Scope: bundle
>>>> Properties:
>>>>   service = worker
>>>
>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

Here's how I got into this.

I have this Karaf assembly. If I start if just after it is built, it
works fine. If I stop and restart it, it fails, because the CXF HTTP
transport does not start in time.

So, I added @References to ensure that the transport starts first.
Then, I hit the problem reported in this thread: a component refuses
to start for lack of a configuration pid whose file is sitting right
there.

If I delete the karaf data directory again, everything is fine.

scr:list goes:

karaf@root>scr:list
 BundleId Component Name Default State
Component Id State  PIDs (Factory PID)
 [  44]   com.basistech.ws.common.InitializeS3FSService  enabled
[   1] [active  ]
 [  44]   com.basistech.ws.common.metrics.MetricsRegistryServiceImpl  enabled
[   2] [active  ] com.basistech.ws.metrics
 [  45]   com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
 enabled
[  19] [active  ] com.basistech.ws.transport.http
...


If I stop and start again,

scr:list switches format to:

karaf@root>scr:list
ID | State   | Component Name
---
-1 | UNSATISFIED |
com.basistech.ws.logstashrequesttracker.impl.LogstashRequestTracker
1  | ACTIVE  | com.basistech.ws.common.InitializeS3FSService
2  | ACTIVE  | com.basistech.ws.common.metrics.MetricsRegistryServiceImpl
3  | ACTIVE  |
com.basistech.ws.frontend.transport.anvils.impl.AnvilsTransportImpl
4  | ACTIVE  |
com.basistech.ws.frontend.transport.anvils.impl.RosapiDnsResolver
5  | ACTIVE  | com.basistech.ws.embeddedworker.impl.EmbeddedTransport
6  | ACTIVE  | com.basistech.ws.usage.impl.LocalUsageTracker
...

(That first component is supposed to be unsatisfied) All my components
appear to be alive.

and

But a swath of my CXF services stop working, even though their
components are activated and they have made the call to start the
service.


On Wed, Jul 6, 2016 at 12:10 PM, Benson Margulies <ben...@basistech.com> wrote:
> com.basistech.worker.service.cfg exists.
>
> And when I stopped and started karaf, the component got itself activated.
>
>
>
> On Wed, Jul 6, 2016 at 12:01 PM, David Jencks <david.a.jen...@gmail.com> 
> wrote:
>> You have configuration policy require and there is no component 
>> configuration shown, so the configuration is missing.
>>
>> If at least one matching configuration were available to DS you’d see one 
>> component configuration for each configuration, and then you could tell if 
>> the references were satisfied or not from the references section of the 
>> component configuration.
>>
>> thanks
>> david jencks
>>
>>> On Jul 6, 2016, at 8:52 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>>> clues?
>>>
>>>
>>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>>> Component Details
>>>  Name: com.basistech.ws.worker.service.WorkerService
>>>  State   : UNSATISFIED
>>>  Properties  :
>>>service=worker
>>> References
>>>
>>> -
>>>
>>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>>> Component Description:
>>>  Name: com.basistech.ws.worker.service.WorkerService
>>>  Default State: enabled
>>>  Activation: immediate
>>>  Configuration Policy: require
>>>  Activate Method: activate
>>>  Deactivate Method: deactivate
>>>  Modified Method: -
>>>  Configuration Pid: [com.basistech.worker.service]
>>>  Services:
>>>  com.basistech.ws.common.WebServiceAvailable
>>>  Service Scope: singleton
>>>  Reference: CxfTransport
>>>Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>>Cardinality: 1..1
>>>Policy: static
>>>Policy option: reluctant
>>>Reference Scope: bundle
>>>  Reference: Metrics
>>>Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>>Cardinality: 1..1
>>>Policy: static
>>>Policy option: reluctant
>>>Reference Scope: bundle
>>>  Reference: Worker
>>>Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>>Cardinality: 1..1
>>>Policy: static
>>>Policy option: reluctant
>>>Reference Scope: bundle
>>>  Properties:
>>>service = worker
>>

Re: What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

com.basistech.worker.service.cfg exists.

And when I stopped and started karaf, the component got itself activated.



On Wed, Jul 6, 2016 at 12:01 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> You have configuration policy require and there is no component configuration 
> shown, so the configuration is missing.
>
> If at least one matching configuration were available to DS you’d see one 
> component configuration for each configuration, and then you could tell if 
> the references were satisfied or not from the references section of the 
> component configuration.
>
> thanks
> david jencks
>
>> On Jul 6, 2016, at 8:52 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> Folks, I have a service that isn't starting, and  I cannot see why. Any 
>> clues?
>>
>>
>> karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
>> Component Details
>>  Name: com.basistech.ws.worker.service.WorkerService
>>  State   : UNSATISFIED
>>  Properties  :
>>service=worker
>> References
>>
>> -
>>
>> karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
>> *** Bundle: com.basistech.ws.rosapi-worker-service (144)
>> Component Description:
>>  Name: com.basistech.ws.worker.service.WorkerService
>>  Default State: enabled
>>  Activation: immediate
>>  Configuration Policy: require
>>  Activate Method: activate
>>  Deactivate Method: deactivate
>>  Modified Method: -
>>  Configuration Pid: [com.basistech.worker.service]
>>  Services:
>>  com.basistech.ws.common.WebServiceAvailable
>>  Service Scope: singleton
>>  Reference: CxfTransport
>>Interface Name: org.apache.cxf.transport.http.DestinationRegistry
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: Metrics
>>Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: Worker
>>Interface Name: com.basistech.ws.worker.api.WorkerInterface
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Properties:
>>service = worker
>

What does it mean when scr:details says 'UNSATISFIED' and nothing else?

[Benson Margulies]

Folks, I have a service that isn't starting, and  I cannot see why. Any clues?


karaf@root>scr:details com.basistech.ws.worker.service.WorkerService
Component Details
  Name: com.basistech.ws.worker.service.WorkerService
  State   : UNSATISFIED
  Properties  :
service=worker
References

-

karaf@root>scr:info com.basistech.ws.worker.service.WorkerService
*** Bundle: com.basistech.ws.rosapi-worker-service (144)
Component Description:
  Name: com.basistech.ws.worker.service.WorkerService
  Default State: enabled
  Activation: immediate
  Configuration Policy: require
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.worker.service]
  Services:
  com.basistech.ws.common.WebServiceAvailable
  Service Scope: singleton
  Reference: CxfTransport
Interface Name: org.apache.cxf.transport.http.DestinationRegistry
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: Metrics
Interface Name: com.basistech.ws.common.metrics.MetricsRegistryService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: Worker
Interface Name: com.basistech.ws.worker.api.WorkerInterface
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Properties:
service = worker

Re: JAX-RS Annotations and Apache Karaf 4.0.5

[Benson Margulies]

I have a ton of working JAX-RS in 4.0.4 with CXF 3.1.x. I didn't see
the start of this thread. What's the problem?


On Fri, Jul 1, 2016 at 1:12 PM, Markus Rathgeb  wrote:
> Hi Scott,
>
> my knowledge about ECF, CXF, JAX-RS is very very small.
> In the past I need to get the OSGi JAX-RS of hstaudacher working in
> Karaf (at least to support Karaf Features for the Eclipse SmartHome
> project and openHAB etc.). The projects already exist and already use
> JAX-RS.
> I started using the stuff hstaudacher provides, but I was not happy as
> I realized that he creates bundles that are just a collection of a lot
> of other bundles.
>
> I don't know the pro and cons of the different projects and ATM its
> nothing I need to care.
> The only thing I want to state is if Artur needs to use JAX-RS, he can
> have a look at the Karaf feature and the work I have already done.
>
> And last but not least, I assume that the hstaudacher does not really
> work on JAX-RS anymore.

Re: Can't start assembly twice -- CXF bundle dependency management

[Benson Margulies]

On Mon, Jun 13, 2016 at 1:47 PM, Benson Margulies <ben...@basistech.com>
wrote:

> Folks,
>
> Using Karaf 4.0.4, I've managed to create an assembly with a problem. The
> problem is that it cannot be started more than once without emptying the
> data directory.
>
> This assembly is has several closely related assemblies that don't exhibit
> this pathology, and, in fact, this one didn't until recently. I suspect
> that some work I did to DRY up some feature specs is the cause.
>
> The symptom is that CXF fails to start up a service, claiming that the
> HTTP transport is missing. I've asked the CXF list for any ideas as to what
> would cause CXF to fail to find the transport. I'm a bit curious about the
> possibility that I've somehow created a bundle dependency order issue.
>
> The failure happens when a DS component fails to create a CXF service in
> its activate method. If the activate method were being called somehow
> before enough CXF bundles were started, that would do it.
>
> Do Karaf feature dependencies effect bundle startup order?
>

I've learned something about this.

I caused this problem as follows:

In my assemblies, I had a long list of  elements, duplicated from
assembly to assembly. To clean this up, I created a feature that simply
aggregated that list (splitting it into a few sublists), and then replaced
the long list in the plugin configuration with the short list.

This seems to have consequences for ordering. I was able to mitigate these
consequences in part by adding some 'prerequisite' declarations.

Can't start assembly twice -- CXF bundle dependency management

[Benson Margulies]

Folks,

Using Karaf 4.0.4, I've managed to create an assembly with a problem. The
problem is that it cannot be started more than once without emptying the
data directory.

This assembly is has several closely related assemblies that don't exhibit
this pathology, and, in fact, this one didn't until recently. I suspect
that some work I did to DRY up some feature specs is the cause.

The symptom is that CXF fails to start up a service, claiming that the HTTP
transport is missing. I've asked the CXF list for any ideas as to what
would cause CXF to fail to find the transport. I'm a bit curious about the
possibility that I've somehow created a bundle dependency order issue.

The failure happens when a DS component fails to create a CXF service in
its activate method. If the activate method were being called somehow
before enough CXF bundles were started, that would do it.

Do Karaf feature dependencies effect bundle startup order?

Re: Slf4j usage in a library

[Benson Margulies]

On Thu, Jun 2, 2016 at 10:34 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> It's probably the cleanest approach, agreed.
>
> Regards
> JB ut a modified version (i.e.
>> OSGi-aware) of FileSystemProvider class in the endorsed library so that
>> it can leverage FileSystemProviders registered as OSGi services.  That's
>> what we usually do for other specs, so not sure why this one would be
>> different.

That's sort of what my thread on the servicemix list is about, no? Is
this something Karaf would do, or would it want to get it from SM?

I could take a run at building it either way. I've never made one of
these. How do we deal with the licensing problem that any replacement
is prone to be a derived work of code with an unfriendly license?
(maybe that question really belongs on SM?)




>>
>> 2016-06-02 16:22 GMT+02:00 Guillaume Nodet <gno...@apache.org
>> <mailto:gno...@apache.org>>:
>>
>> It should be safe if you don't export the packages.  They will be
>> available from the system class loader, but they won't be available
>> to bundles if they are not exported by the system bundle.
>>
>> 2016-06-02 16:02 GMT+02:00 Benson Margulies <ben...@basistech.com
>> <mailto:ben...@basistech.com>>:
>>
>> On Thu, Jun 2, 2016 at 12:20 AM, Jean-Baptiste Onofré
>> <j...@nanthrax.net <mailto:j...@nanthrax.net>> wrote:
>> > Hi Benson,
>> >
>> > slf4j packages are provided by pax-logging-service bundle
>> (defined in
>> > etc/startup.properties), not by library.
>> >
>> > So, in your case, you should not use library, but more bundle
>> definition in
>> > etc/startup.properties after pax-logging-service (as you can do
>> for a custom
>> > appender).
>>
>> JB, could you help me understand how that can work for my
>> particular case?
>>
>> My goal here is to add an NIO2 file system provider that is part
>> of
>> the list of installed providers. Only the installed providers
>> are used
>> for calls to Paths.get(URI).  The code in the JRE that loads up
>> the
>> list of installed providers searches for SPI files using the
>> system
>> classloader, not the TCCL or some other classloader. So, in this
>> regard, it seemed to me that an FS provider was much like a JDBC
>> driver (as per the example of how/why to use a  in
>> doc). So I
>> don't think that putting it into a bundle at all will work.
>>
>>     However, I would be very happy to be wrong. Is there something
>> about
>> java.lang.ClassLoader#getSystemClassLoader inside Karaf that I
>> don't
>> know?
>>
>> Regards,
>> benson
>>
>>
>>
>>  >
>>  > Regards
>>  > JB
>>  >
>>  >
>>  > On 06/01/2016 08:02 PM, Benson Margulies wrote:
>>  >>
>>  >> Hello there.
>>  >>
>>  >> I'm trying to put a jar file into the karaf lib dir. Some
>> classes in
>>  >> there use SLF4J for logging.
>>  >>
>>  >> Those encounter class-not-found errors for SLF4J.
>>  >>
>>  >> Is it safe for me to add slf4j to the lib directory? I'm
>> concerned
>>  >> about disrupting pax-logging, but perhaps all of that is
>> happening
>>  >> inside bundles and won't be effected.
>>  >>
>>  >> Thanks,
>>  >>
>>  >> benson
>>  >>
>>  >
>>  > --
>>  > Jean-Baptiste Onofré
>>  > jbono...@apache.org <mailto:jbono...@apache.org>
>>  > http://blog.nanthrax.net
>>  > Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> 
>> Guillaume Nodet
>> 
>> Red Hat, Open Source Integration
>>
>> Email: gno...@redhat.com <mailto:gno...@redhat.com>
>> Web: http://fusesource.com <http://fusesource.com/>
>> Blog: http://gnodet.blogspot.com/
>>
>>
>>
>>
>> --
>> 
>> Guillaume Nodet
>> 
>> Red Hat, Open Source Integration
>>
>> Email: gno...@redhat.com <mailto:gno...@redhat.com>
>> Web: http://fusesource.com <http://fusesource.com/>
>> Blog: http://gnodet.blogspot.com/
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Slf4j usage in a library

[Benson Margulies]

On Thu, Jun 2, 2016 at 12:20 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Hi Benson,
>
> slf4j packages are provided by pax-logging-service bundle (defined in
> etc/startup.properties), not by library.
>
> So, in your case, you should not use library, but more bundle definition in
> etc/startup.properties after pax-logging-service (as you can do for a custom
> appender).

JB, could you help me understand how that can work for my particular case?

My goal here is to add an NIO2 file system provider that is part of
the list of installed providers. Only the installed providers are used
for calls to Paths.get(URI).  The code in the JRE that loads up the
list of installed providers searches for SPI files using the system
classloader, not the TCCL or some other classloader. So, in this
regard, it seemed to me that an FS provider was much like a JDBC
driver (as per the example of how/why to use a  in doc). So I
don't think that putting it into a bundle at all will work.

However, I would be very happy to be wrong. Is there something about
java.lang.ClassLoader#getSystemClassLoader inside Karaf that I don't
know?

Regards,
benson



>
> Regards
> JB
>
>
> On 06/01/2016 08:02 PM, Benson Margulies wrote:
>>
>> Hello there.
>>
>> I'm trying to put a jar file into the karaf lib dir. Some classes in
>> there use SLF4J for logging.
>>
>> Those encounter class-not-found errors for SLF4J.
>>
>> Is it safe for me to add slf4j to the lib directory? I'm concerned
>> about disrupting pax-logging, but perhaps all of that is happening
>> inside bundles and won't be effected.
>>
>> Thanks,
>>
>> benson
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Slf4j usage in a library

[Benson Margulies]

Hello there.

I'm trying to put a jar file into the karaf lib dir. Some classes in
there use SLF4J for logging.

Those encounter class-not-found errors for SLF4J.

Is it safe for me to add slf4j to the lib directory? I'm concerned
about disrupting pax-logging, but perhaps all of that is happening
inside bundles and won't be effected.

Thanks,

benson

Re: Is there a way to insert a jar into the lib directory as part of pax-exam-karaf configuration?

[Benson Margulies]

JB, sorry. Some other people in some other places get unhappy with any
wasted characters.

I did not think of using the usual APIs that I use for configuration
files to drop a jar into the lib dir. Sorry to waste your time.


On Wed, Jun 1, 2016 at 12:32 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Benson, maybe you can try to type some kind of friendly messages like hello
> and regard ? ;)
>
> We gonna spend some time to answer your question, so you could spend some
> time to write the question ;)
>
> Anyway, using @Configuration, you should be able to provision any file
> before container startup.
>
> Regards
> JB
>
> On 06/01/2016 05:36 PM, Benson Margulies wrote:
>>
>> (See subject)
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Is there a way to insert a jar into the lib directory as part of pax-exam-karaf configuration?

[Benson Margulies]

(See subject)

Adding some things to the system bundle/classpath in a karaf assembly

[Benson Margulies]

I'm reading:

The plugin accepts the  element where you can add
 containing the URL of the library. For instance:



mvn:org.postgresql/postgresql/9.3-1102-jdbc41;type:=endorsed


My goal is to get NIO file system providers into place; they tend to
have dependencies. Does this chase a dependency tree, or do I have to
chase it for myself?

Can't use 'tac' to capture output of alias with many commands

[Benson Margulies]

'licenses' is an alias that runs a series of bundle commands.

Is this surprising? Should I make a jira?


karaf@root>licenses | tac -f /tmp/licenses.txt
2016-05-17 10:30:21,226 | ERROR | nsole user karaf | ShellUtil
   | 174 - org.apache.karaf.shell.core - 4.0.4 | Exception
caught while executing command
java.io.IOException: Write end dead
at java.io.PipedInputStream.read(PipedInputStream.java:310)[:1.8.0_60]
at java.io.PipedInputStream.read(PipedInputStream.java:377)[:1.8.0_60]
at 
org.apache.felix.gogo.runtime.threadio.ThreadInputStream.read(ThreadInputStream.java:67)[174:org.apache.karaf.shell.core:4.0.4]
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)[:1.8.0_60]
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)[:1.8.0_60]
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)[:1.8.0_60]
at java.io.InputStreamReader.read(InputStreamReader.java:184)[:1.8.0_60]
at java.io.BufferedReader.fill(BufferedReader.java:161)[:1.8.0_60]
at java.io.BufferedReader.readLine(BufferedReader.java:324)[:1.8.0_60]
at java.io.BufferedReader.readLine(BufferedReader.java:389)[:1.8.0_60]
at 
org.apache.karaf.shell.commands.impl.TacAction.execute(TacAction.java:70)[172:org.apache.karaf.shell.commands:4.0.4]
at 
org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:83)[174:org.apache.karaf.shell.core:4.0.4]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:67)[174:org.apache.karaf.shell.core:4.0.4]
at 
org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:87)[174:org.apache.karaf.shell.core:4.0.4]
at 
org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:480)[174:org.apache.karaf.shell.core:4.0.4]
at 
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:406)[174:org.apache.karaf.shell.core:4.0.4]
at 
org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[174:org.apache.karaf.shell.core:4.0.4]

Re: Licence inventory

[Benson Margulies]

I'm missing something here.

The doc says that ($.context bundles) is an array containing all bundles, but:

karaf@root>each ($.context bundle) { $it location }
Error executing command shell:each: unable to convert argument values
with value 'org.apache.felix.framework [0]' to type
java.util.Collection



On Tue, May 17, 2016 at 10:01 AM, Jean-Baptiste Onofré <j...@nanthrax.net> 
wrote:
> https://karaf.apache.org/manual/latest/#_scripting_2
>
> Regards
> JB
>
>
> On 05/17/2016 06:57 PM, Benson Margulies wrote:
>>
>> On Tue, May 17, 2016 at 8:07 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>>
>>> You can always create an alias combining bundle:list and bundle:headers
>>> (headers should contain license as defined in the MANIFEST).
>>
>>
>> I was looking into this. I've never scripted the Karaf shell, any
>> examples sitting around to look at?
>>
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 05/17/2016 03:41 PM, Benson Margulies wrote:
>>>>
>>>>
>>>> Anyone know a way to get karaf to list bundles and their licenses ( when
>>>> known )
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Licence inventory

[Benson Margulies]

On Tue, May 17, 2016 at 8:07 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> You can always create an alias combining bundle:list and bundle:headers
> (headers should contain license as defined in the MANIFEST).

I was looking into this. I've never scripted the Karaf shell, any
examples sitting around to look at?

>
> Regards
> JB
>
>
> On 05/17/2016 03:41 PM, Benson Margulies wrote:
>>
>> Anyone know a way to get karaf to list bundles and their licenses ( when
>> known )
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Licence inventory

[Benson Margulies]

Anyone know a way to get karaf to list bundles and their licenses ( when
known )

Re: Can a karaf command be a DS service?

[Benson Margulies]

On Thu, May 5, 2016 at 12:56 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Short answer: no.

Oh, well, conventional service lookup for moi.

>
> You can do gogo command but not karaf command.
>
> Regards
> JB
>
>
> On 05/04/2016 09:52 PM, Benson Margulies wrote:
>>
>> Can I @Component something annotated with
>> org.apache.karaf.shell.api.action.lifecycle.Service?
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Can a karaf command be a DS service?

[Benson Margulies]

Can I @Component something annotated with
org.apache.karaf.shell.api.action.lifecycle.Service?

Disabling JMX altogether

[Benson Margulies]

I'm using pax-exam to test a karaf assembly that contains the
management feature. Is there some way to disable all the JMX without
uninstalling the feature, or do I need to just randomize the ports?

Re: Many pax-exam test classes -> misery

[Benson Margulies]

Another variation on the theme is jetty rejecting a resume of an
asynchronous call.

2016-04-21 12:38:42,537 | ERROR | rosapi-worker-1  | WorkerService
   | 56 - com.basistech.ws.rosapi-worker-service -
1.1.2.v20160421042819 | Exception not handled in Worker.process,
something is very wrong.
java.util.concurrent.RejectedExecutionException:
HttpChannelOverHttp@5ff78927{r=1,c=false,a=ASYNC_WOKEN,uri=/rest/worker/process}
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.execute(QueuedThreadPool.java:362)
at org.eclipse.jetty.server.HttpChannel.execute(HttpChannel.java:806)
at 
org.eclipse.jetty.server.HttpChannelState.scheduleDispatch(HttpChannelState.java:573)
at org.eclipse.jetty.server.HttpChannelState.dispatch(HttpChannelState.java:380)
at 
org.eclipse.jetty.server.AsyncContextState.dispatch(AsyncContextState.java:114)
at 
org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation.redispatch(Servlet3ContinuationProvider.java:125)
at 
org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation.resume(Servlet3ContinuationProvider.java:131)
at 
org.apache.cxf.jaxrs.impl.AsyncResponseImpl.doResumeFinal(AsyncResponseImpl.java:96)
at 
org.apache.cxf.jaxrs.impl.AsyncResponseImpl.doResume(AsyncResponseImpl.java:89)
at org.apache.cxf.jaxrs.impl.AsyncResponseImpl.resume(AsyncResponseImpl.java:73)
at 
com.basistech.ws.worker.service.WorkerService.performProcess(WorkerService.java:268)[56:com.basistech.ws.rosapi-worker-service:1.1.2.v20160421042819]


On Thu, Apr 21, 2016 at 12:36 PM, Benson Margulies <ben...@basistech.com> wrote:
> Karaf 4.0.4. pax-exam 4.8.0.
>
> I need to test a Karaf application with a number of different
> configurations (as specified in cfg files). So, I have about 10 pax
> exam classes, each with per-class pax exam strategy.
>
> The number recently doubled (it used to be more like 5). Ever since
> then, we see sporadic failures in which the container never finishes
> initializing, and then other dumb things go wrong (stack trace of dumb
> thing below).
>
> Does this suggest anything to anyone? I have the failsafe forkCount
> set to 1, so it can't (or shouldn't) be tests running in parallel.
>
> Exception in thread "Thread-22" Exception in thread "Thread-27"
> Exception in thread "Thread-26" java.lang.NoClassDefFoundError:
> org/apache/commons/io/IOUtils
> Exception in thread "Thread-25" at
> com.basistech.ws.itest.AbstractIT.lambda$doExecute$2(AbstractIT.java:226)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:222)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:164)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:139)
> at com.basistech.ws.itest.AbstractIT.doExecute(AbstractIT.java:222)
> at 
> com.basistech.ws.itest.AbstractIT.doRequestExpectSuccess(AbstractIT.java:190)

Re: Proper way to setup a features.xml

[Benson Margulies]

On Tue, Apr 19, 2016 at 9:12 PM, John D. Ament <johndam...@apache.org> wrote:
> Talk about lightning responses Benson!
>
> What does something like that look like?  Is it broken down into multiple
> features?  Basically I'd love to see a single feature file with one feature
> for our core, and then distinct features for each module.  It seems that the
> default behavior is to create a single aggregated feature (when aggregate is
> enabled).

A bit more detail:

The aggregating project has many dependences like:


com.basistech.ws
rosapi-common
features
xml
${project.version}


Then it has:


org.apache.karaf.tooling
karaf-maven-plugin

  true



and it produces something like:

http://karaf.apache.org/xmlns/features/v1.4.0;
name="rosapi-features-1.0.100-SNAPSHOT">

The Rosette-API client classes and their Jackson
dependency.

mvn:com.fasterxml.jackson.core/jackson-annotations/2.6.2
mvn:com.fasterxml.jackson.core/jackson-core/2.6.2
mvn:com.fasterxml.jackson.core/jackson-databind/2.6.2
mvn:com.basistech.rosette/rosette-api-json/1.0.100
mvn:com.basistech.rosette/rosette-api-model/1.0.100


Code in common for Rosette API Web Service 1.5
bean-validation-support
mvn:com.basistech.ws/rosapi-common/1.0.100-SNAPSHOT
mvn:com.basistech/adm-model/1.16.0










>
> John
>
> On Tue, Apr 19, 2016 at 9:09 PM Benson Margulies <ben...@basistech.com>
> wrote:
>>
>> I have the plugin in each of my modules making a feature, and then an
>> aggregator project that uses the plugin again to combine them into a
>> single xml file that makes up the library of features.
>>
>>
>> On Tue, Apr 19, 2016 at 9:07 PM, John D. Ament <johndam...@apache.org>
>> wrote:
>> > I'm looking to get opinions, and figure it makes sense to get an opinion
>> > from the creators.
>> >
>> > I'm trying to figure out what is the best way to create features files.
>> > There's a maven plugin, or I can have it checked into source control.
>> >
>> > The maven plugin will generate a features.xml for each project.  If I
>> > compare to how camel works, for example, there's a single features.xml
>> > that
>> > describes everything in use,
>> >
>> > https://github.com/apache/camel/blob/master/platforms/karaf/features/src/main/resources/features.xml
>> >
>> > This seems cleaner because its all in one spot, but a problem because of
>> > the
>> > large overhead of creating and maintaining the file.  So is there any
>> > way to
>> > automate the generation of something like this file?  I'm trying to do
>> > the
>> > equivalent for Apache Tamaya.
>> >
>> > John

Re: Proper way to setup a features.xml

[Benson Margulies]

I have the plugin in each of my modules making a feature, and then an
aggregator project that uses the plugin again to combine them into a
single xml file that makes up the library of features.


On Tue, Apr 19, 2016 at 9:07 PM, John D. Ament  wrote:
> I'm looking to get opinions, and figure it makes sense to get an opinion
> from the creators.
>
> I'm trying to figure out what is the best way to create features files.
> There's a maven plugin, or I can have it checked into source control.
>
> The maven plugin will generate a features.xml for each project.  If I
> compare to how camel works, for example, there's a single features.xml that
> describes everything in use,
> https://github.com/apache/camel/blob/master/platforms/karaf/features/src/main/resources/features.xml
>
> This seems cleaner because its all in one spot, but a problem because of the
> large overhead of creating and maintaining the file.  So is there any way to
> automate the generation of something like this file?  I'm trying to do the
> equivalent for Apache Tamaya.
>
> John

Diagnosing config problems concisely

[Benson Margulies]

I have one or two cases where the failure to set a config parameter or copy
a file into etc makes the system unusable. These are diagnosed, today, by
throws from activation methods, which results in a very noisy spew of log
messages -- the actual problem can get lost in the noise.

Is there any way to plug something in that would run very early, and could
abort startup after complaining?

Re: The default jetty configuration

[Benson Margulies]

Achim,

We build a Karaf Assembly that contains pax-web. The first time it starts
up, a jetty.xml appears. I suppose that it is 'installing' pax-web at that
point.

So, we might want to grab that template and merge our own stuff into it
rather than just package up a 'small' jetty.xml with our static content
configuration.


--benson


On Wed, Mar 30, 2016 at 4:40 PM, Achim Nierbeck <bcanh...@googlemail.com>
wrote:

> I'm pretty sure nothing will write a jetty.xml when karaf is started.
> If you install pax-web for the first time it'll copy a jetty.xml as
> "template" to the etc folder [1].
> The way the feature service handles this, no it won't interfere, cause
> only if the file doesn't exist it'll be copied.
>
> regarding the configuration, again take a look at the feature [1].
>
> regards, Achim
>
> [1] -
> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-features/src/main/resources/features.xml#L91-L96
>
>
>
> 2016-03-30 22:34 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>
>> We just noticed another fact.
>>
>> When Karaf starts up, pax-web or something writes out a jetty.xml to the
>> etc directory where there was none before.
>>
>> Wouldn't this interfere with trying to change individual config
>> parameters on the fly from the shell?
>>
>> If I have my own jetty.xml, it isn't replaced by some sort of merged-up
>> config.
>>
>> It also writes out a cfg file, but that's less surprising to me.
>>
>> javax.servlet.context.tempdir =
>> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/data/pax-web-jsp
>> org.ops4j.pax.web.config.file =
>> /Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/etc/jetty.xml
>> org.osgi.service.http.port = 8181
>>
>> On Wed, Mar 30, 2016 at 3:52 PM, Achim Nierbeck <bcanh...@googlemail.com>
>> wrote:
>>
>>> Hi Benson,
>>>
>>> yes, this is it. As demanded by the OSGi spec, the configuration for the
>>> server is done by configuration admin service.
>>> The jetty.xml is just available for convenience for specialized
>>> configurations. The same applies to the other two supported containers,
>>> Tomcat and Undertow.
>>>
>>> regards, Achim
>>>
>>>
>>> 2016-03-30 21:34 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>>
>>>> OK, time for me to apologize.
>>>>
>>>> In the environment where I have a jetty.xml to add static content, I
>>>> indeed have the setting in the cfg file.
>>>>
>>>> So, I decided to read the source. Here's the process I see, which
>>>> elaborates on your email.
>>>>
>>>>
>>>>1. 
>>>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>>>creates the jetty server, passing in several config items from config 
>>>> admin.
>>>>2. If you supply a config.file, it might be a file, or it might be
>>>>a directory, presumably containing multiple jetty XML files. You can 
>>>> also
>>>>supply a config.url, which presumably points to a single XML file. 
>>>> However,
>>>>if it's a dir and not a file, it's rejected as invalid. The URL takes
>>>>precedence.
>>>>3. Config admin wins over a classpath resource
>>>>in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
>>>>4. The start method obtains the contents of the file, turns it into
>>>>a resource, and passes it to Jetty configuration.
>>>>5. The start method passes another set of config admin parameters
>>>>to 
>>>> org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
>>>>6. 
>>>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>>>looks to see if there is a 'master connector' as a result of processing
>>>>whatever configuration came through above. If there isn't one, it 
>>>> creates
>>>>one programmatically.
>>>>
>>>> So, the net of all of this is that there is no jetty.xml file in the
>>>> universe that represents the 'default configuration', and that a jetty.xml
>>>> that defines no connectors on the port number from config admin is purely a
>>>> supplement to the automatic configuration.
>>>>
>>>> I'll see if I can some up with any way to reflect any of this into the
>>>> doc as a proposed change.
>>&g

Re: The default jetty configuration

[Benson Margulies]

We just noticed another fact.

When Karaf starts up, pax-web or something writes out a jetty.xml to the
etc directory where there was none before.

Wouldn't this interfere with trying to change individual config parameters
on the fly from the shell?

If I have my own jetty.xml, it isn't replaced by some sort of merged-up
config.

It also writes out a cfg file, but that's less surprising to me.

javax.servlet.context.tempdir =
/Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/data/pax-web-jsp
org.ops4j.pax.web.config.file =
/Users/benson/x/rosapi1.5/assemblies/front-end/target/assembly/etc/jetty.xml
org.osgi.service.http.port = 8181

On Wed, Mar 30, 2016 at 3:52 PM, Achim Nierbeck <bcanh...@googlemail.com>
wrote:

> Hi Benson,
>
> yes, this is it. As demanded by the OSGi spec, the configuration for the
> server is done by configuration admin service.
> The jetty.xml is just available for convenience for specialized
> configurations. The same applies to the other two supported containers,
> Tomcat and Undertow.
>
> regards, Achim
>
>
> 2016-03-30 21:34 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>
>> OK, time for me to apologize.
>>
>> In the environment where I have a jetty.xml to add static content, I
>> indeed have the setting in the cfg file.
>>
>> So, I decided to read the source. Here's the process I see, which
>> elaborates on your email.
>>
>>
>>1. 
>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>creates the jetty server, passing in several config items from config 
>> admin.
>>2. If you supply a config.file, it might be a file, or it might be a
>>directory, presumably containing multiple jetty XML files. You can also
>>supply a config.url, which presumably points to a single XML file. 
>> However,
>>if it's a dir and not a file, it's rejected as invalid. The URL takes
>>precedence.
>>3. Config admin wins over a classpath resource
>>in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
>>4. The start method obtains the contents of the file, turns it into a
>>resource, and passes it to Jetty configuration.
>>5. The start method passes another set of config admin parameters to
>>org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
>>6. 
>> org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
>>looks to see if there is a 'master connector' as a result of processing
>>whatever configuration came through above. If there isn't one, it creates
>>one programmatically.
>>
>> So, the net of all of this is that there is no jetty.xml file in the
>> universe that represents the 'default configuration', and that a jetty.xml
>> that defines no connectors on the port number from config admin is purely a
>> supplement to the automatic configuration.
>>
>> I'll see if I can some up with any way to reflect any of this into the
>> doc as a proposed change.
>>
>>
>> On Wed, Mar 30, 2016 at 2:50 PM, Achim Nierbeck <bcanh...@googlemail.com>
>> wrote:
>>
>>> Hi Benson,
>>>
>>> please take a look at the pax-web documentation [1].
>>> The rule of thumb for Pax-Web is:
>>>
>>> configuration given via configuration admin service overrules anything
>>> configured via jetty.xml
>>>
>>> jetty.xml can be used for additional configuration which isn't
>>> configurable via properties / configuration admin service.
>>>
>>> Handlers are a special case, you can add those either via the jetty.xml
>>> or via OSGi services.
>>>
>>> regards, Achim
>>>
>>> [1] -
>>> http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration
>>>
>>>
>>> 2016-03-30 18:26 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>>>
>>>> JB, something happens even if you do _not_ add that line to the pax web
>>>> config file. I've added additional static content by just dropping in a
>>>> jetty.xml file that adds a connector. Is the difference that adding the
>>>> web.cfg line causes your file to completely replace the default, instead of
>>>> supplementing it?
>>>>
>>>> I'm on this today because we're trying to establish the answer to the
>>>> question of what idleTimeout is actually being used.
>>>>
>>>>
>>>> On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré <j...@nanthrax.net
>>>> > wrote:
>>&

Re: The default jetty configuration

[Benson Margulies]

OK, time for me to apologize.

In the environment where I have a jetty.xml to add static content, I indeed
have the setting in the cfg file.

So, I decided to read the source. Here's the process I see, which
elaborates on your email.


   1. 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
   creates the jetty server, passing in several config items from config admin.
   2. If you supply a config.file, it might be a file, or it might be a
   directory, presumably containing multiple jetty XML files. You can also
   supply a config.url, which presumably points to a single XML file. However,
   if it's a dir and not a file, it's rejected as invalid. The URL takes
   precedence.
   3. Config admin wins over a classpath resource
   in org.ops4j.pax.web.service.jetty.internal.JettyServerImpl#start.
   4. The start method obtains the contents of the file, turns it into a
   resource, and passes it to Jetty configuration.
   5. The start method passes another set of config admin parameters to
   org.ops4j.pax.web.service.jetty.internal.JettyServer#configureContext.
   6. 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.Stopped#start
   looks to see if there is a 'master connector' as a result of processing
   whatever configuration came through above. If there isn't one, it creates
   one programmatically.

So, the net of all of this is that there is no jetty.xml file in the
universe that represents the 'default configuration', and that a jetty.xml
that defines no connectors on the port number from config admin is purely a
supplement to the automatic configuration.

I'll see if I can some up with any way to reflect any of this into the doc
as a proposed change.


On Wed, Mar 30, 2016 at 2:50 PM, Achim Nierbeck <bcanh...@googlemail.com>
wrote:

> Hi Benson,
>
> please take a look at the pax-web documentation [1].
> The rule of thumb for Pax-Web is:
>
> configuration given via configuration admin service overrules anything
> configured via jetty.xml
>
> jetty.xml can be used for additional configuration which isn't
> configurable via properties / configuration admin service.
>
> Handlers are a special case, you can add those either via the jetty.xml or
> via OSGi services.
>
> regards, Achim
>
> [1] -
> http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration
>
>
> 2016-03-30 18:26 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>
>> JB, something happens even if you do _not_ add that line to the pax web
>> config file. I've added additional static content by just dropping in a
>> jetty.xml file that adds a connector. Is the difference that adding the
>> web.cfg line causes your file to completely replace the default, instead of
>> supplementing it?
>>
>> I'm on this today because we're trying to establish the answer to the
>> question of what idleTimeout is actually being used.
>>
>>
>> On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>>
>>> Correct.
>>>
>>> You can add in etc/org.ops4j.pax.web.cfg:
>>>
>>> org.ops4j.pax.web.config.file=${karaf.base}/etc/jetty.xml
>>>
>>> to provision your own jetty.xml.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 03/30/2016 06:07 PM, Benson Margulies wrote:
>>>
>>>> Am I correct that none of the jetty.xml files in the Karaf source tree
>>>> are live in the standard package, and that the config falls back to
>>>> pax-web?
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: The default jetty configuration

[Benson Margulies]

JB, something happens even if you do _not_ add that line to the pax web
config file. I've added additional static content by just dropping in a
jetty.xml file that adds a connector. Is the difference that adding the
web.cfg line causes your file to completely replace the default, instead of
supplementing it?

I'm on this today because we're trying to establish the answer to the
question of what idleTimeout is actually being used.


On Wed, Mar 30, 2016 at 12:10 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Correct.
>
> You can add in etc/org.ops4j.pax.web.cfg:
>
> org.ops4j.pax.web.config.file=${karaf.base}/etc/jetty.xml
>
> to provision your own jetty.xml.
>
> Regards
> JB
>
>
> On 03/30/2016 06:07 PM, Benson Margulies wrote:
>
>> Am I correct that none of the jetty.xml files in the Karaf source tree
>> are live in the standard package, and that the config falls back to
>> pax-web?
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

The default jetty configuration

[Benson Margulies]

Am I correct that none of the jetty.xml files in the Karaf source tree are
live in the standard package, and that the config falls back to pax-web?

Re: problem with SSH when launched in Tanuki

[Benson Margulies]

I found my mistake in the endorsed dir config in wrapper.conf.


On Tue, Mar 29, 2016 at 5:02 PM, Benson Margulies <ben...@basistech.com>
wrote:

> What does it look like in there? I bet you I do not.
>
>
> On Tue, Mar 29, 2016 at 4:36 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
>
>> Check if you have JCE in your wrapper.conf.
>>
>> Regards
>> JB
>>
>>
>> On 03/29/2016 02:08 PM, Benson Margulies wrote:
>>
>>> When I 'wrap' my karaf container, I lose the ability to ssh to it at
>>> 8101:
>>>
>>> In java, I get a backtrace like the following. At the shell, I see
>>>
>>> ➜ package git:(master) ssh -p 8101 karaf@localhost
>>> Unable to negotiate with ::1: no matching cipher found. Their offer:
>>>
>>> It works fine when I launch the container from the 'karaf' command.
>>>
>>>
>>> ---
>>>
>>> jvm 1| java.lang.IllegalStateException: Unable to negotiate key
>>> exchange for encryption algorithms (client to server) (client:
>>> chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,
>>> aes128-...@openssh.com,aes256-...@openssh.com
>>> ,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
>>> rijndael-...@lysator.liu.se
>>> / server: )
>>> jvm 1| at
>>> org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1159)[5:org.apache.sshd.core:0.14.0]
>>> jvm 1| at
>>> org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:388)[5:org.apache.sshd.core:0.14.0]
>>> jvm 1| at
>>> org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)[5:org.apache.sshd.core:0.14.0]
>>> jvm 1| at
>>> org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)[5:org.apache.sshd.core:0.14.0]
>>> jvm 1| at
>>> org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)[5:org.apache.sshd.core:0.14.0]
>>> jvm 1| at
>>> org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>

Re: problem with SSH when launched in Tanuki

[Benson Margulies]

What does it look like in there? I bet you I do not.


On Tue, Mar 29, 2016 at 4:36 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:

> Check if you have JCE in your wrapper.conf.
>
> Regards
> JB
>
>
> On 03/29/2016 02:08 PM, Benson Margulies wrote:
>
>> When I 'wrap' my karaf container, I lose the ability to ssh to it at 8101:
>>
>> In java, I get a backtrace like the following. At the shell, I see
>>
>> ➜ package git:(master) ssh -p 8101 karaf@localhost
>> Unable to negotiate with ::1: no matching cipher found. Their offer:
>>
>> It works fine when I launch the container from the 'karaf' command.
>>
>>
>> ---
>>
>> jvm 1| java.lang.IllegalStateException: Unable to negotiate key
>> exchange for encryption algorithms (client to server) (client:
>> chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,
>> aes128-...@openssh.com,aes256-...@openssh.com
>> ,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
>> rijndael-...@lysator.liu.se
>> / server: )
>> jvm 1| at
>> org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1159)[5:org.apache.sshd.core:0.14.0]
>> jvm 1| at
>> org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:388)[5:org.apache.sshd.core:0.14.0]
>> jvm 1| at
>> org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)[5:org.apache.sshd.core:0.14.0]
>> jvm 1| at
>> org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)[5:org.apache.sshd.core:0.14.0]
>> jvm 1| at
>> org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)[5:org.apache.sshd.core:0.14.0]
>> jvm 1| at
>> org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

problem with SSH when launched in Tanuki

[Benson Margulies]

When I 'wrap' my karaf container, I lose the ability to ssh to it at 8101:

In java, I get a backtrace like the following. At the shell, I see

➜ package git:(master) ssh -p 8101 karaf@localhost
Unable to negotiate with ::1: no matching cipher found. Their offer:

It works fine when I launch the container from the 'karaf' command.


---

jvm 1| java.lang.IllegalStateException: Unable to negotiate key
exchange for encryption algorithms (client to server) (client:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
/ server: )
jvm 1| at 
org.apache.sshd.common.session.AbstractSession.negotiate(AbstractSession.java:1159)[5:org.apache.sshd.core:0.14.0]
jvm 1| at 
org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:388)[5:org.apache.sshd.core:0.14.0]
jvm 1| at 
org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)[5:org.apache.sshd.core:0.14.0]
jvm 1| at 
org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)[5:org.apache.sshd.core:0.14.0]
jvm 1| at 
org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)[5:org.apache.sshd.core:0.14.0]
jvm 1| at 
org.apache.sshd.common.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:54)

Getting rid of basic auth for additional content via jetty.xml

[Benson Margulies]

When I access '/doc', it asked me to log in. I don't think it was
doing that when I set this up the other day, but then again, browser
caching can mislead. How can I turn it off?





http://www.eclipse.org/jetty/configure_9_0.dtd;>











https



32768
8192
8192
true
false
512



  

  
/doc

  
/../doc
true
  

  

  

static content apparently not working in Karaf 4.0.4 via jetty config

[Benson Margulies]

  

  
/doc

  
../../doc
true
  

  

  


jvm 1| 2016-03-16 08:08:39,183 | WARN  | tp1085327538-940 | Response
  | 217 - org.eclipse.jetty.util - 9.2.14.v20151106 |
Committed before 404 null
jvm 1| 2016-03-16 08:08:39,184 | WARN  | tp1085327538-940 |
ServletHandler   | 217 - org.eclipse.jetty.util -
9.2.14.v20151106 | /doc/index.html
jvm 1| java.lang.IllegalStateException: Committed
jvm 1| at
org.eclipse.jetty.server.Response.resetBuffer(Response.java:1243)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.Response.sendError(Response.java:567)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.Response.sendError(Response.java:544)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.servlet.ServletHandler$Default404Servlet.doGet(ServletHandler.java:1805)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
jvm 1| at
javax.servlet.http.HttpServlet.service(HttpServlet.java:687)[93:javax.servlet-api:3.1.0]
jvm 1| at
javax.servlet.http.HttpServlet.service(HttpServlet.java:790)[93:javax.servlet-api:3.1.0]
jvm 1| at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
jvm 1| at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)[234:org.ops4j.pax.web.pax-web-jetty:4.2.4]
jvm 1| at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[213:org.eclipse.jetty.security:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:271)[234:org.ops4j.pax.web.pax-web-jetty:4.2.4]
jvm 1| at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:99)[234:org.ops4j.pax.web.pax-web-jetty:4.2.4]
jvm 1| at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.Server.handle(Server.java:499)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[214:org.eclipse.jetty.server:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[206:org.eclipse.jetty.io:9
.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[217:org.eclipse.jetty.util:9.2.14.v20151106]
jvm 1| at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[217:org.eclipse.jetty.util:9.2.14.v20151106]
jvm 1| at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
jvm 1| 2016-03

Re: static content apparently not working in Karaf 4.0.4 via jetty config

[Benson Margulies]

This is only a problem for errors.


On Wed, Mar 16, 2016 at 8:11 AM, Benson Margulies <ben...@basistech.com>
wrote:

> 
>   
> 
>   
> /doc
> 
>class="org.eclipse.jetty.server.handler.ResourceHandler">
> ../../doc
> true
>   
> 
>   
> 
>   
> 
>
> jvm 1| 2016-03-16 08:08:39,183 | WARN  | tp1085327538-940 | Response
>   | 217 - org.eclipse.jetty.util - 9.2.14.v20151106 |
> Committed before 404 null
> jvm 1| 2016-03-16 08:08:39,184 | WARN  | tp1085327538-940 |
> ServletHandler   | 217 - org.eclipse.jetty.util -
> 9.2.14.v20151106 | /doc/index.html
> jvm 1| java.lang.IllegalStateException: Committed
> jvm 1| at
> org.eclipse.jetty.server.Response.resetBuffer(Response.java:1243)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.Response.sendError(Response.java:567)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.Response.sendError(Response.java:544)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.servlet.ServletHandler$Default404Servlet.doGet(ServletHandler.java:1805)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
> jvm 1| at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:687)[93:javax.servlet-api:3.1.0]
> jvm 1| at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)[93:javax.servlet-api:3.1.0]
> jvm 1| at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
> jvm 1| at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)[234:org.ops4j.pax.web.pax-web-jetty:4.2.4]
> jvm 1| at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[213:org.eclipse.jetty.security:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:271)[234:org.ops4j.pax.web.pax-web-jetty:4.2.4]
> jvm 1| at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[215:org.eclipse.jetty.servlet:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:99)[234:org.ops4j.pax.web.pax-web-jetty:4.2.4]
> jvm 1| at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.Server.handle(Server.java:499)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[214:org.eclipse.jetty.server:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[206:org.eclipse.jetty.io:9
> .2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[217:org.eclipse.jetty.util:9.2.14.v20151106]
> jvm 1| at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[217:org.eclipse.jetty.util:9.2.14.v20151106]
> jvm 1| at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
> jvm 1| 2016-03
>

Re: static content apparently not working in Karaf 4.0.4 via jetty config

[Benson Margulies]

Karaf 4.0.4 brought me 4.2.4 of pax-web.

Is it safe to stick 4.2.5 in there?

I'm making assumptions about the meaning of the following, but, in general,
it seems wrong to get this much traffic for a simple 404 on static content.


jvm 1| 2016-03-16 08:08:39,183 | WARN  | tp1085327538-940 | Response
  | 217 - org.eclipse.jetty.util - 9.2.14.v20151106 |
Committed before 404 null
jvm 1| 2016-03-16 08:08:39,184 | WARN  | tp1085327538-940 |
ServletHandler   | 217 - org.eclipse.jetty.util -
9.2.14.v20151106 | /doc/index.html
jvm 1| java.lang.IllegalStateException: Committed
jvm 1|  at
org.eclipse.jetty.server.Response.resetBuffer(Response.java:1243)[214:org.eclipse.jetty.server:9.2.14.v20151106]



On Fri, Mar 18, 2016 at 7:08 AM, Achim Nierbeck <bcanh...@googlemail.com>
wrote:

> ahh it's a closed connection ... which version of Pax-Web are you using?
> And did you check if that bug is already been fixed with Pax-Web?
>
> regards, Achim
>
>
> 2016-03-18 11:54 GMT+01:00 Benson Margulies <ben...@basistech.com>:
>
>>
>> On Fri, Mar 18, 2016 at 6:46 AM, Achim Nierbeck <bcanh...@googlemail.com>
>> wrote:
>>
>>>
>>> http://ops4j.github.io/pax/web/4.2.x/index.html#_advanced_jetty_configuration
>>
>>
>> For my particular application, zero java code is actually preferable.
>> Anyhow, why would configuring it that way prevent Jetty from try to write
>> to closed connections?
>>
>>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
>

Re: Substitutions in jetty.xml

[Benson Margulies]

Thanks.

On Wed, Mar 16, 2016 at 8:48 AM, Philipp Marx <smi...@googlemail.com> wrote:

> You can do something like this:
>
> /keystore
>
> Cheers,
>
> Philipp
>
> Benson Margulies <ben...@basistech.com> schrieb am Di., 15. März 2016 um
> 22:46 Uhr:
>
>> Can I use any ${...} in there to pass in the pathname of static content?
>> ${karaf.etc} etc would work fine.
>>
>>

Substitutions in jetty.xml

[Benson Margulies]

Can I use any ${...} in there to pass in the pathname of static content?
${karaf.etc} etc would work fine.

embedded testing and classpath management

[Benson Margulies]

So, I had my stuff working in IntelliJ with runEmbedded(true).

Then I modified the pom of the itest project to include the CXF JAXRS
runtime, since I needed to launch a CXF service (mocking something) in
a test.

That was the end of running embedded, as I got class cast errors from
multiple copies of CXF in the classpath.

Since IntelliJ ignores the surefire config params for excluding
dependencies, I don't think that there's a solution from that angle.
Am I just out of luck? We lack a maven scope that means, 'really, just
at compile time. Not in the main runtime classpath, not in the test
runtime classpath."

Karaf shutdown management

[Benson Margulies]

I would like it to be so that when someone runs 'stop', some work in
progress finishes.

This would seem to require the @Deactivates to run in 'the right
order'. Presumably, the order is based on the graph of dependencies.

I'm thinking that I should create my own shutdown service and invoke
it before doing the actual Karaf shutdown.

Re: Problem with sevices using karaf 4.0.4 and cxf 3.1.4

[Benson Margulies]

I'm in production with 4.0.4 + CXF 3.1.4. I don't use blueprint, I
call the CXF API to publish my services.


On Thu, Mar 3, 2016 at 1:48 PM, Leandro Andrade  wrote:
> Do somebody know something about it?
>
> 2016-02-29 17:12 GMT-03:00 Leandro Andrade :
>>
>> Hi again,
>>
>> I used karaf 3.0.5 + cxf 3.1.4 and work well. Have some problem with karaf
>> 4 with cxf?
>>
>> Thanks a lot.
>>
>> Regards,
>>
>> 2016-02-29 16:51 GMT-03:00 Leandro Andrade :
>>>
>>> In time I installed a bundle with a jaxrs example in console:
>>>
>>> examples-cxf-jaxrs
>>>
>>> But I can't see in cxf service list.
>>>
>>>
>>>
>>> 2016-02-29 16:50 GMT-03:00 Leandro Andrade :

 Hi,

 I have some problem with services (jax-rs) using cxf 3.1.4 + karaf
 4.0.4. I installed a example service (extracted of package servicemix 7) as
 a bundle in karaf. It was started without errors, but I can't see this
 service in http://localhost:8181/cxf.


 --
 Leandro Andrade

>>>
>>>
>>>
>>> --
>>> Leandro Andrade
>>> http://www.leandroandrade.net
>>
>>
>>
>>
>> --
>> Leandro Andrade
>> http://www.leandroandrade.net
>
>
>
>
> --
> Leandro Andrade
> http://www.leandroandrade.net

Tanuki

[Benson Margulies]

We've reached the conclusion that we need to get into the tanuki business;
we've had a karaf process die without a trace (possibly a native code
debacle, but we don't know). We already have a tanuki license.

Does anyone have some breadcrumbs for running Karaf 4.0.x under Tanuki on
Linux? I can work it out from the 'start' script, but I'd be grateful for a
head start.

Re: Thread dump for pax-exam embedded getting stuck

[Benson Margulies]

On Fri, Feb 26, 2016 at 1:20 PM, Achim Nierbeck <bcanh...@googlemail.com> wrote:
> Glad it finally did work for you :-)

Sadly, it does not work quite well enough to turn it on by default. I
have multiple test classes in the project that test different Karaf
assemblies, and an attempt to just run 'mvn' and test all of them
fails with excitement such as:



2016-02-26 13:04:19,424 | WARN  | FelixStartLevel  | Activator
   | 237 - org.ops4j.pax.exam.rbc - 4.8.0 | No such Object
bound 170ba024-4550-44b4-bf17-1186f278e6b4
java.rmi.NoSuchObjectException: no such object in table
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)[:1.8.0_60]
at 
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253)[:1.8.0_60]
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:379)[:1.8.0_60]
at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source)[:1.8.0_60]
at 
org.ops4j.pax.exam.rbc.internal.Activator.stop(Activator.java:154)[237:org.ops4j.pax.exam.rbc:4.8.0]
at 
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.Felix.stopBundle(Felix.java:2610)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1389)[org.apache.felix.framework-5.4.0.jar:]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)[org.apache.felix.framework-5.4.0.jar:]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

>
>
>
> 2016-02-26 18:16 GMT+01:00 Benson Margulies <ben...@basistech.com>:
>>
>> Oh, never mind. Dumb mistake
>>
>> On Fri, Feb 26, 2016 at 12:12 PM, Benson Margulies <ben...@basistech.com>
>> wrote:
>> > It does not seem to matter what I put in logback-test.xml, I get:
>> >
>> > 12:06:48.959 [main] INFO  o.o.pax.exam.spi.DefaultExamSystem - Pax
>> > Exam System (Version: 4.8.0) created.
>> > 12:06:48.963 [main] DEBUG o.ops4j.store.intern.TemporaryStore -
>> > Storage Area is
>> > /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/1456506408962-0
>> >
>> >
>> >
>> >
>> > On Fri, Feb 26, 2016 at 12:02 PM, Benson Margulies
>> > <ben...@basistech.com> wrote:
>> >> That did it. All I have to do is figure out how to shut up the DEBUG
>> >> logging.
>> >>
>> >> On Fri, Feb 26, 2016 at 11:41 AM, Achim Nierbeck
>> >> <bcanh...@googlemail.com> wrote:
>> >>> As little hint,
>> >>> Check the PAX Web integration tests.
>> >>> The embedded tests did work for me with that setup.
>> >>>
>> >>> Regards, Achim
>> >>>
>> >>> sent from mobile device
>> >>>
>> >>> Am 26.02.2016 5:20 nachm. schrieb "Benson Margulies"
>> >>> <ben...@basistech.com>:
>> >>>>
>> >>>> I am failing to come up with a working set of pom dependencies for
>> >>>> the
>> >>>> karaf pax-exam container with karaf 4.0.4 once I stop putting my
>> >>>> entire assembly's dependency tree in the tree. Has someone got a
>> >>>> working example to share? The tests in the ops4j repo use
>> >>>> org.apache.karaf.features:standard:xml:features:3.0.3:test.
>> >>>>
>> >>>> On Fri, Feb 26, 2016 at 9:20 AM, Benson Margulies
>> >>>> <ben...@basistech.com>
>> >>>> wrote:
>> >>>> > I see why.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > /Users/benson/.m2/repository/org/eclipse/birt/runtime/org.eclipse.osgi/3.10.2.v20150203-1939/org.eclipse.osgi-3.10.2.v20150203-1939.jar
>> >>>> >
>> >>>> > is in the classpath, because the stock eclipse features have it as
>> >>>> > a
>> >>>> > dependency, and it has a META-INF file that calls for Equinox!
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > On Fri, Feb 26, 2016 at 9:09 AM, Benson Margulies
>> >>>> > <ben...@basistech.com>
>> >>>> > wrote:
>> >>>> >> Now I am really stumped.
>> >>>> >>
>> >>>> >> karaf.framework=felix
>> >>>> >>
>> >>>> >> equinox is _not_ in the classpath any longer.
>> >>>> >>
>> >>>

pax-exam karaf succeeding, but with connection refused backtraces stopping bundles.

[Benson Margulies]

---
 T E S T S
---
Running com.basistech.ws.itest.AnvilsRealComponentIT
Feb 26, 2016 1:00:08 PM org.apache.karaf.main.Main launch
INFO: Installing and starting initial bundles
Feb 26, 2016 1:00:08 PM org.apache.karaf.main.Main launch
INFO: All initial bundles installed and set to start
Feb 26, 2016 1:00:08 PM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Trying to lock
/Users/benson/x/rosapi-and-java-binding/rosapi1.5/itests/tests/target/pax/18a3d494-2224-4701-9cf6-5f3db6cc7280/lock
Feb 26, 2016 1:00:08 PM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Lock acquired
Feb 26, 2016 1:00:08 PM org.apache.karaf.main.Main$KarafLockCallback lockAquired
INFO: Lock acquired. Setting startlevel to 100
Reading POS tagger model from
edu/stanford/nlp/models/pos-tagger/english-left3words/english-left3words-distsim.tagger
... done [0.5 sec].
Loading depparse model file:
edu/stanford/nlp/models/parser/nndep/english_UD.gz ...
PreComputed 10, Elapsed Time: 1.081 (s)
Initializing dependency parser done [4.4 sec].
13:00:36.592 [main] WARN  o.o.pax.exam.spi.DefaultExamSystem - Option
org.ops4j.pax.exam.karaf.options.KarafDistributionConfigurationOption
has not been recognized.
13:00:36.595 [main] WARN  o.o.pax.exam.spi.DefaultExamSystem - Option
org.ops4j.pax.exam.options.FrameworkStartLevelOption has not been
recognized.
ERROR: Bundle org.ops4j.pax.exam.rbc [237] Error stopping bundle.
(java.rmi.ConnectException: Connection refused to host:
tinfoilhat.local; nested exception is:
java.net.ConnectException: Connection refused)
java.rmi.ConnectException: Connection refused to host:
tinfoilhat.local; nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:342)
at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source)
at org.ops4j.pax.exam.rbc.internal.Activator.stop(Activator.java:154)
at 
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2610)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1389)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.(Socket.java:434)
at java.net.Socket.(Socket.java:211)
at 
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
at 
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
... 10 more
ERROR: Bundle org.ops4j.pax.exam.rbc [237] Error stopping
mvn:org.ops4j.pax.exam/pax-exam-container-rbc/4.8.0
(org.osgi.framework.BundleException: Activator stop error in bundle
org.ops4j.pax.exam.rbc [237].)
java.rmi.ConnectException: Connection refused to host:
tinfoilhat.local; nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:342)
at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source)
at org.ops4j.pax.exam.rbc.internal.Activator.stop(Activator.java:154)
at 
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:719)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2610)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1389)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at 

Re: Thread dump for pax-exam embedded getting stuck

[Benson Margulies]

Oh, never mind. Dumb mistake

On Fri, Feb 26, 2016 at 12:12 PM, Benson Margulies <ben...@basistech.com> wrote:
> It does not seem to matter what I put in logback-test.xml, I get:
>
> 12:06:48.959 [main] INFO  o.o.pax.exam.spi.DefaultExamSystem - Pax
> Exam System (Version: 4.8.0) created.
> 12:06:48.963 [main] DEBUG o.ops4j.store.intern.TemporaryStore -
> Storage Area is
> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/1456506408962-0
>
>
>
>
> On Fri, Feb 26, 2016 at 12:02 PM, Benson Margulies <ben...@basistech.com> 
> wrote:
>> That did it. All I have to do is figure out how to shut up the DEBUG logging.
>>
>> On Fri, Feb 26, 2016 at 11:41 AM, Achim Nierbeck
>> <bcanh...@googlemail.com> wrote:
>>> As little hint,
>>> Check the PAX Web integration tests.
>>> The embedded tests did work for me with that setup.
>>>
>>> Regards, Achim
>>>
>>> sent from mobile device
>>>
>>> Am 26.02.2016 5:20 nachm. schrieb "Benson Margulies" <ben...@basistech.com>:
>>>>
>>>> I am failing to come up with a working set of pom dependencies for the
>>>> karaf pax-exam container with karaf 4.0.4 once I stop putting my
>>>> entire assembly's dependency tree in the tree. Has someone got a
>>>> working example to share? The tests in the ops4j repo use
>>>> org.apache.karaf.features:standard:xml:features:3.0.3:test.
>>>>
>>>> On Fri, Feb 26, 2016 at 9:20 AM, Benson Margulies <ben...@basistech.com>
>>>> wrote:
>>>> > I see why.
>>>> >
>>>> >
>>>> > /Users/benson/.m2/repository/org/eclipse/birt/runtime/org.eclipse.osgi/3.10.2.v20150203-1939/org.eclipse.osgi-3.10.2.v20150203-1939.jar
>>>> >
>>>> > is in the classpath, because the stock eclipse features have it as a
>>>> > dependency, and it has a META-INF file that calls for Equinox!
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Feb 26, 2016 at 9:09 AM, Benson Margulies <ben...@basistech.com>
>>>> > wrote:
>>>> >> Now I am really stumped.
>>>> >>
>>>> >> karaf.framework=felix
>>>> >>
>>>> >> equinox is _not_ in the classpath any longer.
>>>> >>
>>>> >> when I run the assembly from command line, it runs felix.
>>>> >>
>>>> >> But when I launch embedded, it's equinox.
>>>> >>
>>>> >> I'm continuing to poke.
>>>> >>
>>>> >>
>>>> >> On Fri, Feb 26, 2016 at 8:15 AM, Benson Margulies
>>>> >> <ben...@basistech.com> wrote:
>>>> >>> Achim, I don't know why I have equinox. I have karaf.framework=felix
>>>> >>> in config.properties, since I don't customize that file.
>>>> >>>
>>>> >>> I might have equinox in my Maven test classpath, should pax-exam be
>>>> >>> respecting that? I can probably get rid of it.
>>>> >>>
>>>> >>>
>>>> >>> On Fri, Feb 26, 2016 at 7:24 AM, Achim Nierbeck
>>>> >>> <bcanh...@googlemail.com> wrote:
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I've seen you are using equinox as container. Did you check if this
>>>> >>>> also
>>>> >>>> happens if you use a felix container?
>>>> >>>>
>>>> >>>> regards, Achim
>>>> >>>>
>>>> >>>>
>>>> >>>> 2016-02-26 3:51 GMT+01:00 Benson Margulies <ben...@basistech.com>:
>>>> >>>>>
>>>> >>>>> Here is a thread dump of all things stuck when trying to use
>>>> >>>>> pax-exam
>>>> >>>>> 4.8.0 with runEmbedded(true), and the thing eventually times out.
>>>> >>>>>
>>>> >>>>> https://gist.github.com/benson-basis/dafe72561c5ee6d1c1d6
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>>
>>>> >>>> Apache Member
>>>> >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>>> >>>> Committer &
>>>> >>>> Project Lead
>>>> >>>> blog <http://notizblog.nierbeck.de/>
>>>> >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>> >>>>
>>>> >>>> Software Architect / Project Manager / Scrum Master
>>>> >>>>

Re: Thread dump for pax-exam embedded getting stuck

[Benson Margulies]

It does not seem to matter what I put in logback-test.xml, I get:

12:06:48.959 [main] INFO  o.o.pax.exam.spi.DefaultExamSystem - Pax
Exam System (Version: 4.8.0) created.
12:06:48.963 [main] DEBUG o.ops4j.store.intern.TemporaryStore -
Storage Area is
/var/folders/80/5l86669j3278_x4hlpntlz38gp/T/1456506408962-0




On Fri, Feb 26, 2016 at 12:02 PM, Benson Margulies <ben...@basistech.com> wrote:
> That did it. All I have to do is figure out how to shut up the DEBUG logging.
>
> On Fri, Feb 26, 2016 at 11:41 AM, Achim Nierbeck
> <bcanh...@googlemail.com> wrote:
>> As little hint,
>> Check the PAX Web integration tests.
>> The embedded tests did work for me with that setup.
>>
>> Regards, Achim
>>
>> sent from mobile device
>>
>> Am 26.02.2016 5:20 nachm. schrieb "Benson Margulies" <ben...@basistech.com>:
>>>
>>> I am failing to come up with a working set of pom dependencies for the
>>> karaf pax-exam container with karaf 4.0.4 once I stop putting my
>>> entire assembly's dependency tree in the tree. Has someone got a
>>> working example to share? The tests in the ops4j repo use
>>> org.apache.karaf.features:standard:xml:features:3.0.3:test.
>>>
>>> On Fri, Feb 26, 2016 at 9:20 AM, Benson Margulies <ben...@basistech.com>
>>> wrote:
>>> > I see why.
>>> >
>>> >
>>> > /Users/benson/.m2/repository/org/eclipse/birt/runtime/org.eclipse.osgi/3.10.2.v20150203-1939/org.eclipse.osgi-3.10.2.v20150203-1939.jar
>>> >
>>> > is in the classpath, because the stock eclipse features have it as a
>>> > dependency, and it has a META-INF file that calls for Equinox!
>>> >
>>> >
>>> >
>>> > On Fri, Feb 26, 2016 at 9:09 AM, Benson Margulies <ben...@basistech.com>
>>> > wrote:
>>> >> Now I am really stumped.
>>> >>
>>> >> karaf.framework=felix
>>> >>
>>> >> equinox is _not_ in the classpath any longer.
>>> >>
>>> >> when I run the assembly from command line, it runs felix.
>>> >>
>>> >> But when I launch embedded, it's equinox.
>>> >>
>>> >> I'm continuing to poke.
>>> >>
>>> >>
>>> >> On Fri, Feb 26, 2016 at 8:15 AM, Benson Margulies
>>> >> <ben...@basistech.com> wrote:
>>> >>> Achim, I don't know why I have equinox. I have karaf.framework=felix
>>> >>> in config.properties, since I don't customize that file.
>>> >>>
>>> >>> I might have equinox in my Maven test classpath, should pax-exam be
>>> >>> respecting that? I can probably get rid of it.
>>> >>>
>>> >>>
>>> >>> On Fri, Feb 26, 2016 at 7:24 AM, Achim Nierbeck
>>> >>> <bcanh...@googlemail.com> wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> I've seen you are using equinox as container. Did you check if this
>>> >>>> also
>>> >>>> happens if you use a felix container?
>>> >>>>
>>> >>>> regards, Achim
>>> >>>>
>>> >>>>
>>> >>>> 2016-02-26 3:51 GMT+01:00 Benson Margulies <ben...@basistech.com>:
>>> >>>>>
>>> >>>>> Here is a thread dump of all things stuck when trying to use
>>> >>>>> pax-exam
>>> >>>>> 4.8.0 with runEmbedded(true), and the thing eventually times out.
>>> >>>>>
>>> >>>>> https://gist.github.com/benson-basis/dafe72561c5ee6d1c1d6
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>>
>>> >>>> Apache Member
>>> >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>> >>>> Committer &
>>> >>>> Project Lead
>>> >>>> blog <http://notizblog.nierbeck.de/>
>>> >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>> >>>>
>>> >>>> Software Architect / Project Manager / Scrum Master
>>> >>>>

Re: Thread dump for pax-exam embedded getting stuck

[Benson Margulies]

That did it. All I have to do is figure out how to shut up the DEBUG logging.

On Fri, Feb 26, 2016 at 11:41 AM, Achim Nierbeck
<bcanh...@googlemail.com> wrote:
> As little hint,
> Check the PAX Web integration tests.
> The embedded tests did work for me with that setup.
>
> Regards, Achim
>
> sent from mobile device
>
> Am 26.02.2016 5:20 nachm. schrieb "Benson Margulies" <ben...@basistech.com>:
>>
>> I am failing to come up with a working set of pom dependencies for the
>> karaf pax-exam container with karaf 4.0.4 once I stop putting my
>> entire assembly's dependency tree in the tree. Has someone got a
>> working example to share? The tests in the ops4j repo use
>> org.apache.karaf.features:standard:xml:features:3.0.3:test.
>>
>> On Fri, Feb 26, 2016 at 9:20 AM, Benson Margulies <ben...@basistech.com>
>> wrote:
>> > I see why.
>> >
>> >
>> > /Users/benson/.m2/repository/org/eclipse/birt/runtime/org.eclipse.osgi/3.10.2.v20150203-1939/org.eclipse.osgi-3.10.2.v20150203-1939.jar
>> >
>> > is in the classpath, because the stock eclipse features have it as a
>> > dependency, and it has a META-INF file that calls for Equinox!
>> >
>> >
>> >
>> > On Fri, Feb 26, 2016 at 9:09 AM, Benson Margulies <ben...@basistech.com>
>> > wrote:
>> >> Now I am really stumped.
>> >>
>> >> karaf.framework=felix
>> >>
>> >> equinox is _not_ in the classpath any longer.
>> >>
>> >> when I run the assembly from command line, it runs felix.
>> >>
>> >> But when I launch embedded, it's equinox.
>> >>
>> >> I'm continuing to poke.
>> >>
>> >>
>> >> On Fri, Feb 26, 2016 at 8:15 AM, Benson Margulies
>> >> <ben...@basistech.com> wrote:
>> >>> Achim, I don't know why I have equinox. I have karaf.framework=felix
>> >>> in config.properties, since I don't customize that file.
>> >>>
>> >>> I might have equinox in my Maven test classpath, should pax-exam be
>> >>> respecting that? I can probably get rid of it.
>> >>>
>> >>>
>> >>> On Fri, Feb 26, 2016 at 7:24 AM, Achim Nierbeck
>> >>> <bcanh...@googlemail.com> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> I've seen you are using equinox as container. Did you check if this
>> >>>> also
>> >>>> happens if you use a felix container?
>> >>>>
>> >>>> regards, Achim
>> >>>>
>> >>>>
>> >>>> 2016-02-26 3:51 GMT+01:00 Benson Margulies <ben...@basistech.com>:
>> >>>>>
>> >>>>> Here is a thread dump of all things stuck when trying to use
>> >>>>> pax-exam
>> >>>>> 4.8.0 with runEmbedded(true), and the thing eventually times out.
>> >>>>>
>> >>>>> https://gist.github.com/benson-basis/dafe72561c5ee6d1c1d6
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Apache Member
>> >>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> >>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> >>>> Committer &
>> >>>> Project Lead
>> >>>> blog <http://notizblog.nierbeck.de/>
>> >>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>> >>>>
>> >>>> Software Architect / Project Manager / Scrum Master
>> >>>>

Re: Thread dump for pax-exam embedded getting stuck

[Benson Margulies]

I am failing to come up with a working set of pom dependencies for the
karaf pax-exam container with karaf 4.0.4 once I stop putting my
entire assembly's dependency tree in the tree. Has someone got a
working example to share? The tests in the ops4j repo use
org.apache.karaf.features:standard:xml:features:3.0.3:test.

On Fri, Feb 26, 2016 at 9:20 AM, Benson Margulies <ben...@basistech.com> wrote:
> I see why.
>
> /Users/benson/.m2/repository/org/eclipse/birt/runtime/org.eclipse.osgi/3.10.2.v20150203-1939/org.eclipse.osgi-3.10.2.v20150203-1939.jar
>
> is in the classpath, because the stock eclipse features have it as a
> dependency, and it has a META-INF file that calls for Equinox!
>
>
>
> On Fri, Feb 26, 2016 at 9:09 AM, Benson Margulies <ben...@basistech.com> 
> wrote:
>> Now I am really stumped.
>>
>> karaf.framework=felix
>>
>> equinox is _not_ in the classpath any longer.
>>
>> when I run the assembly from command line, it runs felix.
>>
>> But when I launch embedded, it's equinox.
>>
>> I'm continuing to poke.
>>
>>
>> On Fri, Feb 26, 2016 at 8:15 AM, Benson Margulies <ben...@basistech.com> 
>> wrote:
>>> Achim, I don't know why I have equinox. I have karaf.framework=felix
>>> in config.properties, since I don't customize that file.
>>>
>>> I might have equinox in my Maven test classpath, should pax-exam be
>>> respecting that? I can probably get rid of it.
>>>
>>>
>>> On Fri, Feb 26, 2016 at 7:24 AM, Achim Nierbeck <bcanh...@googlemail.com> 
>>> wrote:
>>>> Hi,
>>>>
>>>> I've seen you are using equinox as container. Did you check if this also
>>>> happens if you use a felix container?
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2016-02-26 3:51 GMT+01:00 Benson Margulies <ben...@basistech.com>:
>>>>>
>>>>> Here is a thread dump of all things stuck when trying to use pax-exam
>>>>> 4.8.0 with runEmbedded(true), and the thing eventually times out.
>>>>>
>>>>> https://gist.github.com/benson-basis/dafe72561c5ee6d1c1d6
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Apache Member
>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>>>> Project Lead
>>>> blog <http://notizblog.nierbeck.de/>
>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>>>
>>>> Software Architect / Project Manager / Scrum Master
>>>>