Just another weblog

Migrating From Spring dm Server

Posted by damuchinni on March 11, 2009

The easiest way to develop Spring-powered OSGi applications is to use SpringSource Tools (Eclipse plug-in) and SpringSource dm Server combo. They allow rapid development such as MANIFEST.MF validation, convenient deployment and automatic downloading of required (and OSGi-fied) libraries. Later on, when you need to migrate to plain OSGi (just like I do), you can follow this tutorial series.

A month ago I started development of an application with SpringSource dm Server (ssdms). In the middle of the project, concerns arose to deploy it in “plain” OSGi container (namely Equinox). The migration was rocky, so I decided to blog it for the sake of sharing.

First I downloaded the bare bone “Framework” from Eclipse. The “Eclipse Equinox” version (listed topmost) is Framework+stuff, but I didn’t use it since I wanted to build everything from scratch (and it’s stuffed with old Servlet 2.4 and Jetty 5).

The framework is a console, type ss. It will show one active bundle (which is the framework itself). Type close to shutdown.
view source
1.osgi> ss
3.Framework is launched.
4. State Bundle
6.0 ACTIVE org.eclipse.osgi_3.4.0.v20080605-1900

If you want to enable JMX, open eclipse.ini (it’s in if you’re using Mac) and add the following entries:
view source

Run jconsole from Terminal or Command Prompt (assuming JDK/bin in your path) and enter service:jmx:rmi:///jndi/rmi://localhost:6789/jmxrmi in JMX URL. You should be able to see “inside” the framework:

Next step is to fill it with libraries. The easiest way is to copy from ssdms distribution to our Equinox’s /plugins:

* Every jar in /lib EXCEPT:
o Jars started with com.springsource.server
o Jars having slf4j if you want “unified” logging like I do (will explain this later)
o Jars started with org.eclipse.osgi because they may conflict with our OSGi framework
* Every jar in /repository/bundles/ext EXCEPT:
o Jars having slf4j and anything related to any logging framework (commons-logging, Log4J) if you want “unified” logging
o Jars having -sources unless you want to keep the source code
o Jars started with org.springframework.osgi because we will use the ones from Spring Dynamic Modules distribution
* Every jar in /repository/bundles/usr EXCEPT:
o Jars having slf4j and anything related to any logging framework (commons-logging, Log4J) if you want “unified” logging
o Jars having -sources unless you want to keep the source code

What is “unified” logging? Well, you might want to unify your logging facility to be like this:

Essentially everything goes to one sink, easing administration. Anyway the logging deserves its own blog entry so I’ll skip it now. Let’s download Spring Dynamic Modules and copy the following jars from /dist to our Equinox’s /plugins:

* spring-osgi-core-VERSION.jar
* spring-osgi-extender-VERSION.jar
* spring-osgi-io-VERSION.jar
* spring-osgi-web-VERSION.jar
* spring-osgi-web-extender-VERSION.jar

Note: For now, you can use (download and put to /plugins) any logging framework library of your choice. Later on, when you decide to use the unified approach, you must replace them with the SLF4J bridges.

You will definitely want Tomcat and Spring Dynamic Modules to run everytime framework is started. You can go to console and start them manually (the framework remembers last active bundles upon shutdown and will start them next time it’s started), or you can list them in /configuration/config.ini. The latter is prefered since you can “reset” the framework (delete all configuration and cache) and still have the desired bundles run on startup. To do that, put the following entry:
view source
1.osgi.bundles=org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start,
2.catalina.start.osgi-VERSION.jar@3:start, spring-osgi-extender-VERSION.jar@4:start,

Verify our configuration by running the framework again. You should see logs of Tomcat and Spring Dynamic Modules activity. More or less you should see something like this:
view source
01.14:48 Start Thread I o.s.o.w.t.i.Activator – Starting Apache Tomcat/6.0.18 …
02.14:48 Start Thread I o.s.o.w.t.i.Activator – Using default XML configuration bundleresource://3/conf/default-server.xml
03.Mar 11, 2009 2:48:09 PM org.apache.catalina.startup.ClusterRuleSetFactory getClusterRuleSet
04.INFO: Unable to find a cluster rule set in the classpath. Will load the default rule set.
05.14:48 t Dispatcher I o.s.o.e.i.a.ContextLoaderListener – Starting [org.springframework.osgi.extender] bundle v.[1.2.0.m2]
06.Mar 11, 2009 2:48:09 PM org.apache.coyote.http11.Http11AprProtocol init
07.INFO: Initializing Coyote HTTP/1.1 on http-8080
08.Mar 11, 2009 2:48:09 PM org.apache.catalina.startup.Catalina load
09.INFO: Initialization processed in 227 ms
10.Mar 11, 2009 2:48:09 PM org.apache.catalina.core.StandardService start
11.INFO: Starting service Catalina
12.Mar 11, 2009 2:48:09 PM org.apache.catalina.core.StandardEngine start
13.INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
14.Mar 11, 2009 2:48:09 PM org.apache.coyote.http11.Http11AprProtocol start
15.INFO: Starting Coyote HTTP/1.1 on http-8080
16.14:48 Start Thread I o.s.o.w.t.i.Activator – Succesfully started Apache Tomcat/6.0.18 @ Catalina:8080
17.14:48 Start Thread I o.s.o.w.t.i.Activator – Published Apache Tomcat/6.0.18 as an OSGi service
18.14:48 t Dispatcher I o.s.o.e.i.s.ExtenderConfiguration – No custom extender configuration detected; using defaults…
19.14:48 t Dispatcher I o.s.s.t.TimerTaskExecutor – Initializing Timer
20.14:48 t Dispatcher I o.s.s.t.TimerTaskExecutor – Initializing Timer
21.14:48 t Dispatcher I o.s.o.w.e.i.a.WarLoaderListener – Starting [org.springframework.osgi.web.extender] bundle v.[1.2.0.m2]
22.14:48 xtender-Init I o.s.o.w.e.i.a.WarListenerConfiguration – No custom extender configuration detected; using defaults…
23.14:48 xtender-Init I o.s.o.w.d.t.TomcatWarDeployer – No Catalina Service set; looking for one in the OSGi service registry…
24.14:48 xtender-Init I o.s.o.w.d.t.TomcatWarDeployer – Found service Catalina

That’s it for now, later I will write about making EclipseLink JPA to work (dynamically!) and integrating BlazeDS for Flex remoting.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: