On Aug 10, 2010, at 6:10 AM, Felix Meschberger <fmesc...@gmail.com> wrote:
> > > On 09.08.2010 21:14, Justin Edelson wrote: >> The problem is that the current scheme doesn't handle the case where the >> launchpad JAR is updated in a consistent manner. Whenever this is raised, >> the answer is to deploy bundles via sling:install or the web console. In my >> experience, this technique just doesn't scale past a single node. Perhaps >> Ace is a better answer for this, but I think updating the JAR should have a >> consistent effect. > > Well, actually, the current launchpad always has supported bundle > updates by using a new Launchpad JAR file file. > > Because on startup the launcher checks, whether the standalone JAR file > has a more recent last modification time than the previously launched > JAR file in the same sling.home location. Then there's a bug. Because IIRC, the check is actually done using the embedded launchpad base JAR, not the (outer/standalone) launchpad archive. > > If so, the embedded bundles are unpackage. > > Next, the unpack location is scanned for updates since the last > installation. If so, any updated bundles (bundles are never downgraded > by this mechanism) or new bundles are installed. I also think there's a problem with duplicate bundles, but I've only observed this a few times, so am not 100% confident of it, > > So, we already have this mechanis, and this should keep on working of > course. > >> >> It is my belief that the only way to fix this situation is by loading >> bundles from VFS layer we have rather than extracting the bundles. I could >> (of course) be wrong about this and I have not prioritized this (I've got a >> set of RightScripts which will get me by in the near term). But my fear is >> that by removing the code you're suggesting we remove, fixing this issue >> becomes that much harder. >> >>> >>> With using File Install and copying stuff to a well defined directory we >>> enable other use cases. If people want to deploy or remove stuff at >>> runtime, they can just drop/remove stuff from this directory. >> >> At minimum, I'd like to see us recommend against doing this. If we need to >> extract files from the archive, let's do that in a directory where we tell >> users not to touch and then create a 'dropins' directory for user-managed >> files. If users manipulate the extracted files, things can go haywire when >> Launchpad decides to re-extract the archive. > > Well, the goal of unpacking in effect was to enable administrators to > put more bundles to be installed on next startup (or to be installed on > first startup if Sling is distributed as a ZIP containing the launchpad > and the bundles). As I said, this looks like a separate concern and results in exposing an implementation detail (the extraction of bundles) unnecessarily. A discreet directory would be cleaner IMHO. Justin > > Regards > Felix > >> >>> >>> There are other scenarios possible where for example the launchpad app >>> does not contain all the bundles anymore, but they are picked up by File >>> Install etc. >> We already have an alternate scenario - launchpad:run and launchpad:start >> use bundles (OK, artifacts) from the local Maven repository. And now that >> Aether has been released, I'm going to start experimenting with this in >> Launchpad itself. >> >> If you can give me about 10 days, I'll have a different ConfigAdmin solution. >> >> Sorry to be a stick in the mud about this.... >> >> Justin >> >> On Aug 9, 2010, at 11:38 AM, Carsten Ziegeler <cziege...@apache.org> wrote: >> >>> I agree that having to copy the bundles (and other files) before they >>> get installed is odd (especially as they are copied once more by the >>> framework). But on the other hand this is imho a minor issue compared to >>> what we gain. >>> >>> Let's assume that when using Sling disk space is not that important. >>> >>> The copying of the files is transparent to the user: a launchpad is >>> created (either jar or war) which contains everything you want to >>> install (bundles, configs etc). With this use case in mind it doesn't >>> play a role if these things are copied, if File Install is used etc. It >>> just works. >>> >>> If we would use File Install, we add a well known and used instrument to >>> install stuff into an OSGi framework. So if people are known and used to >>> FileInstall, they are already familiar with this stuff. We don't have to >>> add all the support in Sling - which I think is a good thing; we already >>> have code for bundles and deployment packages. And imho we really need >>> support for config files. With using FileInstall we just reuse code. >>> Code which is developed and used by a much wider base. >>> >>> With using File Install and copying stuff to a well defined directory we >>> enable other use cases. If people want to deploy or remove stuff at >>> runtime, they can just drop/remove stuff from this directory. >>> >>> There are other scenarios possible where for example the launchpad app >>> does not contain all the bundles anymore, but they are picked up by File >>> Install etc. >>> >>> So in short :) I don't see any downside of this except the disk space - >>> but I see several advantages. >>> >>> Regards >>> Carsten >>> -- >>> Carsten Ziegeler >>> cziege...@apache.org >>
