Closed cmrockwell closed 2 years ago
It seems that resources from the new release have not been installed correctly. Deleting all Composum Core/Nodes bundles should fix the problem. Use the OSGi web console (/system/console/bundles) to delete all Composum Core/Nodes bundles and reinstall the current bundles. After a reboot everything should work again.
I took the following steps on my Sling12 Starter instance.
/system/console/bundles
grep -r "composum-nodes" sling/framework
I identified all the Composum bundles just installed, and removed them IE rm -rf sling/framework/bundle248
I have now tested this on a fresh Sling 12 (snapshot) instance. I did the upgrade manually via '/system/console/bundle'. But after a reboot both (!) versions were active, version 1.12.0 and version 2.1.1... It seems that the new feature model here restores the version declared as feature at startup in any case. But both versions can't be active at the same time, because they represent the same resources. Unfortunately, I haven't found an alternative way to successfully upgrade an existing Sling 12 instance.
I have now successfully tested an upgrade from Composum Nodes 1.12.0 to 2.2.1 based on Kickstarter 0.0.12.
I have created a new Sling instance with Kickstarter 0.0.12. After starting this instance, I deleted all the Composum bundles (version 1.12.0) and stopped the instance.
I then built a Kickstarter JAR 0.0.13-SNAPSHOT with the configuration customized for Composum Nodes 2.2.1 and replaced the Kickstarter JAR file in the previously stopped instance with the newly built Kickstarter JAR file.
the used 'composum.json' feature configuration:
{
"bundles":[
{
"id":"com.composum.nodes:composum-nodes-commons:2.2.1",
"start-order":"20"
},
{
"id":"com.composum.nodes:composum-nodes-console:2.2.1",
"start-order":"20"
},
{
"id":"com.composum.nodes:composum-nodes-jslibs:2.2.1",
"start-order":"20"
},
{
"id":"com.composum.nodes:composum-nodes-pckgmgr:2.2.1",
"start-order":"20"
},
{
"id":"com.composum.nodes:composum-nodes-usermgr:2.2.1",
"start-order":"20"
}
],
"configurations":{
"org.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment~composum":{
"whitelist.bundles":[
"com.composum.nodes.commons",
"com.composum.nodes.pckgmgr",
"com.composum.nodes.pckginstall"
],
"whitelist.name":"composum.nodes"
}
}
}
After the subsequent start of the Sling instance, only the Composum Nodes bundles in the new version were installed and active.
However, the described error with the login prompt then occurred.
Assuming that the bundles had been updated, but not the repository content embedded in them, I manually installed the bundles, which had actually already been installed correctly, once again via the OSGi console.
After that, the problem was solved.
In my case, the 'composum' whitelist for the administrative login was not correctly adjusted right away. I therefore had to adjust it manually via the configuration view of the OSGi console. That's why I renamed the whitelist in the above configuration.
BTW Do you recommend Oracle or Open JDK? Which is Composum developed and tested with?
There are no preferences, it should run with Oracle as well as with OpenJDK without any problems. In the past Oracle prevailed, but this is shifting more and more to OpenJDK. We test it sometimes on one and sometimes on the other JDK. Currently our central test instance runs on CentOS and OpenJDK 11, my local test system on Mac OS X and Oracle JDK 11...
With Releas 2.5.0 Composum Nodes is available as a package for installation / upgrade via package manager. This installation via package (composum-nodes-sling-package-<version>.zip) is the preferred solution for future installations/upgrades of Composum Nodes. A 'setup' bundle is used to remove an existing version of Composum Nodes before the installation of the new version controlled by the 'setup' bundle starts. This should hopefully eliminate the problems with the upgrade. https://search.maven.org/search?q=a:composum-nodes-sling-package
we stumbled about this issue when doing last smoke test on the Sling 12 Starter release - which includes the latest composum nodes release 4.0.1. we have seen this problem only when starting Sling 12 Starter on Windows (not using WSL): https://issues.apache.org/jira/browse/SLING-11168
however, this issues is marked as solved. but in this case it was not an "upgrade" scenario. it was a fresh sling 12 instance including composum 4.0.1 which is broken on Windows.
@ist-rw any hints?
I can't relate to that. I built the starter version 12 and started it in a Windows 10 VM (VMware): no exceptions in the logfile and no visible problems.
thanks for cross-checking. actually it seems windows in a VM on mac is not affected.
in the meantime we identified the root cause on side of sling - https://issues.apache.org/jira/browse/SLING-11189 should fix the issue.
Since this was traced bug to a sling bug that was marked as fixed and the fix version is contained in Sling Starter 12, I'd like to close this issue. Please feel free to open it again, if you think it's our fault and we can do something about it. Thank you for reporting it!
After updating one of my local Sling instances, there Composum Console (/bin/browser.html) is not working with the screenshot below. Previous version was 1.12.0 updated to 2.1.1
With the log messages..
15.12.2020 14:52:55.925 WARN [0:0:0:0:0:0:0:1 [1608061975765] GET /bin/browser.html HTTP/1.1] com.composum.sling.clientlibs.service.DefaultClientlibService Could not resolve css:category:composum.components.widgets 15.12.2020 14:52:55.927 WARN [0:0:0:0:0:0:0:1 [1608061975765] GET /bin/browser.html HTTP/1.1] com.composum.sling.clientlibs.processor.RenderingVisitor Not present: mand. css:category:composum.components.widgets referenced from css:/libs/composum/nodes/console/clientlibs/base/css 15.12.2020 14:52:55.943 WARN [0:0:0:0:0:0:0:1 [1608061975765] GET /bin/browser.html HTTP/1.1] com.composum.sling.clientlibs.service.DefaultClientlibService Could not resolve css:category:composum.components.widgets
Is there any advice how to correct the situation? perhaps a way to reinstall
Hard to troubleshoot without /bin/browser.html