Revision as of 17:26, 1 December 2010

Day 2

Florian arrived! Apparently he has had a woeful time stranded in Frankfurt and having to take a 'bus from Heathrow to Southampton as flights to So'ton were cancelled.

09:00 start

Glyn asked us all to identify ourselves (barring memory loss from last night), and this helped us all to attach names again.

Glyn then read minutes for yesterday for our perusal. (I hope this doesn't get reviewed too severely :-D) The summary was masterly (even recognisable) — well done Glyn.

Since the minutes are such a good summary, I'm going to limit these journal entries to extra-topic observations. Hope it isn't too ephemeral.

09:30 start agenda - compare Virgo to other OSGi server solutions

This was really a nice session — we were able to pat ourselves on the back a bit. However, Dmitry did remind us that the others were 'catching up' and that we need to get new compelling function in, or at least make the app developers job significantly smoother to reamin near the front of the pack.

Glyn had some observations around the use of Aries deployment on Virgo. This highlighted for us how hard it is for someone to place other components on our platform. Although most of the problems turn out to be dependency issues not of our making, this is still sobering — others will struggle to get these things working.

Out of this session (it was not a dissing exercise, honest) some requirements arose — these were nearly all simple things (not all) so there is no shortage of work for contributors/committers in the near future. The roadmap discussion later today will be very interesting. One of these was enhancements to administration — the use of Admin Console to dynamically manage logging, for example — and there were requests to make persistence issues much easier to handle.

Although this session wandered a bit, it has to be said that the comparisons were not at all bad for us. Other topics raised here were EJB support (?), JavaEE web profiles, and JPA solutions which cut down management/update burden for that sort of application ("98% of all apps use datasources" - D).

10:13 break

10:23 development vs production modes

It is clear that the idea of having special restrictions placed on servers in production would be quite a useful feature for admins. Coupled with a notion of 'captured resolution' for artifacts, this would go some way to allowing a production system to be robust, and potentially faster in deployment. The security of production systems (Krasimir talks about security later) could also be different, though it would be nice to switch this on in development for testing. In general we agreed that the 'mode' of a system should be visible on every (or nearly every) system admin panel displayed. Chris can surely manage this :-)

10:54 Jetty

Chris gave an outline of the Jetty work — which involves having a Jetty layer instead of the web layer (including Gemini.web and tomcat) on top of the kernel to produce a new server config. Chris has successfully gotten Jetty running as a prototype, and, apart from a few refactorings and tweaks, splash and admin console should be able to run on top of this platform. It has to be said that some features are lost here — and import bundle is one of them — but this is not supposed to be functionally equivalent to the tomcat solution.

11:07 Snaps

Chris again, and he told us about the adventures he has had building, testing and basically keeping working the Snaps technology. (In case you've never heard of it, it is a fork of the Slices facility, which allows front end web apps to be built of independent components, which can be dynamically installed and uninstalled — by doing the same to the underlying bundles that implement them.)

Snaps is exciting stuff, and only requires a little more push to become a reliable repository which is published and supported as part of Virgo. We enjoyed hearing aboutt his, and many ideas were put forward as to how this might be exploited by other Virgo facilities, for example the Admin Console, a configuration management facility and possibly a Spring Batch platform extension to the kernel.

Quip of the day, by Dmitry: "We're not pure RESTafarians."

11:43 Web

Violeta spoke about the Web container, including Tomcat and Servlet implications. We expect to need to move to Tomcat 7 soon, partly because that might mean we don't have to run with a (SpringSource) modified version of Tomcat, to enable embedding. This also implies a move to Servlet 3.x. Certain restrictions can be removed thereby and extra features of Tomcat supported. I have to admit to feeling out of my depth here.

12:11 break

12:23 Dmitry's list

Dmitry spoke about JPA and JNDI (for Gemini Naming) and some experience with Tomcat changes. The main point here is that we need to include all those web developers out there (98% of them, according to D) who need to use datasources. These people should have a smooth and easy path in. We all agreed, of course. D was able to highlight the management problem from personal experience with several customers: it is not good to have to manage datasource definitions that are duplicated (up to three times) in one application system. D has a lot of good requirements (and use cases) that could be fixed with a (small) matter of programming. (The problem this week appears to be lots of ideas for things to do, but not enough resources to do them all!) I did catch, though, that D offered to do something (with snaps?) — to get the DNS definitions in one place, perhaps? It is not clear exactly what this is, but if anyone can prototype this, D can.

In this period mention was made of a Spring Batch extension on the kernel platform that enabled simple management of jobs, each of which can be dynamically deployed and then executed in an OSGi framework. Probably with a Web front end. It was questioned whether this was really necessary — by which I took the questioner to mean does this elverage the OSGi container in any real sense? D seemed to think so. Glyn asked if there was a customer using Spring Batch who could benefit. There are interesting possibilities; how to begin?

12:50 Security

At this point the Agenda was bent to include things that were planned for this afternoon.

Krasi told us of all the things he would like to see to support what he termed 'security'. This turns out to mean not only permissions and access contorl, but also system self-protection against faulty (or even malicious) applications. We are talking 'isolation', API restrictions, OS access denial, including file system hiding (perhaps).

This led to a notion of a sandbox region, or subsystem (or whatever), where 'risky' apps could be run. Can we implement this using the region concept in the kernel (with perhaps some LTW technology on top for API protection)? Under the old nested frameworks api, yes, K reckons we can. Under the new framework resolution hooks, it is not so clear. This led to a discussion of the new region implementation — Glyn seemed to think this was an interesting test of the new function in Equinox 3.7. I had the temerity to point out that it might even prove the Equinox spec proposals (implemented in 3.7) infeasible. Of course, this was time for lunch.

13:11 LUNCH

14:01 Roadmap

Here we started to outline what was on the near (and not so near) horizon. Gl;yn took us through the plans (tentative though they are) that we (s2) see are coming.

There is Spring 3.0.5 upgrade (trivial?); user region re-implementation (on Equinox 3.7) (not so trivial; Bundlor and tooling donation to Eclipse; extension to plan schema allowing URI as well as artifact TxNxV;