On second thought... s/fails/falls short for/ On Aug 9, 2010, at 7:27 AM, Justin Edelson <justinedel...@gmail.com> wrote:
> > > On Aug 9, 2010, at 4:59 AM, Felix Meschberger <fmesc...@gmail.com> wrote: > >> 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. > AFAICT, the bundles (and now configs) will still be extracted from the > launchpad artifact. I agree that if we're going to extract these files, we > should use FileInstall. However, I don't agree that we should be doing this > extraction in the first place. > >> >> 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. > > Agreed. But what I think we both value more than overkill and code > duplication is ease of comprehension and this is where I think the current > scheme fails us. > > Justin >> >> 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 >>>> >>>
