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 < 1MB jar runnable with "java -jar JARNAME.JAR -console". It wasn't fun to start it that way, so following instructions in QuickStart Guide (do spend some time reading the last section, it's worth it) I downloaded a native launcher for my Mac from the same download page.
Note for Mac users: Since it's the same launcher used in Eclipse IDE, it doesn't work in Java 6 64-bit. Neither does the Cocoa version.
Verify the framework by running it. At the osgi> console, type ss. It will show one active bundle (which is the framework itself). Type close to shutdown.
osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20080605-1900
If you want to enable JMX, open eclipse.ini (it's in Eclipse.app if you're using Mac) and add the following entries:
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=6789 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
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:
- Jars started with com.springsource.server
- Jars having slf4j if you want "unified" logging like I do (will explain this later)
- Jars started with org.eclipse.osgi because they may conflict with our OSGi framework
- Every jar in /repository/bundles/ext EXCEPT:
- Jars having slf4j and anything related to any logging framework (commons-logging, Log4J) if you want "unified" logging
- Jars having -sources unless you want to keep the source code
- Jars started with org.springframework.osgi because we will use the ones from Spring Dynamic Modules distribution
- Every jar in /repository/bundles/usr EXCEPT:
- Jars having slf4j and anything related to any logging framework (commons-logging, Log4J) if you want "unified" logging
- 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:
osgi.bundles=org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start,
catalina.start.osgi-VERSION.jar@3:start, spring-osgi-extender-VERSION.jar@4:start,
spring-osgi-web-extender-VERSION.jar@4:start
eclipse.ignoreApp=true
osgi.noShutdown=true
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:
14:48 Start Thread I o.s.o.w.t.i.Activator - Starting Apache Tomcat/6.0.18 ... 14:48 Start Thread I o.s.o.w.t.i.Activator - Using default XML configuration bundleresource://3/conf/default-server.xml Mar 11, 2009 2:48:09 PM org.apache.catalina.startup.ClusterRuleSetFactory getClusterRuleSet INFO: Unable to find a cluster rule set in the classpath. Will load the default rule set. 14:48 t Dispatcher I o.s.o.e.i.a.ContextLoaderListener - Starting [org.springframework.osgi.extender] bundle v.[1.2.0.m2] Mar 11, 2009 2:48:09 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Mar 11, 2009 2:48:09 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 227 ms Mar 11, 2009 2:48:09 PM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Mar 11, 2009 2:48:09 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.18 Mar 11, 2009 2:48:09 PM org.apache.coyote.http11.Http11AprProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 14:48 Start Thread I o.s.o.w.t.i.Activator - Succesfully started Apache Tomcat/6.0.18 @ Catalina:8080 14:48 Start Thread I o.s.o.w.t.i.Activator - Published Apache Tomcat/6.0.18 as an OSGi service 14:48 t Dispatcher I o.s.o.e.i.s.ExtenderConfiguration - No custom extender configuration detected; using defaults... 14:48 t Dispatcher I o.s.s.t.TimerTaskExecutor - Initializing Timer 14:48 t Dispatcher I o.s.s.t.TimerTaskExecutor - Initializing Timer 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] 14:48 xtender-Init I o.s.o.w.e.i.a.WarListenerConfiguration - No custom extender configuration detected; using defaults... 14:48 xtender-Init I o.s.o.w.d.t.TomcatWarDeployer - No Catalina Service set; looking for one in the OSGi service registry... 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.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}