Re: Features Core bundle stuck in "Resolved" state

Well, I’m glad it helped :-) The Import-Service and Export-Service have IIUC never been osgi official valid properties (at least since R4), so I’m not sure what is looking at them or who is installing them. The subsystem stuff I was talking about is the subsystem spec, implemented in aries,

Re: Features Core bundle stuck in "Resolved" state

Well that was a brilliant suggestion. When I looked in the bundle manifest, I saw an "Import-Service" header that looked suspicious. So I decided to remove it by including <_removeheaders>Import-Service in the instructions for the maven bundle plugin. E.g.

Re: Features Core bundle stuck in "Resolved" state

I have no actual idea what is going on here….. but…. This looks a lot like the subsystem resolution errors I’ve seen. The subsystem resolver treats some requirements a bit differently than the runtime resolver. For instance, generally bundles are encouraged to specify the services they

Re: Features Core bundle stuck in "Resolved" state

Once again, thanks very much for that explanation. I will use that information to restructure our features. Unfortunately, when I applied your fix to our project I ran into another unexplainable issue. In this scenario, a feature won't install successfully because it complains about a missing

Re: Doc on embedded mode?

Benson- How are you defining "embedded" in your use case? -Matt Pavlovich On 9/13/16 11:10 AM, Benson Margulies wrote: 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

Re: Features Core bundle stuck in "Resolved" state

You basically have 3 ways to express a dependency on a feature (discarding the versioning stuff) xxx xxx xxx The first one means the resolver may include the given feature to solve a constraint, but this is not a requirement. For example, the constraint may be solved by a different

Re: Karaf 4.x startup - Aries causing components to deactivate and re-activate multiple times

Thanks David - I don't see any evidence of bundle location changes. It looks to me like the Aries TransactionManagerService is published to the OSGi registry by its own BundleActivator, then its configuration is provided so the activator unregisters itself (causing my components to all shut down

Doc on embedded mode?

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: Karaf 4.x startup - Aries causing components to deactivate and re-activate multiple times

I forgot the possible solutions if this is the problem :-) The best would be if you can figure out how to set the bundleLocation to “?” and this works. It should work fine with DS and felix config admin. I don’t know if blueprint would work with this: my impression is that it relies on

Re: Karaf 4.x startup - Aries causing components to deactivate and re-activate multiple times

I wonder if something is setting/changing/unsetting the bundle location on the configuration? Based on reports of other cycling behavior, I think this might happen if there’s a blueprint bundle also using the pid. If the bundle location is for instance set to another bundle and then unset

Re: Karaf 4.x startup - Aries causing components to deactivate and re-activate multiple times

Thanks for that information Jens. I am using Karaf 4.0.6 which appears to have version 2.0.6 of SCR: 84 | Active | 30 | 2.0.6 | Apache Felix Declarative Services There must be another problem... Marc On Tue, Sep 13, 2016 at 11:17 AM, Jens Offenbach

Error executing 'stty -F /dev/pts/0 -a': stty: /dev/pts/0: Permission denied

Hallo, I am really in trouble with current 4.1.0-SNAPSHOT. I have fixed "KARAF-4704: Unwanted variable interpolation in shell scripts" in my local build. "KARAF-4705: java.lang.ClassNotFoundException: org.jledit.ConcreteEditorFactory" has been already fixed. Thanks a lot! Now, I am facing

Re: Features Core bundle stuck in "Resolved" state

Hi Guillame, Firstly, thanks for looking into this. In regard to the "overuse of the prerequisite flag", keep in mind that the project I checked in is completely artificial. Before checking in the project, I removed many references to bundles that are not in the public maven central repository

Karaf 4.x startup - Aries causing components to deactivate and re-activate multiple times

I've been having a problem that I can't seem to resolve even after days of troubleshooting. When Karaf starts up, some of my components are activated (methods annotated with @Activate are called), then de-activated (methods annotated with @Deactivate are called) and activated again - sometimes

Re: Access environment variables from blueprint

Hi, Thanks for the info. I wrote on the jira story that it would be great to have that feature in the blueprint core. Thanks for informing on the fabric8 xml as well. Looking forward to the new features. Best Souciance On Tue, Sep 13, 2016 at 9:44 AM, lburgazzoli [via Karaf] <

Re: Access environment variables from blueprint

A new blueprint-core bundle with support for env vars [1] is on vote. In addition there is a fabric8-karaf-blueprint which is a blueprint port of camel property placeholder support [2] [1] https://issues.apache.org/jira/browse/ARIES-1311 [2]

Re: Features Core bundle stuck in "Resolved" state

I've raised a JIRA https://issues.apache.org/jira/browse/KARAF-4710 and I'll commit the fix I've found asap. 2016-09-13 5:27 GMT+02:00 oski_bear : > I have created a git repository with a project that reproduces these > issues. > You can find it here >

Access environment variables from blueprint

Hi, Does anyone know how you can access environment variables in blueprint xml syntax? In Camel you can write: @PropertyInject("{{env:EVENTBUS}}") private String eventbus; But I haven't found the equivalent for setting a property value based on an environment variable in blueprint. Is this

Re: Features Core bundle stuck in "Resolved" state

You clearly overuse the prerequisite="true" flag which causes multiple runs of the features service. I'll investigate a bit more, as I think there's a bug in the feature service in this case, but it would be much more efficient to only use the prerequisite flag when it's actually needed (mainly