Restart/Refresh the ADEP OSGi container [Apache Felix]

One of the main components of the Adobe Digital Enterprise Platform is the Apache Felix OSGi Container over which the various services and sub-components of the platform are deployed.

The container obviously brings along the great capabilities of OSGi as a dynamic component model, where components (and services) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot. However, one of the other very cool aspect of the container is the ability to Stop and/or Restart  the entire OSGi framework remotely, to help resolve/refresh the installed bundles, their bundle contexts and dependencies, etc.

To do so, you just need to go to the Felix Web Console @ the URL – http://server:port/system/console. Go to the System Information tab, where you will something like this:

 

 

 

 

 

Note the Restart and Stop options indicated in green.

The System Information tab is also useful to gather other system related information such as the JVM details, memory consumption (with the ability to perform a forced Garbage Collection), etc.

4 Responses to Restart/Refresh the ADEP OSGi container [Apache Felix]

  1. Ankush says:

    Alternatively, one can also go to http://server:port/admin and start/stop launchpad application. This will restart the OSGi container.

  2. sakagarw says:

    That is true. Thanks, Ankush!

  3. Alex says:

    I don’t know why you would ever want to restart the whole OSGi framework or even launchpad webapp (except for cases where you have to restart the whole JVM anyway). You can update individual bundles or refresh packages through the bundle list in the web console.

    • sakagarw says:

      Yes, agree that you could do so for individual bundles from the ‘Bundles’ view, but that gets too cumbersome if you have a long chain of bundle dependencies and you may have to do so for a number of those. Solutions on ADEP are a classic example of this, wherein they have a long chain of dependencies and an issue in one of the bundles leads to a number of bundles unresolved/stopped. Hence, this just seems to provide a more convenient way of doing so; of course, not to mention cases where you encounter an unexpected bundle behavior and want to refresh the container to ensure that everything is reset.