Hi Carsten, in this particular case we are struggeling with the fact that we need to uninstall "any" configuration and/or bundle comming through any installer that might be harmful. So we have a list of configs and bundles that would need to be forcefully uninstalled, yet we don't know exactly where those are. The instance at that point is shut down (this is about migration from one persistence to another) and I currently see no trivial way to find out where those install candidates come from and automatically remove them.
So the questions would be: a) how to get the exact source locations of install candidates (could probably be read from osgi installer cache!?)? b) how to properly uninstall the candidates (I assume for jcr we would need to start up the instance to perform this)? Cheers Dominik On Wed, Aug 3, 2016 at 9:50 AM, Carsten Ziegeler <cziege...@apache.org> wrote: > > Hi, > > > > I'm working on upgrade and migration process of JCR storage > formats/repository types for Sling and my goal is to remove completely some > OSGi configurations or bundles in offline mode related to storage format > that are no longer used and might conflict with the new storage options I > would like to install. > > > > My question simply is: What is the best practice of uninstalling OSGi > configurations in offline mode to be sure they are not reinstalled? > > > > The assumption here is that the Sling instance is completely not running > due to critical repository conversion, but at the same time my process has > a direct physical access to Sling launchpad and JCR repository folder > structure. > > > > The side effect that might be helpful here is that I'm planning to > change Sling runmode of that instance after migration but the configuration > I need to get rid is not necessary bound to any runmode and it might be > still active after starting the instance. > > > > I've noticed that I might try to get rid configurations from > /launchpad/config folder but they can be still picked up by OsgiInstaller > using [1] and [2] and put back into: /apps/system/config etc > > > > Maybe I should get rid of OSGi bundles or components instead of thinking > only about configuration? WDYT? > > Please let me know if I missed something or my approach is not necessary > a good/safe one. > > > > I think tempering with implementation details is not a good idea in > general. If the configuration has been installed through the OSGi > installer in the first place, removing the configuration from the source > will lead to the removal by the OSGi installer. Which means, if the > configuration is in the "install" folder on the file system, you can > remove it from there. If it's in the repository, remove it from the > repository. Everything else is then handled by the various installer parts. > > Carsten > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > >
