|Re: [virgo-dev] [gyrex-dev] Gyrex and Virgo|
Thanks for your response. Comments inline.
If the multiplicity of Virgo deliverables causes any confusion, please see this page:
and the section "Virgo Runtime Deliverables" (including Figures 9 & 10 which provide a quick summary) on pages 19-20 of the Virgo white paper:
On 13 Apr 2012, at 08:42, Gunnar Wagenknecht wrote:
Virgo Nano and Nano "full" have a single region, to keep things simple. There is a hot deployer (currently broken - bug 375965): you just put bundles to be installed/started in the pickup directory.
Virgo Kernel and higher (Virgo Tomcat and Jetty Servers) have multiple regions, but you can still just put bundles to be installed/started in the user region in the pickup directory.
Virgo Nano and Nano "full" sound like the best fit for Gyrex since they support runtime p2 provisioning into the kernel region (Kernel-based distributions only support initial provisioning of kernel+user regions and then runtime provisioning of the kernel region since p2 has no region support.)
The smallest Nano distribution has no web content. Similarly for the Kernel. The Nano "full" distribution is Tomcat based, as is Virgo Tomcat Server, so there should be no clash there. Virgo Jetty Server is where clashes are likely.
Sounds good. Virgo tends to aggressively start lazy activation bundles since we find that many people don't understand lazy activation (should only be used for bundles which will be activated by class or resource loading), but I don't think that's a particular issue for Virgo+Gyrex.
These edits could easily be applied to Virgo and the additional bundles placed in the plugins directory. This would install Gyrex into the kernel region, which is the only region for Nano and Nano "full".
I'd like to see ECF distributed OSGi running on Virgo, but I haven't found suitable runtime-oriented documentation. The ECF docs seem geared towards the Eclipse IDE. But mixing and matching other components with Gyrex on Virgo is not the initial use case and can be deferred.
Thanks. Sounds like too much work for the present. Let's aim for Nano+Gyrex initially as that should be trivial to get going.
Application and feature subsystems should work pretty much like Virgo's current support for scoped plans (or PARs) and unscoped plans, respectively. They should play nicely with Virgo's current diagnostics.
Composite subsystems may need some tweaks in order to share kernel diagnostics, but that's not something I'd thought about until now, so thanks for raising it.
Nice. Users can then probably pick and choose what to add to Virgo+Gyrex.