What the OSGi Web Container means for dm Server
Following my previous entry many people have been asking about the impact that the move to the OSGi Web Container will have on dm Server. The most common questions being asked are:
- What is being added?
- What is staying the same?
- What is changing?
- How do I keep up to date?
I'll address each of these questions independently. If you have any more questions, please feel free to comment.
What is being added?
Integrating with the Web Container RI will give dm Server access to all the features of the OSGi Web Container standard. This includes a standard model for how WARs are handled, support for the webbundle URL scheme and support for the Web Container extender.
I'm exploring some nice value-added features for the RI including dynamic configuration using ConfigAdmin, a comprehensive MBean interface to introspect deployed web bundles and EventAdmin integration to monitor lifecycle events. All of these features will be added to dm Server as well as to the RI.
What is staying the same?
You'll be pleased to know that much of what you have learnt about web applications in dm Server remains the same.
Using the dm Server deployer
In addition to support for webbundle URLs, WAR files can still be deployed using the dm Server deployer. All paths into the deployer are supported including the pickup directory, deployer MBean and Admin Console.
When deploying using the dm Server deployer, WAR file dependencies will be automatically installed from the bundles available in the configured repository chain.
WAR deployment patterns
All the WAR types mentioned in the Programmer's Guide remain - in fact they are part of the Web Container standard.
System package imports
WARs deployed using dm Server will auto-import all the configured system packages even if this feature doesn't make it into the standard. If deploying using a webbundle URL you can trigger system package import using a URL parameter. I'm hopeful that the spec will include some standard behaviour in this area
What is changing?
We are aiming to keep the most features the same in dm Server, but the move to the Web Container does necessitate some changes. At the same time, we're taking advantage of the code rework to integrate some of the more popular feature requests we see from our users.
Web modules are being removed
The biggest change is the removal of web modules. Our preference is to support standards-based approaches, and now that we've been able to work with the OSGi Alliance to create a standards-based approach to web applications on OSGi, we are moving to it in preference to a dm Server-specific solution.
For those of you who are using web modules today, I'm really interested to hear what features you like the most and would be sad to lose. There is no reason why important web modules features cannot be reworked on top of Web Container web bundles.
Switch to Tomcat config format
In the 1.0.x line, the Tomcat instance embedded in dm Server is configured using the JSON configuration file format. Many of our users have requested that we switch back to using Tomcat's XML format. The Web Container RI uses the standard Tomcat format and when dm Server switches to the Web Container it will switch configuration file formats as well.
I'm still finalizing the exact details of where the configuration files will be stored. I'm hoping to be able to parameterize the Tomcat configuration file with placeholders that can be populated from ConfigAdmin
How do I keep up to date?
The easiest way to stay abreast of the progress is to track the SVN repos for the Web Container and for dm Server Web. You can access these repos at the URLs below:
- OSGi Web Container - https://anonsvn.springsource.org/svn/dm-server-osgi-web-container/trunk
- dm Server Web - https://anonsvn.springsource.org/svn/dm-server-web/main-branches/jersey
I'll be blogging here regularly and you can follow progress on Twitter with #osgi and #dmserver.
Similar Posts
- Introduction to the OSGi Web Container
- Deploying WARs to the OSGi Web Container is now even easier
- dm Server 2.0 M3
- dm Server 2.0 M4
- SpringSource dm Server Admin Console
Daniel Rubio says:
Added on June 2nd, 2009 at 12:11 amNice post
So WAR files stay and Web modules are being dropped. I'm not entirely clear how a 'webbundle' in the OSGi-spec will differ from a web module in dm Server.
But the biggest benefit I felt web modules solved was that you could configure a series of paramaters in a MANIFEST.MF file, and let the server auto-generae the web.xml file (and even attach it a web.xml file (that was merged) if no parameters were available.
Will a webbundle OSGi-spec support this ? Or does a webbundle OSGi-spec function more like a shared library/services WAR were you still need to deal with web.xml files (and only something like Context-Path is supported in the MANIFEST.MF) ?
One the other hand, I don't now how practical it would be to rely on MANIFEST.MF headers once you start creating more sophisticted apps that could include web.xml, faces.xml, or some extra configuration files. Again my lack of familiarity with the spec.
On a related note on the release of this OSGi container, I have a lower-level question related to Spring-DM and what will happen to it going forward now that the OSGi web container is a reality. On a bare OSGi application using Spring-DM its web-extender is able to 'delegate' a web application(WAR with a MANIFEST) to a 'vanilla' Tomcat or Jetty instance (By 'vanilla' I mean just the (non-OSGi) container JARs with OSGi data and nothing more). Will Spring-DM keep supporting this extender 'delegation' model to 'vanilla' Java EE containers , now that there is a OSG web container implementation?
Rob Harrop (blog author) says:
Added on June 2nd, 2009 at 1:59 am@Daniel
The structure of a webbundle is currently in flux. If you take any old WAR and install it using the webbundle: URL scheme then, that webbundle is still a valid WAR. There is discussion about being able to create any old bundle and have it serve up web content, but I imagine that will still end up surprisingly WAR-like.
The challenge of a new format is getting something that works nicely with tooling and also has a well-defined contract for resources that are intended to be private to the app - like WEB-INF.
RFC66 only talks about what we call WARs, shared-library WARs and shared-service WARs. It provides headers to control the context path and where the container extracts JSP content to.
I liked the generation capabilities of web modules but too many people found them confusing, and as you say, they don't really scale when you have a large project. There is nothing to prevent us from supporting generation on dm Server by extending our RFC66 contract but I'd like to be certain that what we support has real concrete value.
Re: web support in Spring DM. I'm not 100% certain on the plan there. I'll check with Adrian/Costin and they can weigh in.
Adrian Colyer says:
Added on June 2nd, 2009 at 5:25 amSpring DM 2.0 is focused on being the RI for the OSGi Blueprint Service (aka RFC 124). Now that web support in OSGi has its own fledgling spec (RFC 66) and its own project, the existing support in Spring DM will be deprecated in favour of integration with the RFC 66 web extender.
Costin Leau (blog author) says:
Added on June 2nd, 2009 at 6:01 amAdding to what Adrian said, from a technical perspective, RFC 66 does all that Spring DM web support offers in a standard, portable way. In fact, I would expect existing web applications to migrate to RFC 66 with minimal (if any) updates.
As for the roadmap the web support will be deprecated in the upcoming 2.0 and then removed in the next major version. We'll make sure to properly document the transition from one scenario to the other as well as migrate the samples included in the distribution.
Anoop says:
Added on June 2nd, 2009 at 10:07 amDoes this mean that the whole concept of personalities is going away from Spring DM Server or it is just the "Spring DM specific web module" personality being replaced by "OSGI specification based Web Container web bundle" ?
Daniel Rubio says:
Added on June 3rd, 2009 at 12:44 pmThanks for all the answers.
I only have a few more questions on time-lines. Adrian and Costin mention Spring-DM 2.0 as a target for leveraging RFC 66 (and deprecating web support as it currently stands in Spring-DM)
What about dm Server, RFC 66 and the deprecation of web modules? Will this occur post-dm Server 2.0 final release ? or will it be present in dm Server 2.0 final release?
Finally, will there be something on the UI composition front (e.g shared session state between fragments, JSF) to look at in dm Server 2.0 ? Or is this something beyond dm Server 2.0 final release?
Rob Harrop (blog author) says:
Added on June 4th, 2009 at 4:41 am@Anoop
Personalities are definitely staying. We see the Web Container being one of the personalities exhibited by dm Server and to support this we are using the Web Container RI.
Rob Harrop (blog author) says:
Added on June 4th, 2009 at 4:42 am@Daniel
Web modules will be removed in 2.0 M3 to give users plenty of time to adjust. I just finished writing the migration guide yesterday.
As for modular web apps and UI composition - we're starting work on that in our next sprint which starts on Monday.
petev says:
Added on July 2nd, 2009 at 8:53 amHi, looks very good! Is this going to be usable standalone and also with Jetty? Any plans to contribute it later to Equinox Runtime Project?
10x & greetings!
Adrian Colyer says:
Added on July 2nd, 2009 at 9:25 am@petev
The RFC 66 implementation is usable standalone as per Rob's previous blog entry http://blog.springsource.com/2009/05/27/introduction-to-the-osgi-web-container/.
The SpringSource implementation embeds Tomcat, but it would not surprise me to see other implementations based on Jetty being implemented elsewhere too.
The RFC 66 project is hosted in SpringSource repos alongside all of our other OSGi-related projects, and there are no current plans to move any of these to Eclipse.
Regards, Adrian.