Virgo in the Cloud: a CloudFoundry buildpack

The recent Virgo community survey showed quite a bit of interest in running Virgo in the cloud. With CloudFoundry's forthcoming "buildpack" support, this was relatively easy to achieve.

A Virgo buildpack is available on github - see the README for detailed information. It currently supports two types of application: web applications or "overlays". A web application may be a standard WAR file or an OSGi Web Application Bundle. An overlay is a pair of directories -- pickup for the application(s) to be deployed and repository/usr for any additional dependencies not already provided by Virgo -- which are placed in an instance of Virgo Server for Apache Tomcat.

The support for buildpacks should ship later this month - see the CloudFoundry roadmap.

Virgo survey results

Thanks to the ninety-seven people who filled in the Virgo survey. The survey is now closed and the results are in. I'll summarise the results here, but the raw data (in Open Document Spreadsheet format) are available for anyone who wants more detail.

88% of respondents are on Virgo 3.5.0 or later while only 5% are still using SpringSource dm Server.

Virgo Server for Apache Tomcat is by far the most popular runtime deliverable. I would expect this to change over time if SAP's cloud strategy based on Nano Web is successful, even if such success doesn't feature much in Virgo survey results.

A greater respondents (36%) are in production this time, compared to 23% in May 2011.

OSGi and Spring are both preferred programming models with Java EE being somewhat less preferred.  Admittedly this question doesn't capture those who are forced to use a programming model they would prefer not to, but hopefully that number is small given the choice of programming model provided by Virgo.

The future directions were all of interest, some a little more than others. I'm not going to comment in detail, but better support for OSGi standard applications is particularly strong with a high "Gimme gimme" ranking and a tiny snooze factor.

The written comments were illuminating on the whole. Here are the comments for question 7 "Any other future direction(s) you'd really like to see".

Better Maven integration: Automatic deployment, Automatic installation, etc. Better Documentation on How To do integration tests of a complex Web Appplication in Virgo.

I would like to see a better testing framework for Virgo unit and integration testing.

Ensuring that the tooling follows the development of the Virgo server, because it's quite slow right now and often leads to some null pointer that imply reconfiguring the server in STS :(

reliability and troubleshooting are a major concern. As Virgo exposes OSGi to applications - it's harder to debug classloading problems, compared to pure Tomcat or Jetty environments. xx

Question 11 "Anything else to get off your chest?" produced quite a bit of feedback. The tooling is fairly criticised, so we are hoping the upcoming 1.0.1 release will fix a number of common problems. There are repeated calls for sharing of experience with real world applications and technologies, something I feel the Virgo community could helpfully contribute, for instance via blogs or on the Virgo wiki: I'd invite anyone interested to go ahead and add to the Community section. Meanwhile, we have been revamping the samples and will be issuing a milestone soon.

Integration testing made easy (we talked about cargo integ' on the forum and it's for me the priority to leverage Virgo as a top level platform).

Virgo was not simple to shrink, we ended up with a number of components that we could not easily throw out. We did eventually get the right isolation and app working, but the project failed for other non technical reasons. There are generally too many frame works in java, and the owners of java have let opportunity to fix jar hell slip too many times. Look at other language ecosystems as examples. Erlang makes it super easy for operators to update code in a system.

Virgo: Don't push yourself so hard today. Try to find some relaxation time. If you had big plans, perhaps you should cancel them. Instead, schedule some time with friends or family. Or treat yourself to a little indulgence. Some wine tasting here or appetizers there won't hurt as long as you don't go overboard.

We really would like to see a much more stable version of the virgo tooling. Virgo must be restarted way too often during deployment because of tooling problems.

Move away from Spring. JavaEE + OSGi is a better combination. Nice to see that supported in the latest(?) release.

Generally I'm sorry to say I just don't see a future for Virgo. The container is too hard to use and the complexity is too much for the benefits delivered. Gettting a working build and keeping it working with manifest manipulation is still too hard and error prone. It seems unlikely it will ever get fixed or improved. The "next big thing" seems to be Typesafe. But for the most part, containers are going away, and we're going to move to something like AMQP based services. In fact, you can get JVM isolation just by running more JVMs in the cloud. So the unit of deployment is the Virtual Machine, not an OSGi bundle. Sorry for the negative feedback, personally I have always liked OSGi, but for most developers it's too hard to use for the benefits derived.

The first one thanks for your job, and support of this great Software called Virgo. We are developing in OSGi and Virgo about two years, developing Konekti aka Modular Web business platform. We suffer the bad initial tools in eclipse to develop, actually are better. Of course we would like more documentation :) We think it would be interesting adding any blog or tutorials about integration of other frameworks, or experience with Virgo. Our company spent many time integrating many frameworks like JBMP, Drools, ActiveMQ, Jersey, GWT, Vaadin, Jasper Reports, Quartz, ... , so we could provide our experience. Also we would like to know this experience of other companies that also are developing in OSGi and Virgo. We think that Virgo and OSGi in general are a great technology, but not many people knows about it, so any pedagogical work is necessary, and any must lead it. If in the future you add some meeting point, we can contribute it with our real experience in OSGi and Virgo. Best Regards.

Without Eclipse Virgo we would probably not have choosen to try OSGi in my project. Because we need to migrate a Java web application with quite a lot dependencies.

My take on the future - you need to branch out and ensure as much of the available Java technologies are instantly usable in Virgo. Classify the technologies (something like java-source.net does, but better) and pick a project for each one to start with, involve the community and build a library of addons and examples - you'll not only prevent users from bailing on using Virgo because of too much program infrastructure integration effort, but do just the opposite - attract them with ready-to-use examples and simple working projects. I started playing with Virgo since about 7 months. I am using Virgo to rebuild an existing security application platform which we provide to our customers and i find it very attractive to use for me as a developer. Using Virgo as an application server platform opens up a huge potential to me and allows me to build real modular applications based on osgi without having to deal with osgi runtime basics to get started, which is great. The features Virgo provides are good and do make sense to have in such an environment. Although, as mentioned above, Virgo Tooling should be improved and in my opinion this is the key element to attract more developers for using Virgo.

We use it as a managed osgi runtime and install everything into one region for sanity. Virgo rewriting bundle imports causes more problems than they are worth. Using different containers instead of a partitioned runtime makes more sense for disparate applications.

Virgo tools need a lot of improvements. In my company we ended up implementing a little set of eclipse plug-ins to perform similar tasks as those offered by Virgo tools. For example, ordering of projects deployed to the server, because whenever you open the Virgo server editor it takes ages to show up and you just have a 5 lines list for ordering bundles, with no possibility to perform a multiple selection.

Nice modular concept. Needs examples to host Virgo Nano in regular J2EE web app

I don't know what I'd do without you guys!

sorry but I feel you're apart from rest of the osgi community. Why not use or contribute to bnd, maven-bundle-plugin... (note : I have no idea about politics) Please keep thing simple, because It's not easy to defend osgi. I try in my compagny, but osgi feel complicated. In fact it's not. Just a problem of image.

First up - it's excellent. We were going to migrate to an OSGI stack but Virgo seems to have addressed a whole bunch of issues we knew we would hit. The down sides are: - eclipse tooling a bit unreliable / immature (still cannot deploy a ) - different approach from target platform standard eclipse stuff (more eclipse general issue maybe) - the whole spring, hibernate, cglib, resolve issues, class not found issues, blah blah is still a nightmare (nature of the game I guess) - *particularly if migrating to virgo* - greenfield may be easier

Hate the fact that there is no book on Virgo yet, hate that using it depends on other projects (Gemini) that also have sparse documentation. Even a simple hello world on one of the technologies can be a waste of a few hours when adapting to Virgo. Felix/Aries start to gain more traction now. No Paxrunner support for Virgo yet.

To me virgo nano with documentation regarding on how to build isolation would be perfect.

The whole jetty thing and not having an answer for regular Jdk app server model.

Virgo is great and has been very reliable. It is OSGi and integrating 3rd party software that is the pain. For example, getting DB2 datasources using a ConnectionPool framework and getting the datasources via JNDI lookup or a Declarative service takes a lot of work to configure. I still have not seen any good documentation about storing encrypted data in external properties files and then having a hook to decrypt the data so that it may be used in a blueprint.xml definition in the context of ${var} substitution. I do not want the id/password used for my database connections to be stored in plain text in some properties file. Seems that there should be a good recipe or API for handling such common security concerns. For the most part I am well pleased with what Virgo offers, and I am in the middle of transforming a JBoss J2EE multi-tier application to a pure OSGi application running under Virgo.

I love Virgo but the learning curve is steep. Not only Virgo's fault but overall to develop SpringDM applications I had many problems since there are many technologies involved none of which is particularly stable. Random problems: Bundles where there which were not seen, then they were seen. Spring services were found then were not found anymore. Then deleting the work directory solved a lot. Then a bundle was found with version 0.0.0 and you have no idea why. Then 1 day later you realise there was a missing dependency. Etc. Debugging is still quite tricky, when things work do work but many times to get there is a huge pain. Anyway Virgo rocks :) Also the problem with many JARs around which are not yet OSGfied. And to OSGi them you have to beg the developers. Or you have to wrap it yourself but then you have to do it everytime there's a release. There are ways to easily OSGfy a plugin but it would be very useful to make the process as seamless as possible and push the community to embrace OSGi.

I really appreciate what you guys doing. But I don't like the current state of maven support. We use maven for every project it is key technology at our company. It was not easy to setup maven multi-module project to work with eclipse virgo ide and be able to successfully build outside eclipse as well. (driving all osgi dependencies from maven side + generating manifest + providing transient dependencies so virgo can see them when we add dependency just to pom.xml) Do not have sources this days is just sad (and make it that bundles which comes with virgo to be source-aware is complete madness) - with maven it is just so easy. Anyway keep up good work.

Its still hard to managed those jar dependencies or change to more recent version of spring without running into conflicts.

Tooling tooling tooling. Is has been the biggest issue and time consuming process. We have finally crafted a build setup that support maven in CI and in Sts that works but at times can be fragile and difficult to troubleshoot. Many many times we ponder if there is a better way and aren't able to find the answer.

Startup time is the major pain point for us.

I think you need to do more community development. Work on describing how people can use vanilla technologies deployed in Virgo and then move into OSGi modules if they want to. My main concern is trying to stay within a technology stack that is either directly portable or easily ported to a different server as an option.

Seems like things took a while to transition to Eclipse, but feeling better about Virgo and tooling by the day. We're most interested in running this on tiny devices, so are happy (and hoping) to see continued support for Nano.

We are very happy with Virgo! We enjoy the fact that's pretty lightweight, easy to configure and provides good performance. A good thing would be if more than one pickup-folder could be defined.

In my opinion Virgo is lacking some really good documentation and programming examples. The examples available are all using maven and not the eclipse pde dependencies and tools, wich are the easiest way to develop within Eclipse.

Virgo Tooling with Eclipse is a nightmare. So many bugs, runtime parameters that can't be changed (try to change MaxPermSize...) or the lib\endorsed directory not included - took us hours to find out. You guys should eat your own dog food and start to use these tools not just in hobby projects.... I guess this would improve quality.

You should put more effort in the Virgo Tooling it's the more frustrating thing in Virgo. It is very slow and buggy. Keep the good work!

I want better virgo tooling in eclipse/sts. Each times i open tooling in eclipse, it's very slow still 30-40secs. If i stop virgo in error during starting then i need kill eclipse.

The technology section of the survey is rather long and hard to summarise, but it will provide useful input for future development. See the raw data if you are interested.

Finally, the quiz results were intriguing. The correct (or should I say my) answers are:

JOnAS was the biggest mystery with 49% responding "Dunno". WebLogic was second with 32%, just in front of WebSphere with 28%. One person thought that Virgo does not use OSGi or explicitly support it, but their preferred programming model was Java EE, so perhaps they see Virgo as just another enterprise server.

No solution for complexity

Neil Bartlett's blog of this title is shocking because it shows how slow to adopt proven technology the computing industry is.

David Parnas wrote his seminal paper "On the Criteria To Be Used in Decomposing Systems into Modules" (available here) in 1972. A large transaction processing monitor was modularised in the 1980's because the cost of servicing it was spiralling out of control. (Precise specifications were written for the new modules to clean up the interfaces and minimise dependencies on module internals, but that's another story.)

The OSGi module system for Java has been mature for at least five years, possibly longer depending on how you count it. Most of the major Java application servers are now constructed of OSGi modules and a number of them expose OSGi for applications to use. And yet we still see complaints such as the one Neil quotes. It seems application developers are stuck in their ways or stuck on systems which prevent them from using modularity.

Of course, modularity will eventually be adopted by all business critical software. There's really no rational alternative. But how long it will take is quite another matter.

Why I hate spikes

The recording of Dan North's recent talk on "Embracing Uncertainty" set me thinking again about what I like and dislike about agile methods such as scrum. As we end the 157th consecutive sprint of the Virgo project, I certainly appreciate the focus and sense of making progress that each sprint brings.

But what I really dislike are spikes.

The principle of a spike sounds fine: carve out some time to do some exploratory work. But I soon find myself too constrained by a spike. One definition of a spike is (emphasis added):

"a story that cannot be estimated until a development team runs a timeboxed investigation. The output of a spike story is an estimate for the original story."

There are some assumptions buried in that definition which I think show some of the problems:

• implicitly, and significantly, a spike is something you do in a sprint
• timeboxed - of course we can't commit an indefinite amount of time to a spike, but a timebox kind of implies that at the end, you'll come up with "the goods"
• estimate - the "goods" are an estimate
• original story - there's an assumption that the spike won't change your perception of what the story should be.

Here's where Dan's presentation helped me understand what was going on. Spikes are an attempt to fit some explorative work into an agile process which is designed for repeatedly churning out reliable software with minimal risk.

My natural way of doing exploratory work is rather different. First of all, I don't presume to know what it is I expect to find. I have some ideas to try out, some questions to answer, or maybe just something I need to learn about (and believe me, the longer I stay in this job, the more ignorant I realise I am).

So the actual "goods" are really answers, understanding, and more ideas. It might be possible to turn some of these into estimates for a story, but that's not really the goal.

What's wrong with trying to fit exploratory work into a sprint, you may ask? I think the psychology of reporting status in a stand-up meeting each day forces me to focus on things which will deliver immediate results. Sometimes the best way to explore something is to follow a number of lines of inquiry, get yourself thoroughly overwhelmed, take a break, and then (after several pennies have hopefully dropped), start to understand the underlying concepts.

Worse still, if I have at least one non-trivial task in the sprint besides a spike, it's really hard to get into the exploratory frame of mind. The only way I've found is to get the other stuff out of the way as quickly as possible and then try to switch modes.

So in the future, I propose to approach exploratory work differently. I'll treat it as something that's done outside a sprint. I'll still keep the idea of a timebox - it's no good going off indefinitely and losing contact with the rest of the team. But I definitely won't require that the output is an estimate of a story.

If this sounds too risky, then good. Innovation is supposed to be risky.

Restore Windows pop-up from Java on Mac OS X

I kept seeing the following pop-up during Java based builds on Mac OS X:

There was no obvious cause, but this was annoying as it paused the build until I dismissed the pop-up, although it never seemed to have any side-effect in the build.

I finally seem to have found the solution, which was to delete the Java related files in the directory ~/Library/Saved Application State:


$ rm -rf ~/Library/Saved\ Application\ State/com.apple.javajdk16.cmd.savedState/
$ rm -rf ~/Library/Saved\ Application\ State/net.java.openjdk.cmd.savedState/

Eclipse Bundle Recipes project to supersede SpringSource Enterprise Bundle Repository (EBR)

IBM, Paremus, Rebaze, Red Hat, and VMware/SpringSource, with interested parties Peter Kriens and SAP, have submitted an Eclipse Bundle Recipes project proposal aiming to provide a repository of OSGi bundle templates for open source JARs. The intention is that this will supersede the SpringSource Enterprise Bundle Repository (EBR).

It's been nearly a couple of years since we made the templates from the SpringSource EBR available on github. Apart from several pull requests from Raman Gupta (a.k.a. rocketraman, pictured below), not much appeared to happen...

In fact, quite a lot was happening behind the scenes. I was in touch with various colleagues in other companies to see if there was interest in creating a community-based replacement for the SpringSource EBR. It turned out that several large vendors did want to join in, but some of them were very cautious about the licenses of the JAR files that the project would handle. For this reason, we went in the direction of a project to host just the manifest templates.

Clearly, this wasn't going to be much use to people needing to download OSGi bundles, so we also discussed how to make the resultant bundles available. One approach was to generate the bundles on the client machine to cope with most, if not all, open source licenses. The downside of this is the potential lack of reproducibility each time a bundle is generated.

The more people we talked to, the more interest there was in storing the generated bundles in Maven Central. It turns out this is exactly what the Pax Tipi project over at OPS4J started doing last year. So we hope to build on their experience, but perhaps achieve a higher profile.

So the plan is to collaborate on templates at the Eclipse Bundle Recipes project, but also have these published to Maven Central. The details need to be worked out, but now that the Eclipse project proposal has been submitted, we can finally talk about this in public. The project fits naturally into the Eclipse Runtime umbrella project.

Interestingly, another resource for people wanting to add OSGi manifests to existing project has recently become available - the metadata advice bugzilla category at the OSGi Alliance. This should be a valuable resource for anyone wanting to develop a high quality OSGi manifest for a third party JAR.

So the scene is finally set for some progress on superseding the SpringSource EBR. Watch this space or, better still, keep an eye on the Eclipse Bundle Recipes project and or get involved. There's a discussion topic on the proposals forum if you want to comment.

Virgo Community Survey

It's a couple of years since we ran the first Virgo survey and the project has moved on a lot since then. So we've just published a new Eclipse Virgo Community Survey. If you use Virgo, I'd really appreciate it if you could take a few minutes to complete the survey. If you are short of time, please just fill in the first six questions and skip the rest.

Question 12 is a fun quiz about the use of OSGi in application servers. You'll probably find it interesting even if you have no interest in Virgo. We'll provide the answers in a few weeks time along with the survey results.

Here's the survey if you want to get going right away.

Virgo 3.6.0 released

Virgo 3.6.0 is available for download. Although the release includes many small enhancements and bug fixes, some major new features are worth highlighting and there is one smaller one I'd like to draw to the attention of Windows users.

Mike Milinkovich, the Executive Director of the Eclipse Foundation, spoke of Virgo 3.6.0 in his recent JAX interview:

"A third important milestone was SAP shipping its Netweaver Cloud offering based on the Eclipse Virgo project. Having a major vendor basing such a significant product on Eclipse runtime technologies is a great endorsement of the work that the Eclipse RT community has been doing for several years."

So, let's look at the new features.

Java Enterprise APIs

The Virgo Nano Web distribution now integrates several open source Java Enterprise API implementations which will reduce the barrier to entry for a large class of existing applications.

The SAP NetWeaver Cloud platform, which uses Virgo Nano Web as its application server, has been certified against the Java EE Web Profile. Although Virgo has not been certified, I'm optimistic that if Virgo eventually gains access to the Web Profile TCK (discussed by the Eclipse Board in June), it shouldn't be too onerous to get it to pass. Until such time as we certify Virgo, we have to be careful not to claim support for the relevant APIs. Please see the release notes for further details of the APIs and implementations involved.

Virgo continues its first class support for Spring by embedding Spring framework 3.1 and supporting Spring framework 3.2 in the kernel-based deliverables.

Virgo users now have the choice of using Spring or Java Enterprise APIs to develop Virgo applications. Alternatively, they are free to take the minimal Nano or kernel deliverables and build their own custom runtimes, like Infor did with their ION server.

See the Virgo feature summary for a comparison of the various Virgo deliverables.

New Web Admin Console

This began life as a skunk-works project by my colleague Chris Frost. The new web admin console is an AJAJ application backed by the Jolokia OSGi agent paired with Gemini Management. Gemini Management and the Virgo kernel publish JMX mbeans which enable Virgo to be managed and inspected. Jolokia provides JSON access to those mbeans which are then available to the JavaScript running in the admin console. Again, more of this in the release notes and an upcoming blog from Chris - meanwhile here's an earlier blog.

We are particularly fond of the OSGi explorer which provides a graphical depiction of package and service wirings. The initial prototype was implemented by David Normington during a short internship here at SpringSource. Below is an example package wiring diagram.

We had lots of fun testing and fixing the admin console (especially on IE), but we are rather pleased with the result. It seems to push the SVG implementations fairly hard though. Take this example of large "fan-out":

If we scroll to the far left on Safari, the Bezier curves are nice and smooth:

Compare the result in Chrome:

Again see the release notes for more details and screenshots.

The master stroke of the new web admin console is that by minimising its dependencies (shown below), it is now available in all Virgo runtimes, right down to Nano, and smoothly degrades on Nano and Nano Web by omitting panels which are only relevant to kernel and above. Where a web container is not provided by the runtime, on Nano and the kernel, we use the Equinox HTTP Service to host the admin console.

Java 7 Support

This is boring but important since Java 6 public updates cease in February 2013. The Hudson jobs for Virgo run under Java 7, but we still do local builds and releases under Java 6 to ensure both versions work well.

Kernel Deployer Pathname Reduction

This is the smaller feature to make the lives of Windows users a bit easier and which satisfied a long-standing requirement.

Firstly, the kernel deployer uses shorter paths for storing copies of deployer artefacts.

Secondly, users can configure the kernel deployer to deploy bundles in packed form, which avoids the potentially long paths involved in exploded directories. Deploying in exploded form is still the default because deploying web applications packed changes their behaviour: certain servlet API methods return null when a web application is deployed packed. See "Configuring Deployment" in the section "Configuring the Kernel and User Region" in the Virgo User Guide for details.

Conclusion

All in all Virgo 3.6.0 is a significant release and should make Virgo attractive to a broader range of users and applications. We expect Virgo 3.7.0 to improve on 3.6.0 incrementally and we welcome bug and enhancement reports based on your experience of using 3.6.0.

Can you add your project to the Virgo powered list (on the Virgo home page) in 2013?