[JBoss JIRA] (JBDS-4722) Problem creating splash implementation
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBDS-4722?page=com.atlassian.jira.plugin.... ]
Josef Kopriva closed JBDS-4722.
-------------------------------
Resolution: Done
> Problem creating splash implementation
> --------------------------------------
>
> Key: JBDS-4722
> URL: https://issues.jboss.org/browse/JBDS-4722
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: product
> Affects Versions: 12.9.0.AM1
> Reporter: Ondrej Dockal
> Assignee: Nick Boldt
> Fix For: 12.9.0.AM3
>
>
> I got a bunch of error while restarting/starting over devstudio.
> {code}
> Problem creating splash implementation
> java.lang.UnsupportedClassVersionError: com/jboss/devstudio/core/splash/SplashHandler has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:276)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:555)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:514)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:501)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:470)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:609)
> at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:177)
> at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:931)
> at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
> at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:60)
> at org.eclipse.ui.internal.WorkbenchPlugin.lambda$0(WorkbenchPlugin.java:288)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:71)
> at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:285)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory$1.run(SplashHandlerFactory.java:134)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory.create(SplashHandlerFactory.java:129)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory.processElement(SplashHandlerFactory.java:112)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory.findSplashHandlerFor(SplashHandlerFactory.java:60)
> at org.eclipse.ui.internal.Workbench.getSplash(Workbench.java:892)
> at org.eclipse.ui.internal.Workbench.access$2(Workbench.java:884)
> at org.eclipse.ui.internal.Workbench$2.run(Workbench.java:782)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.Workbench.createSplashWrapper(Workbench.java:846)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:597)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:560)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:656)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:592)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1498)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1471)
> Session data:
> eclipse.buildId=12.9.0.AM1-v20180726-1026-B3091
> java.version=1.8.0_172
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments: -product com.jboss.devstudio.core.product
> Command-line arguments: -os linux -ws gtk -arch x86_64 -product com.jboss.devstudio.core.product
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBDS-4722) Problem creating splash implementation
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBDS-4722?page=com.atlassian.jira.plugin.... ]
Josef Kopriva commented on JBDS-4722:
-------------------------------------
I have retested it with latest build and the error message is gone, so closing.
[~nickboldt] thx for fixing.
Verified in:
Red Hat Developer Studio
Version: 12.9.0.AM3
Build id: AM3-v20180829-0502-B3265
Build date: 20180829-0502
> Problem creating splash implementation
> --------------------------------------
>
> Key: JBDS-4722
> URL: https://issues.jboss.org/browse/JBDS-4722
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: product
> Affects Versions: 12.9.0.AM1
> Reporter: Ondrej Dockal
> Assignee: Nick Boldt
> Fix For: 12.9.0.AM3
>
>
> I got a bunch of error while restarting/starting over devstudio.
> {code}
> Problem creating splash implementation
> java.lang.UnsupportedClassVersionError: com/jboss/devstudio/core/splash/SplashHandler has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:276)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:555)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:514)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:501)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:328)
> at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:470)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411)
> at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:609)
> at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:177)
> at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:931)
> at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
> at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:60)
> at org.eclipse.ui.internal.WorkbenchPlugin.lambda$0(WorkbenchPlugin.java:288)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:71)
> at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:285)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory$1.run(SplashHandlerFactory.java:134)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory.create(SplashHandlerFactory.java:129)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory.processElement(SplashHandlerFactory.java:112)
> at org.eclipse.ui.internal.splash.SplashHandlerFactory.findSplashHandlerFor(SplashHandlerFactory.java:60)
> at org.eclipse.ui.internal.Workbench.getSplash(Workbench.java:892)
> at org.eclipse.ui.internal.Workbench.access$2(Workbench.java:884)
> at org.eclipse.ui.internal.Workbench$2.run(Workbench.java:782)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.Workbench.createSplashWrapper(Workbench.java:846)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:597)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:560)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:152)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:656)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:592)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1498)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1471)
> Session data:
> eclipse.buildId=12.9.0.AM1-v20180726-1026-B3091
> java.version=1.8.0_172
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Framework arguments: -product com.jboss.devstudio.core.product
> Command-line arguments: -os linux -ws gtk -arch x86_64 -product com.jboss.devstudio.core.product
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JBIDE-26323) Add JBoss Tools 4.9.0.AM1 to list of releases on tools.jboss.org
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26323?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-26323 at 8/28/18 3:06 PM:
-------------------------------------------------------------
I guess Mat didn't run any of the publishing scripts to copy from staging to development while I was on PTO / in Europe for the Che F2F.
I see stuff in stage, but not in prod. http://download.jboss.org/jbosstools/photon/staging/updates/core/
Why didn't you say anything the first week of August? I think we were all three NOT on PTO that week. I guess I assumed that if anything went wrong, you would contact me and him to get it sorted.
(Checking my old sent mail, it appears I may have implied accidentally that the staging steps were all that Mat was required to do in my absence -- not the release steps too. If that's the case, I'll try to be more explicit next time.)
Now that it's 28 days later, do we need to bother releasing AM1 after AM2? Who would ever want to download it when there's a newer version?
We could:
a) retarget the N&N files so they're for AM2 instead of AM1, or
b) omit the links to zips in products.yaml for the AM1 release (so at least the 'coming soon' label goes away), or
c) teach you how to run the scripts that copy from stage to prod, so you can run the Jenkins jobs to make sure AM1 is released.
WDYT?
was (Author: nickboldt):
I guess Mat didn't run any of the publishing scripts to copy from staging to development while I was on PTO / in Europe for the Che F2F.
I see stuff in stage, but not in prod. http://download.jboss.org/jbosstools/photon/staging/updates/core/
Why didn't you say anything the first week of August? I think we were all three NOT on PTO that week. I guess I assumed that if anything went wrong, you would contact me and him to get it sorted.
Now that it's 28 days later, do we need to bother releasing AM1 after AM2? Who would ever want to download it when there's a newer version?
We could:
a) retarget the N&N files so they're for AM2 instead of AM1, or
b) omit the links to zips in products.yaml for the AM1 release (so at least the 'coming soon' label goes away), or
c) teach you how to run the scripts that copy from stage to prod, so you can run the Jenkins jobs to make sure AM1 is released.
WDYT?
> Add JBoss Tools 4.9.0.AM1 to list of releases on tools.jboss.org
> ----------------------------------------------------------------
>
> Key: JBIDE-26323
> URL: https://issues.jboss.org/browse/JBIDE-26323
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: website
> Affects Versions: 4.9.0.AM1
> Reporter: Jeff MAURY
> Assignee: Jeff MAURY
> Fix For: 4.9.0.AM3
>
> Attachments: screenshot-1.png
>
>
> I noticed 4.9.0.AM1 was not defined in website causing this release to appear as 'Coming soon' even after 4.9.0.AM2 is out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JBIDE-26323) Add JBoss Tools 4.9.0.AM1 to list of releases on tools.jboss.org
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26323?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-26323 at 8/28/18 1:45 PM:
-------------------------------------------------------------
I guess Mat didn't run any of the publishing scripts to copy from staging to development while I was on PTO / in Europe for the Che F2F.
I see stuff in stage, but not in prod. http://download.jboss.org/jbosstools/photon/staging/updates/core/
Why didn't you say anything the first week of August? I think we were all three NOT on PTO that week. I guess I assumed that if anything went wrong, you would contact me and him to get it sorted.
Now that it's 28 days later, do we need to bother releasing AM1 after AM2? Who would ever want to download it when there's a newer version?
We could:
a) retarget the N&N files so they're for AM2 instead of AM1, or
b) omit the links to zips in products.yaml for the AM1 release (so at least the 'coming soon' label goes away), or
c) teach you how to run the scripts that copy from stage to prod, so you can run the Jenkins jobs to make sure AM1 is released.
WDYT?
was (Author: nickboldt):
I guess Mat didn't run any of the publishing scripts to copy from staging to development while I was on PTO / in Europe for the Che F2F.
I see stuff in stage, but not in prod. http://download.jboss.org/jbosstools/photon/staging/updates/core/
Why didn't you say anything the first week of August? I think we were all three NOT on PTO that week.
Anyway do we really need to bother with this? We could:
a) retarget the N&N files so they're for AM2 instead of AM1, or
b) omit the links to zips in products.yaml for the AM1 release (so at least the 'coming soon' label goes away), or
c) teach you how to run the scripts that copy from stage to prod, so you can run the Jenkins jobs to make sure AM1 is released.
WDYT?
> Add JBoss Tools 4.9.0.AM1 to list of releases on tools.jboss.org
> ----------------------------------------------------------------
>
> Key: JBIDE-26323
> URL: https://issues.jboss.org/browse/JBIDE-26323
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: website
> Affects Versions: 4.9.0.AM1
> Reporter: Jeff MAURY
> Assignee: Jeff MAURY
> Fix For: 4.9.0.AM3
>
> Attachments: screenshot-1.png
>
>
> I noticed 4.9.0.AM1 was not defined in website causing this release to appear as 'Coming soon' even after 4.9.0.AM2 is out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JBIDE-26323) Add JBoss Tools 4.9.0.AM1 to list of releases on tools.jboss.org
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26323?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-26323:
------------------------------------
I guess Mat didn't run any of the publishing scripts to copy from staging to development while I was on PTO / in Europe for the Che F2F.
I see stuff in stage, but not in prod. http://download.jboss.org/jbosstools/photon/staging/updates/core/
Why didn't you say anything the first week of August? I think we were all three NOT on PTO that week.
Anyway do we really need to bother with this? We could:
a) retarget the N&N files so they're for AM2 instead of AM1, or
b) omit the links to zips in products.yaml for the AM1 release (so at least the 'coming soon' label goes away), or
c) teach you how to run the scripts that copy from stage to prod, so you can run the Jenkins jobs to make sure AM1 is released.
WDYT?
> Add JBoss Tools 4.9.0.AM1 to list of releases on tools.jboss.org
> ----------------------------------------------------------------
>
> Key: JBIDE-26323
> URL: https://issues.jboss.org/browse/JBIDE-26323
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: website
> Affects Versions: 4.9.0.AM1
> Reporter: Jeff MAURY
> Assignee: Jeff MAURY
> Fix For: 4.9.0.AM3
>
> Attachments: screenshot-1.png
>
>
> I noticed 4.9.0.AM1 was not defined in website causing this release to appear as 'Coming soon' even after 4.9.0.AM2 is out.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JBIDE-26304) File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26304?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-26304:
------------------------------------------
I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=538367.
Closing this task.
> File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
> ----------------------------------------------------------------------
>
> Key: JBIDE-26304
> URL: https://issues.jboss.org/browse/JBIDE-26304
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.9.0.AM3
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.9.0.AM3
>
>
> JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
> While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
> We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
> h2. Steps:
> I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
> The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
> # ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
> # ASSERT: Initially I have
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="hello"
> {code}.
> # ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
> # EXEC: I go project preferences > Maven and choose the "openshift" profile
> # ASSERT: I see component settings being updated on disk.
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="ROOT"
> {code}.
> # RESULT: the configured module for my OpenShift server adapter is still called *hello*.
> # ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
> # EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
> # RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
> h2. Fix:
> To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
> {code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
> protected void cleanAllDelegates() {
> Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
> while(i.hasNext()) {
> i.next().clearCache();
> }
> + clearModuleCache();
> modulesChanged();
> }
> + @Override
> + public void clearModuleCache() {
> + clearCache(null);
> + }
> {code}
> ps. notice the oddness in terms of API:
> {code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JBIDE-26304) File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26304?page=com.atlassian.jira.plugi... ]
Andre Dietisheim closed JBIDE-26304.
------------------------------------
Resolution: Done
> File Eclipse bugzilla reporting J2EEDeployableFactory module cache bug
> ----------------------------------------------------------------------
>
> Key: JBIDE-26304
> URL: https://issues.jboss.org/browse/JBIDE-26304
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: openshift
> Affects Versions: 4.9.0.AM3
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.9.0.AM3
>
>
> JBIDE-22138 reported that the OpenShift Server adapter does not respect the "openshift" maven profile of a project.
> While implementing it we discovered that *J2EEDeployableFactory* is not clearing it's module cache when the *deploy-name* in *.settings/org.eclipse.wst.common.component* is changed.
> We need to file an Eclipse bug that reports this an create a PR for it (see *Fix* further down)
> h2. Steps:
> I have recorded the following screencast: https://www.youtube.com/watch?v=V_SdtXYkJHA&feature=youtu.be
> The following steps assume a change in maven profile which leads to a change in the deploy-name. The same can be achieved by simply editing *.settings/org.eclipse.wst.common.component* in an Eclipse editor, leaving maven aside.
> # ASSERT: I have a maven project "hello" where switching the profile switches the deployment name from *hello.war* (no profile selected) to *ROOT.war* (profile "openshift" selected).
> # ASSERT: Initially I have
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="hello"
> {code}.
> # ASSERT: Looking at the configured modules for my server adapter I see the module being called *hello*.
> # EXEC: I go project preferences > Maven and choose the "openshift" profile
> # ASSERT: I see component settings being updated on disk.
> {code:title=<workspace>hello/.settings/org.eclipse.wst.common.component}
> deploy-name="ROOT"
> {code}.
> # RESULT: the configured module for my OpenShift server adapter is still called *hello*.
> # ASSERT: the configured module for my OpenShift server adapter should be called *hello(ROOT)*.
> # EXEC: If I now go to some project property which updates the maven config (ex. Web Content Settings) and hit "Apply and Close"
> # RESULT: The available modules for my OpenShift Server adapter are updated, the configured module is now updated and called *hello(ROOT)*
> h2. Fix:
> To fix this bad behaviour one has to change *J2EEDeployableFactory* in the following way:
> {code:title=org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory}
> protected void cleanAllDelegates() {
> Iterator<FlatComponentDeployable> i = moduleDelegates.values().iterator();
> while(i.hasNext()) {
> i.next().clearCache();
> }
> + clearModuleCache();
> modulesChanged();
> }
> + @Override
> + public void clearModuleCache() {
> + clearCache(null);
> + }
> {code}
> ps. notice the oddness in terms of API:
> {code}protected void clearCache(IProject project){code} has a parameter *IProject* but it's not being used in this class, nor in the super classes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months