OSGi configuration removal when Sling sleeps

[Arek Kita <ar...@adobe.com>]

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.

Thanks in advance,
Arek


[1] https://sling.apache.org/documentation/bundles/file-installer-provider.html
[2] https://sling.apache.org/documentation/bundles/jcr-installer-provider.html

-- 
Arkadiusz Kita | Adobe R&D Software Engineer

Re: OSGi configuration removal when Sling sleeps

[Dominik Süß <do...@gmail.com>]

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 <cz...@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
> cziegeler@apache.org
>
>

Re: OSGi configuration removal when Sling sleeps

[Carsten Ziegeler <cz...@apache.org>]

> 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
cziegeler@apache.org