This page summarises the Virgo plan and notes design ideas for future Virgo features.
The following plan is subject to change and depends on how much resource is available as the project evolves.
3.0.0 (Maya) Release
Theme: Eclipse RT integration
Schedule: July/August 2011
Draft Release Notes for 3.0.0
- Jetty support (bug 321726)
- Use Equinox config admin instead of that of Felix (bug 310217)
- Use Equinox log service instead of that of Felix (bug 310218)
- Use Equinox event admin instead of that of Felix (bug 310219)
- Upgrade Spring to 3.0.5 (bug 314282)
- Rebase region support on OSGi framework hooks (bug 330776)
- Tomcat 7/servlet 3.0 (bug 332045)
- Make Virgo's web behaviour conform strictly to the OSGi web spec (bug 326798)
- Support OSGi Log service (bug 342716)
- Move the Kernel to DS to remove the fixed startup order (bug 333474)
- Allows PARs to contain plans (bug 335689)
- Remove entry/exit advice from hashCode() equals() and toString() methods (bug 328033)
- Critical bug fixes
5094 APPROVED Tomcat 7.0.12 Version: 7.0.12
5095 APPROVED Tomcat 7.0.12 Version: 7.0.12 (PB CQ5094)
5012 APPROVED Java Unified Expression Language Version: 2.2
5014 APPROVED javax.annotation Version: 1.1
5083 APPROVED Apache Felix Gogo Version: 0.8.01
5092 APPROVED org.apache.mina.core Version: 2.0.2
5091 APPROVED Apache SSHD Version: 0.5.0
4462 APPROVED javassist Version: 3.13.0.GA
3.5.0 (Azure) Release
Theme: p2 and tooling integration
Draft Release Notes for 3.5.0
- Provision Virgo with p2 (bug 343543)
- p2 repository in the repository chain (bug 309778)
- Support for Virgo IDE tooling
- Critical bug fixes
Nice to Have
The following items currently do not fit in the above plans, but have been raised as desirable by one or more users:
- Upgrade from Spring DM to Gemini Blueprint (bug 317943)
- Admin console administration of remote Virgo instances
- Multiple user regions
The following features are not currently in plan:
- Integration server
- Batch server
To accommodate simultaneous releases of Virgo runtime, OSGi Web Container runtime, and Virgo tooling, we are branding each release with the name of a colour, including old releases.
|Brand||Runtime||Web Container||Eclipse IDE Tooling|
|Fern||SpringSource dm Server 1.0||-||-|
|Emerald||SpringSource dm Server 2.0||OSGi Web Container 1.0||-|
|Cornflower||Virgo 2.1||Gemini Web 1.1||-|
|Maya||Virgo 3.0||Gemini Web 2.0||-|
|Azure||Virgo 3.5||Gemini Web 2.x||Virgo IDE 1.0? - TBD|
Bondi and Periwinkle are candidates for other releases (before or after Azure).
Note: the SpringSource dm Server releases are shade of green because of the SpringSource branding. Virgo has cornflower blue in its logo and admin console styling, so we chose shades of blue for Virgo releases.
Snaps is a prototype also from dm Server where it was known as Slices. It aims to give you the full benefit of a dynamic and modular OSGi environment for your web applications by allowing you to spread the front end across many bundles, or Snaps. The Snaps source code is available from one of our Git repos listed on the 'Source' tab. Thanks to Patsy Phelan and Dmitry Sklyut for comments on this content.
A Snap is an OSGi Web Application Bundle that is responsible for handling requests for part of the total application. Requests are served up to each snap depending on what part of the context path the snap has registered to handle. Each Snap will be given requests by a host bundle. A Host bundle is also just a normal web application bundle with filter configured to dispatch certain requests to any registered Snaps.
The host will handle requests to '/app/*' while '/app/orders' and '/app/billing' will be dispatched to the relevant Snap bundle.
Snaps is different from other technologies such as Web Fragments in that it much more decoupled and takes advantage of OSGi to allow for the dynamic composition of a web app at runtime. The lifecycle of the Snap and the Host is completely decoupled. This is due to the services like approach. Web Fragments are static and much more closely coupled, they share the same classpath and the modularity it offers is only at development time. This extra decoupling means that snaps can be developed in isolation from the host application, even after the host application has be released.