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 >>> >>
