Details
-
Type:
Task
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Sprint:Fall 8
Description
After fixing all the errors that appeared during the JDK21 migration, IGB works well in Mac and Linux (both development and installers). However, with Windows, there exists an issue with the LookandFeel classes. It was later identified by David Norris that the issue was caused because these classes are being called in IGB.java and migrated the specific block of code to OSGIHandler.java and IGB was able to open up. Unfortunately, this code change broke the Linux workflow. So David thought the best course of action would be to do Linux specific changes in IGB.java and the Windows specific changes in OSGIHandler.java. This worked in Linux but not in Windows.
Turns importing UIManager and LookandFeel classes in IGB is causing an issue. Both classes have static methods, so they are loaded too early and it is unable to identify the Java native classes it needs to work the look and feel.
Initial changes in Windows: https://bitbucket.org/KarthikRavee91/karthikfork-igb/commits/dae47e819ce174d40c675bf4a402e78d51265415
Changes in Linux by David: https://bitbucket.org/hillrunner2008/integrated-genome-browser/commits/2271bb786bf72aae278f53422a6ba3b8cc5429e7
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Epic Link |
|
| Status | To-Do [ 10305 ] | In Progress [ 3 ] |
| Description |
After fixing all the errors that appeared during the JDK21 migration, IGB works well in Mac and Linux (both development and installers). However, with Windows, there exists an issue with the LookandFeel classes. It was later identified by David Norris that the issue was caused because these classes are being called in IGB.java and migrated the specific block of code to OSGIHandler.java and IGB was able to open up. Unfortunately, this code change broke the Linux workflow. So David thought the best course of action would be to do Linux specific changes in IGB.java and the Windows specific changes in OSGIHandler.java. This worked in Linux but not in Windows.
Turns importing UIManager and LookandFeel classes in IGB is causing an issue. Both classes have static methods, so they are loaded too early and it is unable to identify the Java native classes it needs to work the look and feel. Initial changes in Windows: https://bitbucket.org/KarthikRavee91/karthikfork-igb/commits/dae47e819ce174d40c675bf4a402e78d51265415 Changes in Linux by David: https://bitbucket.org/KarthikRavee91/karthikfork-igb/commits/dae47e819ce174d40c675bf4a402e78d51265415 |
| Description |
After fixing all the errors that appeared during the JDK21 migration, IGB works well in Mac and Linux (both development and installers). However, with Windows, there exists an issue with the LookandFeel classes. It was later identified by David Norris that the issue was caused because these classes are being called in IGB.java and migrated the specific block of code to OSGIHandler.java and IGB was able to open up. Unfortunately, this code change broke the Linux workflow. So David thought the best course of action would be to do Linux specific changes in IGB.java and the Windows specific changes in OSGIHandler.java. This worked in Linux but not in Windows.
Turns importing UIManager and LookandFeel classes in IGB is causing an issue. Both classes have static methods, so they are loaded too early and it is unable to identify the Java native classes it needs to work the look and feel. Initial changes in Windows: https://bitbucket.org/KarthikRavee91/karthikfork-igb/commits/dae47e819ce174d40c675bf4a402e78d51265415 Changes in Linux by David: https://bitbucket.org/KarthikRavee91/karthikfork-igb/commits/dae47e819ce174d40c675bf4a402e78d51265415 |
After fixing all the errors that appeared during the JDK21 migration, IGB works well in Mac and Linux (both development and installers). However, with Windows, there exists an issue with the LookandFeel classes. It was later identified by David Norris that the issue was caused because these classes are being called in IGB.java and migrated the specific block of code to OSGIHandler.java and IGB was able to open up. Unfortunately, this code change broke the Linux workflow. So David thought the best course of action would be to do Linux specific changes in IGB.java and the Windows specific changes in OSGIHandler.java. This worked in Linux but not in Windows.
Turns importing UIManager and LookandFeel classes in IGB is causing an issue. Both classes have static methods, so they are loaded too early and it is unable to identify the Java native classes it needs to work the look and feel. Initial changes in Windows: https://bitbucket.org/KarthikRavee91/karthikfork-igb/commits/dae47e819ce174d40c675bf4a402e78d51265415 Changes in Linux by David: https://bitbucket.org/hillrunner2008/integrated-genome-browser/commits/2271bb786bf72aae278f53422a6ba3b8cc5429e7 |
After testing David's new changes, where he changed the Windows lookandfeel an error appears but IGB in Metal look and feel runs:
WARNING: Repository url http://felix.apache.org/obr/releases.xml cannot be used. Skipped. org.xmlpull.v1.XmlPullParserException: unexpected type (position:END_DOCUMENT null@1:0 in java.io.InputStreamReader@781654f8) at org.kxml2.io.KXmlParser.exception(Unknown Source) at org.kxml2.io.KXmlParser.nextTag(Unknown Source) at org.apache.felix.bundlerepository.impl.PullParser.parseRepository(PullParser.java:47) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.repository(DataModelHelperImpl.java:168) at org.apache.felix.bundlerepository.impl.DataModelHelperImpl.repository(DataModelHelperImpl.java:141) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl$1.run(RepositoryAdminImpl.java:114) at java.base/java.security.AccessController.doPrivileged(AccessController.java:571) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl.addRepository(RepositoryAdminImpl.java:110) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl.addRepository(RepositoryAdminImpl.java:98) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl.addRepository(RepositoryAdminImpl.java:93) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl.initialize(RepositoryAdminImpl.java:279) at org.apache.felix.bundlerepository.impl.RepositoryAdminImpl.discoverResources(RepositoryAdminImpl.java:189) at org.lorainelab.igb.plugin.manager.BundleInfoManager.getFilteredRepositoryBundles(BundleInfoManager.java:114) at org.lorainelab.igb.plugin.manager.BundleInfoManager.refreshBundleInfo(BundleInfoManager.java:72) at org.lorainelab.igb.plugin.manager.BundleInfoManager.activate(BundleInfoManager.java:61) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:245) at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:687) at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:531) at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:354) at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:115) at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:1002) at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:975) at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:920) at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:349) at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:249) at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:362) at org.apache.felix.framework.Felix.getService(Felix.java:3984) at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:450) at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:88) at org.apache.felix.scr.impl.inject.methods.BindMethod.getServiceObject(BindMethod.java:675) at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2612) at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1401) at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1830) at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:1060) at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:955) at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:920) at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:349) at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:249) at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:362) at org.apache.felix.framework.Felix.getService(Felix.java:3984) at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:450) at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:88) at org.apache.felix.scr.impl.inject.methods.BindMethod.getServiceObject(BindMethod.java:675) at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2612) at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.prebind(DependencyManager.java:1401) at org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1830)
| Attachment | Metal_LNF.png [ 18163 ] |
David Norris has fixed the issue following request for assistance from Nowlan Freese - see Dec 20 email subject heading: "igb windows error"
Request:
Hey David,
Thank you again for all of your help over the last few weeks. So far everything has been running well in IGB, other than on Windows. The error that you and Karthik were working on late Thursday seems to still be an issue. The issue is sporadic, but for the most part IGB won't run on Windows. We've been trying to figure out what is going on by comparing the changes you made on Karthik's laptop (commit) versus the changes that were pushed to the main-JDK21-with-javafx-no-theme branch (commit).
I've got a Windows laptop set up (Danny's old MSI laptop) so I can try things out. I know you are off the clock, but any suggestions would be appreciated!
Thank you!
Nowlan
The commit that fixed the error was:
KR and NF have both tested the new installer built with the above new commit and observed that the problem is GONE.
It looks the upgraded version of felix we started using had a change in how it was finding configuration files for the framework. Because the configuration file wasn't get found, the new felix was trying to use a default configuration file.
| Status | In Progress [ 3 ] | Needs 1st Level Review [ 10005 ] |
| Status | Needs 1st Level Review [ 10005 ] | First Level Review in Progress [ 10301 ] |
| Status | First Level Review in Progress [ 10301 ] | Ready for Pull Request [ 10304 ] |
| Status | Ready for Pull Request [ 10304 ] | Pull Request Submitted [ 10101 ] |
| Status | Pull Request Submitted [ 10101 ] | Reviewing Pull Request [ 10303 ] |
| Status | Reviewing Pull Request [ 10303 ] | Merged Needs Testing [ 10002 ] |
| Status | Merged Needs Testing [ 10002 ] | Post-merge Testing In Progress [ 10003 ] |
| Resolution | Done [ 10000 ] | |
| Status | Post-merge Testing In Progress [ 10003 ] | Closed [ 6 ] |
| Assignee | Karthik Raveendran [ karthik ] | David Norris [ david.norris ] |
Changes are merged and build is triggered.
Testing for this fix will be done as part of "smoke testing ticket" - IGBF-3510.
Removing the imports from IGB.java seems to work but this will definitely fail in Linux. A work around needs to be found to time the loading of the look and feel after the native Java classes are loaded.