Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
OSGi dynamics. Update of backing service. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • OSGi dynamics. Update of backing service.

    Good day!
    Could you please explain the following feature of OSGi dynamic
    bundle support with spring-dm?
    My configuration is described below (Felix 3.2.2):

    Code:
    g! lb
    START LEVEL 1
       ID|State      |Level|Name
        0|Active     |    0|System Bundle (3.2.2)
        1|Active     |    1|AOP Alliance API (1.0.0)
        2|Active     |    1|JBoss Logging SPI (2.0.5.GA)
        3|Active     |    1|SLF4J API (1.5.6)
        4|Resolved   |    1|SLF4J Log4J Binding (1.5.6)
        5|Active     |    1|SLF4J Jakarta Commons Logging Over SLF4J Binding (1.5.6)
        6|Active     |    1|log4j.osgi (1.2.15.SNAPSHOT)
        7|Active     |    1|Apache Felix Bundle Repository (1.6.2)
        8|Active     |    1|Apache Felix Configuration Admin Service (1.2.4)
        9|Active     |    1|Apache Felix Gogo Command (0.8.0)
       10|Active     |    1|Apache Felix Gogo Runtime (0.8.0)
       11|Active     |    1|Apache Felix Gogo Shell (0.8.0)
       12|Active     |    1|Spring AOP (3.0.0.RC1)
       13|Active     |    1|Spring ASM (3.0.0.RC1)
       14|Active     |    1|Spring Beans (3.0.0.RC1)
       15|Active     |    1|Spring Context (3.0.0.RC1)
       16|Active     |    1|Spring Core (3.0.0.RC1)
       17|Active     |    1|Spring Expression Language (3.0.0.RC1)
       18|Active     |    1|Spring Test (3.0.0.RC1)
       19|Active     |    1|spring-osgi-annotation (2.0.0.M1)
       20|Active     |    1|spring-osgi-core (2.0.0.M1)
       21|Active     |    1|spring-osgi-extender (2.0.0.M1)
       22|Active     |    1|spring-osgi-io (2.0.0.M1)
       23|Active     |    1|pa (0.0.0)
       24|Active     |    1|pb (0.0.0)
    where pa and pb are some custom bundles, with services and dependencies defined as:
    pa
    Code:
    <osgi:service ref="s1" interface="pa.IServiceA"/>
    pb
    Code:
        <osgi:reference id="s1" interface="pa.IServiceA" timeout="3000" availability="optional"/>
    After the bundle representing a back-end service (pa) has restarted,
    this back-end service becomes available to the bundle pb
    Code:
    g! stop 23
    g! start 23
    g! inspect service requirement 24
    pb (24) requires services:
    ----------------------------------
    ....
    ----
    Registering bundle = pa [23]
    Bundle-SymbolicName = pa
    Bundle-Version = 0.0.0
    objectClass = pa.IServiceA
    org.springframework.osgi.bean.name = s1
    osgi.service.blueprint.compname = s1
    service.id = 25
    2. However, updating pa makes back-end service unavailable to the pb bundle.
    Code:
    g! update 23
    g! inspect service capability 23
    pa (23) provides services:
    ----------------------------------
    Bundle-SymbolicName = pa
    Bundle-Version = 0.0.0
    objectClass = pa.IServiceA
    org.springframework.osgi.bean.name = s1
    osgi.service.blueprint.compname = s1
    service.id = 29
    ----
    ....
    g! inspect service requirement 24
    pb (24) requires services:
    ----------------------------------
    ...
    <there is not such sevice>
    Trying to call this service from the pb bundle results in
    Code:
    g! org.springframework.osgi.service.ServiceUnavailableException: service matching filter=[(objectClass=pa.IServiceA)] unavailable
    Is such behaviour expected? And how can I attain truly transparent dynamic service reloading, retaining availability of services not only after bundle restarts but also after bundle updates?
    Last edited by sinus; Jul 11th, 2011, 07:43 AM.

  • #2
    I think you can use:

    1. BundleContext to get service manually.

    2. Use Service registration and unregistration listener
    see (7.1.7. Service Registration And Unregistration Lifecycle)

    Try to refresh pb after updating pa. I think that pb has "old" references to pa.

    Comment


    • #3
      >1, 2
      Sure, but in this case using of spring-dm become meaningless.

      Comment

      Working...
      X