Spring DM Server Lifecycle Listener

[traceon]

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 http://tomcat.apache.org/tomcat-5.5-...eListener.html)
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/net.my.bundle/1.0.0/myservice-1.0.0.jar/myproperties.properties) before the bundle is deployed.
3. Continue deployment

Is that possible? I couldn't find anything .

thx a lot for you're help!

[dsklyut]

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 (http://wiki.ops4j.org/display/PAXSB/Documentation) has some nice utilities in the swissbox lifecycle subproject to deal with tracking bundles also.

[traceon]

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)

[dsklyut]

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: http://static.springsource.org/osgi/...ompendium.html

[traceon]

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.

[dsklyut]

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.