Announcement Announcement Module
No announcement yet.
Spring DM Server Lifecycle Listener Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring DM Server Lifecycle Listener

    Spring DM Server 2.0.0 RELEASE

    hi together,

    i wan't to know if there is some kind of Lifecycle Listener (as i know from Tomcat
    BundleActivator Interface doesn't fit for my needs because if have to react on pre-/post deploy/undeploy bundles.

    i have to do the following:

    1. React on bundle pre-deployment
    2. Replace config placeholders for specific environment (dev, qs, test, live...) in the extracted bundle (/dm-server/work/com.springsource.kernel.deployer_2.0.0.RC1/staging/global/bundle/ before the bundle is deployed.
    3. Continue deployment

    Is that possible? I couldn't find anything .

    thx a lot for you're help!
    Last edited by traceon; Jan 15th, 2010, 12:46 PM.

  • #2
    It looks like you need an "extender pattern" here.

    You can use many different strategies:

    1. Implement com.springsource.kernel.install.artifact.InstallAr tifactLifecycleListenerSupport and publish it as a service. Use this if you don't mind dependency on the internals of dm-server.
    2. Use org.osgi.util.tracker.BundleTracker (only 4.2 osgi spec)
    3. Register a org.osgi.framework.BundleListener with the bundle context.

    Pax ( has some nice utilities in the swissbox lifecycle subproject to deal with tracking bundles also.


    • #3
      Originally posted by dsklyut View Post
      1. Implement com.springsource.kernel.install.artifact.InstallAr tifactLifecycleListenerSupport
      That sounds good but i'm not sure if this fit with my needs.
      (pls see first post)


      • #4
        You could try using a com.springsource.kernel.install.pipeline.stage.tra nsform.Transformer
        but that could be too low level for you.

        Why don't you use ConfigAdmin service? That way you can have properties externalized and don't need to use any of the extender tricks.

        See here:


        • #5
          i could imagine this will work for spring context specific properties like ProperyPlaceholderConfigurer but would this also work if e.g. i wan't to replace the log
          level in the log4j.xml on a specific stage (test, live) ? this has to be done before the app context is setup.


          • #6
            There are many ways to handle log4j configuration, but why would you use log4j if dm-server already supports logback?

            You can manage logback configuration from $DMS_HOME/config/serviceability.xml as a central location. You can also include logback.xml at the root of the jar at it will be used for logging in your bundle by dm-server medic code.

            Can you list all of the configurations that you want to manage with this replacement strategy?

            ConfigAdmin strategy does not have to be limited to the properties placeholder in your configuration xml only.

            We use a hybrid approach for configuration:
            1. We have a Configuration class that is auto-managed/injected with properties when config admin property set is changed and beans are injected with config bean and able to call getters on it to retrieve latest values. Note: make sure that you are holding a lock during updates. ReadWriteLock works very well in this case.
            2. Required properties, i.e. configuration that we expect to have prior to start up and that does not change, we use property placeholder support.


            • #7
              Some detailed explanation of my problem:

              Currently we are evaluating a migration from our old System (Plain Java Webapp/Tomcat 6) to Spring DM.

              The most tricky part of our app is the property loading mechanism which i also
              have to migrate.

              Here is a short description.
              The property loading mechanism loads properties based on host/hosttype and supports property inhertiance (host inherit from hosttype, hosttype inherit from default), importing (@@syntax can be used to import other properties) and overwriting (most specific overwrites the less specific)

              The properties are loaded in the following order
              default -> hosttype -> host

     (default -> live conf)
     (hosttype ->qa specific conf)
     (host -> dev specific conf)

              The properties loader PL distinguish based on the host/hosttype (which are env variables on the according system) which properties have to be loaded. The properties specified in these files then can be used as placeholders in the usual expression language "${myapp.property1}". The PL itself executes the placeholder replacement.

              This PL mechanism is suspended with the TomcatLifecycleListener so that on every deployment the proper properties for the according system where loaded. This enables us to set configurable values even in the web.xml or the log4.xml before the application is started. We're using this approach also for executing env. specific DB Creation scripts on app startup.

              No i'm facing the problem to migrate this functionality
              Last edited by traceon; Jan 18th, 2010, 03:18 AM.


              • #8

                If you have to migrate one to one - this functionality "might" be achievable with help of

                Where you can get a reference to a Tree of com.springsource.kernel.install.artifact.InstallAr tifact (s). From InstallArtifact you can get a reference to com.springsource.kernel.artifact.fs.ArtifactFS and get a reference from that to a File

                // or
                take a look at code or javadocs for more info.

                I would also mention that moving to a different platform architecture might facilitate some changes to current application architecture.
                If you are trying to go modular and start using OSGi vs. just deploying wars into dm-server, there will be some changes in your future application architecture


                • #9

                  i've tried to extend the

                  as in the source code documentation described.
                  An InstallArtifactLifecycleListener is notified of {@link InstallArtifact} lifecycle events. An InstallArtifactLifecycleListener implementation should be stateless and is made known to the deployer by publishing it as an OSGi service.
                  The bundle can be compiled and installed into the dm server without exceptions but somehow it doesn't react on any lifecycle events when another bundle is installed. At least i expected to see the "-------------------TEST-----------------" in the dm server out (see below)

                  public interface MyLifecycleListener extends InstallArtifactLifecycleListener
                  public class MyLifecycleListenerImpl extends InstallArtifactLifecycleListenerSupport implements MyLifecycleListener
                    public void onInstalling(InstallArtifact installArtifact) throws DeploymentException {
                      System.out.println("--------------------- TEST --------------------------");
                  Bean Mapping (...resources/com/myapp/spring-config.xml)
                       <bean id="myLifecycle" class="com.myapp.MyLifecycleListenerImpl"/>
                  OSGI Mapping (../resources/META-INF/spring/spring-config-osig.xml)
                     <import resource="classpath:/com/myapp/spring-config.xml" />
                    <osgi:service id="myLifecycleListener"
                                  interface="com.myapp.MyLifecycleListener" />
                  Manifest-Version: 1.0
                  Bundle-Name: MyOSGi 
                  Bundle-SymbolicName: com.myapp
                  Bundle-Version: 2.0
                  Export-Package: com.myapp
                  Export-Service: com.myapp.
                  Import-Bundle: com.springsource.kernel.deployer;version="[2.0.0.RELEAS
                  what is wrong here? thx a lot!


                  • #10
                    You have to publish your service with fqn InstallArtifactLifecycleListener vs. com.myapp.MyLifecycleListener

                    <osgi:service id="myLifecycleListener"
                                    interface="fqn.InstallArtifactLifecycleListener" />


                    • #11
                      still doesn't work . how about the MANIFEST.MF. does i have to export the InstallArtifactLifecycleListener there as well?