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