Apologies in advance for reordering the bits from Carsten's email, but I think my response will make more sense this way.
On Wed, Aug 4, 2010 at 9:53 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > > Currently the launchpad copies the initial set of bundles to a file > directory and creates a structure based on the start levels there. > Bundles are then picked up from there and installed. > Personally, I'd like to revisit this design. It seems unnecessary to copy the bundles to the file system vs. reading them directly from the InputStream. AFAICT, this was originally done to allow for additional bundles (i.e. ones not in the launchpad archive) to be placed in the startup directory, but that's exactly where FileInstall *should* be used. What I would like to see is that the ResourceProvider interface (the launchpad one, not the Sling API one) is treated like a virtual file system and that resources from this VFS are used directly by: 1) the bits in launchpad which install/start bundles 2) some ConfigAdmin bridge thingy 3) the jackrabbit.server bundle (in order to load the JR config from inside the archive) Yes... disk is cheap, but it seems wasteful that in a typical Sling install you end up with three copies of each bundle - one inside the archive, one in the startup directory, and one in the Felix cache. > while trying to implement handling of initial configurations for the > ConfigAdmin within our launchpad, I noticed that this is more difficult > than I thought. The final problem is a class loading issue as the > launchpad does not contain the compendium class (for config admin). > For the same reason, the current support of deployment packages is > broken in launchpad. The other obvious solution is to embed ConfigAdmin in Launchpad. I'm sure there are reasons not to do this, but I suspect that these are somewhat academic in nature given how stable the Felix ConfigAdmin implementation appears to be. > While trying to workarund these problems I came back to an idea I had a > long time ago: instead of doing all these installs (bundle, configs, > depl. pcks etc.) in our own code, why not use existing stuff? > The FileInstall bundle from Apache Felix covers most of our use cases - > there are some minor pieces missing. But we can add the required > features there and avoid duplicate code by just using File Install. I'm not sure these missing pieces are so minor... last I looked, File Install doesn't support start levels. Although I'm not sure Sling *needs* start levels, they are useful from an administrative perspective. It seems to me that what's really needed is a refactoring of ConfigAdmin and FileInstall (and JCR Install for that matter) to provide a unified, standalone config parsing library. I believe I saw some discussion on felix-dev about having FileInstall use the config parsing bits from the ConfigAdmin bundle. This is better than having code duplication, but a standalone library still seems better to me. All that said, I'm on vacation and haven't been able to fully process this. But I did want to raise my concerns now before this got too far. Justin > Note, that File Install is mainly used to get initial configuration into > the system - so it's more bootstrapping - for everything else jcr > install can be used. Or File Install is nice for all those scenarios > where no repository is used :) > > WDYT? > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org >
