Karaf
  1. Karaf
  2. KARAF-1189

Feature installation: synchronization between copiing configuration files and installing/starting bundles

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: karaf-core

      Description

      Hi,

      Actually there is no synchronization between installation/starting bundles and copiing configuration files.
      It causes sometimes that bundles with OSGi services are already started, but appropriate configuration is not yet accepted by ConfigurationAdmin. Result is failed services by first installation. After restart problem is resolved.
      Question: is it basically possible to wait untile configuration files are accepted by ConfigurationAdmin and only after it start bundles from the feature?

      Regards,
      Andrei.

        Issue Links

          Activity

          Hide
          Andrei Shakirin added a comment -

          I can imagine that by feature installation, Karaf will install configurations at first and wait until configurations are available via ConfigurationAdmin service. Only after that, Karaf will install bundles.

          Show
          Andrei Shakirin added a comment - I can imagine that by feature installation, Karaf will install configurations at first and wait until configurations are available via ConfigurationAdmin service. Only after that, Karaf will install bundles.
          Hide
          Christian Schneider added a comment -

          I have found another simpler workaround. If the feature file also has a <config> entry then this config is guaranteed to be written to the config admin service before the feature bundles are installed

          Show
          Christian Schneider added a comment - I have found another simpler workaround. If the feature file also has a <config> entry then this config is guaranteed to be written to the config admin service before the feature bundles are installed
          Hide
          Andrei Shakirin added a comment -

          Hi Christian,

          Yes, it is clear for me that it isn't Karaf issue.
          The question was could Karaf provide generic workaround for Spring DM configurations by feature installation (first recommended workaround).
          As I can see it is not realistic.
          I will think about more or less generic solution for my case.
          Let close defect.

          Regards,
          Andrei.

          Show
          Andrei Shakirin added a comment - Hi Christian, Yes, it is clear for me that it isn't Karaf issue. The question was could Karaf provide generic workaround for Spring DM configurations by feature installation (first recommended workaround). As I can see it is not realistic. I will think about more or less generic solution for my case. Let close defect. Regards, Andrei.
          Hide
          Christian Schneider added a comment -

          The core problem is that Spring DM does not wait for configs or reload on config changes. So this can not be solved in Karaf. Workarounds exist

          Show
          Christian Schneider added a comment - The core problem is that Spring DM does not wait for configs or reload on config changes. So this can not be solved in Karaf. Workarounds exist
          Hide
          Andreas Pieber added a comment -

          I second Achim on this one; this is a "problem" of OSGi, not karaf --> +1 for closing too.

          Show
          Andreas Pieber added a comment - I second Achim on this one; this is a "problem" of OSGi, not karaf --> +1 for closing too.
          Hide
          Achim Nierbeck added a comment - - edited

          @Andrej:
          If you have a Service that depends on a external configuration your only option is to go for managed Service Factories.
          There is some documentation for this in the Spring-DM documentation at:
          http://static.springsource.org/osgi/docs/1.2.1/reference/html-single/#compendium:cm:managed-service-factories

          btw. I don't see this actually being an issue of Karaf, that's the way the OSGi env. is designed
          so +1 for closing

          Show
          Achim Nierbeck added a comment - - edited @Andrej: If you have a Service that depends on a external configuration your only option is to go for managed Service Factories. There is some documentation for this in the Spring-DM documentation at: http://static.springsource.org/osgi/docs/1.2.1/reference/html-single/#compendium:cm:managed-service-factories btw. I don't see this actually being an issue of Karaf, that's the way the OSGi env. is designed so +1 for closing
          Hide
          Christian Schneider added a comment -

          @Andrej:
          I think the other issue is not about the same problem. Spring DM has no measure to wait for configs or update on changes.
          If you deploy a config using a file then you will always have the uncertainity when it is updated in config admin.

          So I see three possible solutions:

          • Update the config using the jmx bean or command. In that case my fix for the other issue guarantees that the data is there when you install your bundle after this.
          • Use the ManagedService directly so you can pull up the service not at bundle start but rather when the config is there. This probably does not work well with defining the service in spring.
          • Use blueprint which supports config updates and not starting when there is no config

          About the issue in Karaf: I don´t think we can really fix this in karaf as the problem is with spring dm.
          So if you agree I close this issue.

          Show
          Christian Schneider added a comment - @Andrej: I think the other issue is not about the same problem. Spring DM has no measure to wait for configs or update on changes. If you deploy a config using a file then you will always have the uncertainity when it is updated in config admin. So I see three possible solutions: Update the config using the jmx bean or command. In that case my fix for the other issue guarantees that the data is there when you install your bundle after this. Use the ManagedService directly so you can pull up the service not at bundle start but rather when the config is there. This probably does not work well with defining the service in spring. Use blueprint which supports config updates and not starting when there is no config About the issue in Karaf: I don´t think we can really fix this in karaf as the problem is with spring dm. So if you agree I close this issue.
          Hide
          Christian Schneider added a comment -

          I am currently working on the lnked issue. I think it will also solve this one

          Show
          Christian Schneider added a comment - I am currently working on the lnked issue. I think it will also solve this one
          Hide
          Jürgen Kindler added a comment -

          Could this problem somehow be related to KARAF-1243 ?

          As I understand is also just happens from time to time. This is also the problem in KARAF-1243 when using the Karaf config service explicitly. If the same code is in use here and there, it might get fixed automagically ...

          Show
          Jürgen Kindler added a comment - Could this problem somehow be related to KARAF-1243 ? As I understand is also just happens from time to time. This is also the problem in KARAF-1243 when using the Karaf config service explicitly. If the same code is in use here and there, it might get fixed automagically ...
          Hide
          Andrei Shakirin added a comment - - edited

          Need a solution/workaround for Spring DM case: see last comment

          That I can imagine as a solution:
          Karaf copies feature configuration files at first, than waits before they are available via ManagedService and only after it installs the feature bundles.

          What do you think?

          Andrei.

          Show
          Andrei Shakirin added a comment - - edited Need a solution/workaround for Spring DM case: see last comment That I can imagine as a solution: Karaf copies feature configuration files at first, than waits before they are available via ManagedService and only after it installs the feature bundles. What do you think? Andrei.
          Hide
          Andrei Shakirin added a comment -

          Hmm ... baiscally OK from technical point of view, but for me is still a problem as for Spring DM user.

          Imagine following use case: I implement a simple CXF service using Spring DM and define endpoint via compendium properties:

          <spring:beans
          xmlns="http://www.springframework.org/schema/beans"
          xmlns:spring="http://www.springframework.org/schema/beans"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi"
          xmlns:jaxws="http://cxf.apache.org/jaxws"
          xmlns:context="http://www.springframework.org/schema/context"
          xmlns:osgix="http://www.springframework.org/schema/osgi-compendium"
          ...
          <context:property-placeholder properties-ref="test-configuration" />
          <osgix:cm-properties id="test-configuration" persistent-id="test.authorization"/>

          <jaxws:endpoint id="AuthorizationProvider"
          xmlns:serviceNamespace="http://services.sopera.org/Authorization"
          serviceName="serviceNamespace:Authorization" endpointName="serviceNamespace:AuthorizationProvider"
          implementor="#authorizationProviderImpl" address="$

          {authorization.endpoint}

          ">
          </jaxws:endpoint>

          </spring:beans>

          Than I define my endpoint in configuration and deploy bundle with a service and configuration file as a feature.
          What I see after deployment: service is failed, because of missing configuration. However configuration file is copiied and present in the Karaf/etc.
          Very confusing ...

          Sure, workarounds can be using OSGi ManagedService directly or blueprint, but how to resolve Spring DM case?

          Andrei.

          Show
          Andrei Shakirin added a comment - Hmm ... baiscally OK from technical point of view, but for me is still a problem as for Spring DM user. Imagine following use case: I implement a simple CXF service using Spring DM and define endpoint via compendium properties: <spring:beans xmlns="http://www.springframework.org/schema/beans" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi" xmlns:jaxws="http://cxf.apache.org/jaxws" xmlns:context="http://www.springframework.org/schema/context" xmlns:osgix="http://www.springframework.org/schema/osgi-compendium" ... <context:property-placeholder properties-ref="test-configuration" /> <osgix:cm-properties id="test-configuration" persistent-id="test.authorization"/> <jaxws:endpoint id="AuthorizationProvider" xmlns:serviceNamespace="http://services.sopera.org/Authorization" serviceName="serviceNamespace:Authorization" endpointName="serviceNamespace:AuthorizationProvider" implementor="#authorizationProviderImpl" address="$ {authorization.endpoint} "> </jaxws:endpoint> </spring:beans> Than I define my endpoint in configuration and deploy bundle with a service and configuration file as a feature. What I see after deployment: service is failed, because of missing configuration. However configuration file is copiied and present in the Karaf/etc. Very confusing ... Sure, workarounds can be using OSGi ManagedService directly or blueprint, but how to resolve Spring DM case? Andrei.
          Hide
          Christian Schneider added a comment - - edited

          We just discussed another problem. When you update a config in the config admin service you do not know when all listeners have been notified. I think we should fire an event when all listeners have processed the update event. So the user can be sure the system works with the new config settings.

          Show
          Christian Schneider added a comment - - edited We just discussed another problem. When you update a config in the config admin service you do not know when all listeners have been notified. I think we should fire an event when all listeners have processed the update event. So the user can be sure the system works with the new config settings.
          Hide
          Jean-Baptiste Onofré added a comment -

          Agree with Christian: to match a bundle lifecycle with a config, you have to use a ManagedService.

          It's not dependant of a feature, it should be directly in your bundle (as it's bundle specific).

          Show
          Jean-Baptiste Onofré added a comment - Agree with Christian: to match a bundle lifecycle with a config, you have to use a ManagedService. It's not dependant of a feature, it should be directly in your bundle (as it's bundle specific).
          Hide
          Christian Schneider added a comment -

          Basically the right way to do this is to start your services when the config is present. So for example you start the service in the ManagedService.updated method. I think blueprint can take care of this too.

          Show
          Christian Schneider added a comment - Basically the right way to do this is to start your services when the config is present. So for example you start the service in the ManagedService.updated method. I think blueprint can take care of this too.
          Hide
          Jean-Baptiste Onofré added a comment -

          Could you elaborate ? I'm not sure to understand your needs.

          Show
          Jean-Baptiste Onofré added a comment - Could you elaborate ? I'm not sure to understand your needs.

            People

            • Assignee:
              Christian Schneider
              Reporter:
              Andrei Shakirin
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development