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