OSGI DM Server to simple Jetty Webapp
I am working with Wicket Framework combined with OSGI, Spring DM and running on the DM server. Though everything is working fine, I am running into issues because the Springsourcetool plugin is synchronizing my changes to local server every time a change is saved. You can turn this off but you do need to see your changes on the server. Especially when you are tuning the layout.
You can also save the page as a local HTML page to experiment with some ui changes but still there is some merge work to be done afterwards.
Instead of doing that, I decided to switch over to Jetty during the ui development so there was less overhead for using DM server to redeploy all par bundles when saved.
The changes were very simple:
update the web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/jetty-applicationContext.xml</param-value>
</context-param>
<!--
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<context-param>
<param-name>contextClass</param-name>
<param-value>com.springsource.server.web.dm.ServerOsgiBundleXmlWebApplicationContext</param-value>
</context-param>
-->
Since I use spring DM to inject the beans using osgi:reference, I created an addtional jettyApplicationContext.xml where I replace the osgi:reference calls with standard bean definitions.
So originally I had:
<osgi:reference id="authenticationService" interface="com.componence.social.AuthenticationService"></osgi:reference>
in the jetty context file:
<bean id="iwinAuthenticationService" class="com.componence.social.services.impl.AuthenticationServiceMockImpl"></bean>
Now since Maven dependencies has caused that the project references are set, using a direct spring bean injection is a piece of cake.
Now you can use the Jetty plugin to start the web application as a standard server and changes are instantly shown within 2 seconds. This will definitely save you time and a lot of frustation!
Good luck!
Interesting – thanks for sharing this. It seems that you have probably replaced the PAR file with separate bundles for use with Jetty. Did you try this with dm Server as you may find that the results are just as good and you wouldn’t be switching back and forth between platforms? Also, a comparative timing on dm Server, even if only approximate, would be helpful.
I’m also interested in whether you are running Jetty in an OSGi environment and, if so, which one.
You may also be interested to know that dm Server is being contributed to Eclipse as the Virgo project and we have integration with Jetty high on the list of work items following the contribution.
Hello Glyn,
Thanks for your comments.
The par project is still in place, the only difference is that I am not deploying from the par project but directly from the web project using ‘run-jetty-run’ plugin. I am using DM server as the OSGI platform server with the standard Tomcat plugin but during development I still find the overhead of redeployment of all bundles a bit too much. Especially if you need to do something for the user interface. I like the Par approach since it provides standard solutions for problems like weaving and classpath context but it seems it also requires you to deploy all bundles within the par for each change. Not sure if you can configure it differently..
The Jetty that I use is standard delivered with the run-jetty-run plugin so it’s not in a OSGI environment. Since each bundle has a context file for all bean definitions and a context file for OSGI service definitions, I could easily create a single jetty-context.xml file that imports all standards beans so I don’t need a OSGI platform to start the application. The only problem that I do have with this approach is that the Maven pom.xml files now need an additional change. Normally all bundle projects are marked as provided since they will be available as OSGI bundle services. Now I need to comment the ‘provided’ scope out to have the conventional large web projects again.
So I still prefer to use the DM server to deploy the application since it will be the target platform for the application. Just for frontend development, it’s still a bit too slow. Also after 10+ changes, the server tends to throw an out-of-memory exception which requires me to manually kill the process.
Thanks for pointing me to the Virgo project. It looks really interesting to have such a platform and I will definitely keep an eye on the progress. Currently I still think you need to do a bit too much get all the right components to work together using OSGI. Hopefully this project will make it more accessible for a broader audience.
Regards,
John
Hi John
Thanks for the additional info.
You can use a scoped plan to get weaving, TCCL, etc. support without using a PAR file, but the support for refreshing an individual bundle of a plan is not currently particularly strong, so I’m not sure a scoped plan would meet your development-time needs.
The OOM after 10+ changes is disappointing. I guess this is probably a lack of PermGen space, but we did do some work to avoid these problems, so it seems you’ve found a bug. If you can spare the time to reproduce this with an app you don’t mind sending us, please raise a bug against Virgo.
You’re right about Virgo. One of its objectives is to build a larger community who can really crack the usability issues associated with OSGi – and most of these are in the build and development arenas.
Regards,
Glyn