Hi all
The migration guide (Performing an In-Place Upgrade) says that it is important to bring up the instance with the quickstart jar file. But what I tried is doing the migration with the quickstart war file. Is this possible too or do I have necessariily have to use the self executing jar file? The way I did does not trigger any upgrade process. Apache Felix is not coming up, the first bundle it tries to load fails with the following message:
06-Dec-2017 10:38:11.770 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Setting sling.home=C:\apache-tomcat-8.5.24-author\bin\author (servlet parameter sling.home)
06-Dec-2017 10:38:11.775 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Sling Extension Lib Home : C:\apache-tomcat-8.5.24-author\bin\author\launchpad\ext
06-Dec-2017 10:38:11.783 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Checking launcher JAR in C:\apache-tomcat-8.5.24-author\bin\author
06-Dec-2017 10:38:11.783 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Checking launcher JAR in folder C:\apache-tomcat-8.5.24-author\bin\author\launchpad
06-Dec-2017 10:38:11.791 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Existing launcher is up to date, using it: 5.6.0.2_6_10-B001 (org.apache.sling.launchpad.base.jar)
06-Dec-2017 10:38:11.794 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Loading launcher class org.apache.sling.launchpad.base.webapp.SlingServletDelegate from org.apache.sling.launchpad.base.jar
06-Dec-2017 10:38:11.795 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: External Libs Home (ext) is null or does not exists.
06-Dec-2017 10:38:11.803 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Starting launcher ...
06-Dec-2017 10:38:11.803 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log granite: Starting Apache Sling in C:\apache-tomcat-8.5.24-author\bin\author
06-Dec-2017 10:38:13.582 SEVERE [FelixStartLevel] org.apache.catalina.core.ApplicationContext.log ERROR: Error starting slinginstall:C:\apache-tomcat-8.5.24-author\bin\author\launchpad\startup\0\org.apache.felix.http.bridge-2.2.0.jar (org.osgi.framework.BundleException: Unable to resolve org.apache.felix.http.bridge [1](R 1.1): missing requirement [org.apache.felix.http.bridge [1](R 1.1)] osgi.ee; (&(osgi.ee=JavaSE)(version=1.6)) Unresolved requirements: [[org.apache.felix.http.bridge [1](R 1.1)] osgi.ee; (&(osgi.ee=JavaSE)(version=1.6))])
org.osgi.framework.BundleException: Unable to resolve org.apache.felix.http.bridge [1](R 1.1): missing requirement [org.apache.felix.http.bridge [1](R 1.1)] osgi.ee; (&(osgi.ee=JavaSE)(version=1.6)) Unresolved requirements: [[org.apache.felix.http.bridge [1](R 1.1)] osgi.ee; (&(osgi.ee=JavaSE)(version=1.6))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4112)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2118)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:745)
I feel like Apache Felix and Sling are still in the old version..
Thanks,
Chris
Solved! Go to Solution.
Views
Replies
Total Likes
Thanks for all the input so far!
I got it working!
I had a lot of dependency resolving errors on Sling startup saying that Java 6 and JAva 7 where missing... I don't really get it. But in the end the following lines made it work:
# prepended "JavaSE-1.8" here
ee-1.8=JavaSE-1.8,JavaSE-1.7,JavaSE-1.6,J2SE-1.5,J2SE-1.4,J2SE-1.3, J2SE-1.2,JRE-1.1,JRE-1.0,OSGi/Minimum-1.2,OSGi/Minimum-1.1, OSGi/Minimum-1.0
# appended "1.8" here
eecap-1.8=osgi.ee; osgi.ee\="OSGi/Minimum"; version\:List<Version>\="1.0,1.1,1.2", osgi.ee; osgi.ee\="JavaSE"; version\:List<Version>\="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"
I don't really get why I had to do this manually, though..
Views
Replies
Total Likes
It is possible. I have been using 2 instances of AEM on the same weblogic. Are you doing a vanila AEM 6.0 to AEM 6.3 migration ?
Can you elaborate the steps you performed so far?
Views
Replies
Total Likes
I recommend following the official docs when upgrading. If you run into issues and followed the docs exactly - open a support ticket as they can help you if you require a hotfix.
Views
Replies
Total Likes
Hi Hermant
Thanks for your reply. I saw that there is documentation for migrating web application server installations here: Upgrade Steps for Application Server Installations
I followed the steps except for the repository migration, because we already use crx3 with mongo. When starting the Tomcat, Sling does not startup successfully.
I'm now comparing the installation folders of my migrated instance with a freseh AEM 6.3, Tomcat, tarMK installation.
Views
Replies
Total Likes
Also - if you follow the doc exactly and run to issue - please open a support ticket. You may require a patch that they can provide.
Views
Replies
Total Likes
I don't have an appserver instance handy, but please validate your sling.properties file. Have you followed the documentation at [1]? I covers an upgrade from 5.6.1 to 6.3 (not from 6.0), but it might give you good hints what to do. I would recommend to review the section about modification of the sling.properties file.
Views
Replies
Total Likes
Thanks for all the input so far!
I got it working!
I had a lot of dependency resolving errors on Sling startup saying that Java 6 and JAva 7 where missing... I don't really get it. But in the end the following lines made it work:
# prepended "JavaSE-1.8" here
ee-1.8=JavaSE-1.8,JavaSE-1.7,JavaSE-1.6,J2SE-1.5,J2SE-1.4,J2SE-1.3, J2SE-1.2,JRE-1.1,JRE-1.0,OSGi/Minimum-1.2,OSGi/Minimum-1.1, OSGi/Minimum-1.0
# appended "1.8" here
eecap-1.8=osgi.ee; osgi.ee\="OSGi/Minimum"; version\:List<Version>\="1.0,1.1,1.2", osgi.ee; osgi.ee\="JavaSE"; version\:List<Version>\="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"
I don't really get why I had to do this manually, though..
Views
Replies
Total Likes
Thank you for posting the solution.
Views
Replies
Total Likes
Beside that your workaround is now fixed in AEM 6.3 SP3, I experienced a Problem with some OSGi bundles. In my case it was the ehcache 3.6.0 bundle, but I think there are a lot more, so I put this information in this thread, maybe someone will find it useful.
First I checked the instance config at localhost:4502/system/console/status-slingprops:
org.osgi.framework.system.capabilities = osgi.ee; osgi.ee="OSGi/Minimum"; version:List<Version>="1.0,1.1,1.2", osgi.ee; osgi.ee="JavaSE"; version:List<Version>="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"
-> so everything is fine.
When I upload the bundle within felix console everything is fine, but if I try to use the auto install "/crx-quickstart/install" the bundle write the following error log
org.osgi.framework.BundleException: Unable to resolve ehcache [1337](R 1337.2): missing requirement [ehcache [1337](R 1337.2)] osgi.ee; (&(osgi.ee=JavaSE)(version=1.8)) Unresolved requirements: [[ehcache [1337](R 1337.2)] osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))]
It seem to me that AEM auto install still uses the old LDAP search version filter for Require-Capabilities, see Bug-Report below:
My lesson learned: Try to upload the bundle in felix directly to test if there is a problem with AEM auto install.
Views
Likes
Replies
Views
Like
Replies