Hi, On 06.08.2010 21:07, Justin Edelson wrote: > 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.
That is, as I understand it, the exact goal right now: Instead of duplicating implementation code with File Install we leverage File Install. This makes our Launchpad code base smaller and easier to understand and maintain while even extending the overall functionality. > > 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) I agree, that the Jackrabbit Configuration file is a real issue right now. Because it currently is hard to easily overwrite in a fresh installation. We should look for a solution to this problem.... > > 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. Yes, this ssems odd and overkill. But I valuate this not as critical as duplicating code. If this is a concern I suggest generating a ZIP (or compressed tar) file consisting of something like this: * raw launchpad with just the log and file install bundles * bundles and configurations to be installed After unpacking the package file can be discarded. (Of course I still think the all-encompassing executable JAR-file a major asset of Sling) > >> 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. It is really about the Configuration Admin service package. Of course we will never integrate the Configuration Admin implementation with Launchpad Base (this would severly violate the separation of concerns principle). Still, I would discourage adding the Configuration Admin service package to launchpad base. Because this might cause problems should the API be extended in the future (or increase the version number as has been done in R 4.2). > >> 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. Sling definitely doesn't require start levels. We introduced them to workaround an implementation issue with early Felix framework releases with respect to finding a consistent classspace for imports/exports and to somehow create kind of a layered system setup. And yes, File Install does not have support for start levels yet and such support will have to be added. But I would assume, that we are not the only ones with a requirement to add start level support to file install. > > 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. A standalone library with a single file (or two files) in it is probably not worth the effort ;-) And the discussion on felix-dev was exactly to leverage the configuration file format of the Configuration Admin service and to reuse the configuration file parser in File Install by means of the Embed-Dependency functionality of the bundle plugin. > > 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. Thanks alot for sharing and keep on enjoying your vacation ;-) Regards Felix > > 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 >> >
