DominikSuess commented on a change in pull request #6: SLING-9172 - adding
support for property sling.installer.multiversion…
URL:
https://github.com/apache/sling-org-apache-sling-installer-core/pull/6#discussion_r388239535
##########
File path:
src/main/java/org/apache/sling/installer/core/impl/tasks/BundleTaskCreator.java
##########
@@ -71,14 +71,17 @@
private BundleBlackList bundleBlacklist;
+ private boolean isMultiVersion;
+
/**
* @see
org.apache.sling.installer.core.impl.InternalService#init(org.osgi.framework.BundleContext,
org.apache.sling.installer.api.ResourceChangeListener, RetryHandler)
*/
@Override
public void init(final BundleContext bc, final ResourceChangeListener
listener, final RetryHandler retryHandler) {
this.bundleContext = bc;
this.retryHandler = retryHandler;
-
+
+ this.isMultiVersion =
Boolean.valueOf(bc.getProperty("sling.installer.multiversion")) ? true : false;
Review comment:
This doesn't match the scenario this is implemented for - this is supposed
to be a generic change as otherwise the upgrade can break certain scenarios you
cannot recover. The situation with this flag enabled might cause other issues
as you indicate but those are recoverable and can be fixed downstream. The
problem with the default behavior in cases wehre multiple versions of bundles
are active is that the installer destroys the state in an unrecoverable way.
Subsequently we will address downstream cases.
Sidenote - the Dynamic Classloader case is in fact not really related to
this case as multiple bundles (different BSNs) cause the same problem as of
today.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
