[JBoss JIRA] (JBIDE-26311) EAP 7.1 fails to stop when connected over ssh
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26311?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-26311:
-------------------------------------
I'm not able to replicate. I've attached a screencast. I will admit this screencast was using a "localhost" type connection instead of ssh, but, once I realized that, I re-ran my test with an ssh connection and noticed no difference.
I mean... i COULD make a new video with teh correct connection type, but, I promise you it appears to work fine.
Caveats: I'm using the new TP, AM3 version, which Nick pushed out last night. Seems to work :|
> EAP 7.1 fails to stop when connected over ssh
> ---------------------------------------------
>
> Key: JBIDE-26311
> URL: https://issues.jboss.org/browse/JBIDE-26311
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.9.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: regression
> Attachments: JBIDE-26311.local.ogv
>
>
> I have an EAP 7.1 setup up over ssh. It's running on my localhost, so it's the most basic test of an ssh server. When I click the stop button on the server, it says:
> Server Red Hat JBoss EAP 7.1 ssh failed to stop.
> An exception stack trace is not available.
> It will stop on second attempt. On a local server this would mean killing the server java process. I'm not sure exactly what happens on a remote server, but it works.
> I'm pretty sure this worked last time (previous milestone).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (JBIDE-26311) EAP 7.1 fails to stop when connected over ssh
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26311?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-26311:
--------------------------------
Attachment: JBIDE-26311.local.ogv
> EAP 7.1 fails to stop when connected over ssh
> ---------------------------------------------
>
> Key: JBIDE-26311
> URL: https://issues.jboss.org/browse/JBIDE-26311
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.9.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Labels: regression
> Attachments: JBIDE-26311.local.ogv
>
>
> I have an EAP 7.1 setup up over ssh. It's running on my localhost, so it's the most basic test of an ssh server. When I click the stop button on the server, it says:
> Server Red Hat JBoss EAP 7.1 ssh failed to stop.
> An exception stack trace is not available.
> It will stop on second attempt. On a local server this would mean killing the server java process. I'm not sure exactly what happens on a remote server, but it works.
> I'm pretty sure this worked last time (previous milestone).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (JBDS-4711) Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4711?page=com.atlassian.jira.plugin.... ]
Nick Boldt reassigned JBDS-4711:
--------------------------------
Assignee: Josef Kopriva (was: Nick Boldt)
> Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4711
> URL: https://issues.jboss.org/browse/JBDS-4711
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, upstream
> Affects Versions: 12.0.0.GA
> Environment: F28 + 12.0.0.GA-v20180625-0632-B2859
> Reporter: Josef Kopriva
> Assignee: Josef Kopriva
> Priority: Minor
> Fix For: 12.9.0.AM3
>
>
> After every start of devstudio, there is a warning:
> {code:java}
> eclipse.buildId=12.0.0.GA-v20180625-0632-B2859
> 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: -data file:/home/jkopriva/devstudio_B2859_2/workspace/ -os linux -ws gtk -arch x86_64 -product com.jboss.devstudio.core.product
> org.eclipse.egit.core
> Warning
> Mon Jun 25 13:18:32 CEST 2018
> Builtin LFS support not present/detected
> java.lang.ClassNotFoundException: org.eclipse.jgit.lfs.BuiltinLFS cannot be found by org.eclipse.egit.core_5.0.0.201806131550-r
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
> 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 java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.eclipse.egit.core.Activator.registerBuiltinLFS(Activator.java:279)
> at org.eclipse.egit.core.Activator.start(Activator.java:212)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> 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.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:454)
> 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.egit.ui.Activator$RepositoryChangeScanner.<init>(Activator.java:921)
> at org.eclipse.egit.ui.Activator.setupRepoChangeScanner(Activator.java:1034)
> at org.eclipse.egit.ui.Activator.start(Activator.java:336)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> 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.services.WorkbenchServiceRegistry.getSourceProviders(WorkbenchServiceRegistry.java:174)
> at org.eclipse.ui.internal.services.SourceProviderService.readRegistry(SourceProviderService.java:104)
> at org.eclipse.ui.internal.Workbench$34.runWithException(Workbench.java:2378)
> at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:32)
> at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:233)
> at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:144)
> at org.eclipse.swt.widgets.Display.syncExec(Display.java:5831)
> at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:95)
> at org.eclipse.ui.internal.Workbench.initializeDefaultServices(Workbench.java:2373)
> at org.eclipse.ui.internal.Workbench.init(Workbench.java:1654)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2859)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:597)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (JBDS-4711) Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4711?page=com.atlassian.jira.plugin.... ]
Nick Boldt resolved JBDS-4711.
------------------------------
Resolution: Done
We're now using egit/jgit 5.1 [1] so I assume this is fixed. I'll let [~jkopriva] verify and close or reopen if it's still a problem.
[1] http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.9...
> Add support for LFS via egit to Devstudio/JBoss Tools? (was ClassNotFoundException in Error Log after start: Builtin LFS support not present/detected)
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBDS-4711
> URL: https://issues.jboss.org/browse/JBDS-4711
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, upstream
> Affects Versions: 12.0.0.GA
> Environment: F28 + 12.0.0.GA-v20180625-0632-B2859
> Reporter: Josef Kopriva
> Assignee: Nick Boldt
> Priority: Minor
> Fix For: 12.9.0.AM3
>
>
> After every start of devstudio, there is a warning:
> {code:java}
> eclipse.buildId=12.0.0.GA-v20180625-0632-B2859
> 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: -data file:/home/jkopriva/devstudio_B2859_2/workspace/ -os linux -ws gtk -arch x86_64 -product com.jboss.devstudio.core.product
> org.eclipse.egit.core
> Warning
> Mon Jun 25 13:18:32 CEST 2018
> Builtin LFS support not present/detected
> java.lang.ClassNotFoundException: org.eclipse.jgit.lfs.BuiltinLFS cannot be found by org.eclipse.egit.core_5.0.0.201806131550-r
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508)
> 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 java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.eclipse.egit.core.Activator.registerBuiltinLFS(Activator.java:279)
> at org.eclipse.egit.core.Activator.start(Activator.java:212)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> 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.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36)
> at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:454)
> 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.egit.ui.Activator$RepositoryChangeScanner.<init>(Activator.java:921)
> at org.eclipse.egit.ui.Activator.setupRepoChangeScanner(Activator.java:1034)
> at org.eclipse.egit.ui.Activator.start(Activator.java:336)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
> at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
> at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:729)
> at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1002)
> at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:354)
> at org.eclipse.osgi.container.Module.doStart(Module.java:581)
> at org.eclipse.osgi.container.Module.start(Module.java:449)
> at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:468)
> at org.eclipse.osgi.internal.hooks.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:114)
> at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:505)
> 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.services.WorkbenchServiceRegistry.getSourceProviders(WorkbenchServiceRegistry.java:174)
> at org.eclipse.ui.internal.services.SourceProviderService.readRegistry(SourceProviderService.java:104)
> at org.eclipse.ui.internal.Workbench$34.runWithException(Workbench.java:2378)
> at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:32)
> at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:233)
> at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:144)
> at org.eclipse.swt.widgets.Display.syncExec(Display.java:5831)
> at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:95)
> at org.eclipse.ui.internal.Workbench.initializeDefaultServices(Workbench.java:2373)
> at org.eclipse.ui.internal.Workbench.init(Workbench.java:1654)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2859)
> at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:654)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:597)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (JBIDE-26147) Incremental publish not working with WF13, WF12 and WF11
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26147?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-26147.
---------------------------------
Resolution: Rejected
Closing as rejected. We cannot fix problem 1. Problem 2 is properly fixed via a full publish.
> Incremental publish not working with WF13, WF12 and WF11
> --------------------------------------------------------
>
> Key: JBIDE-26147
> URL: https://issues.jboss.org/browse/JBIDE-26147
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.6.0.AM3
> Reporter: Jeff MAURY
> Assignee: Rob Stryker
> Fix For: 4.9.0.Final
>
> Attachments: helloworld-rs.zip
>
>
> Deployed a JAX-RS application to WF11, WF12 and WF13. This application is using JAX-RS 2.1 server side event Sse injected into method parameter through @Context.
> This application is deployed but when an endpoint is used, an error is raised probably because WF is still on JAX-RS 2.0.
> Then this code is commented out, the application is incrementally published but the error persists
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (JBIDE-26147) Incremental publish not working with WF13, WF12 and WF11
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26147?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-26147.
---------------------------------
Resolution: Done
Incremental deployment is not guaranteed to work when method signatures are added or removed. When the server is started in 'run' mode, this will simply change the .class file. WildFly is not looking for changes to .class files when in run mode. Incremental deployment when in 'run' mode only really affects static files like html, css, js, etc.
When in debug mode, incremental deployment will copy the changed files (as in run mode) except the attached remote debugger will automatically update the running code. If a method signature changes, it may or may not work depending on the situation. Often times you'll get a hotcode replace error.
In both of these situations, the proper solution is to right-click on the module in the servers view and select full publish.
tl;dr, Incremental deployment has limitations. It is not magic and cannot work if the server is not looking for changes (run mode), or the changes cannot possibly be made (hotcode replace error in debug mode). In all cases, if your deployment seems broken, execute a full publish on it to fix it.
I tested this scenario. This scenario can be split into 2 problems:
1) Why is the getEvent method failing via classnotfoundException
2) Why, when re-commented, does the deployment not go back to normal?
Item 1 is due to wildfly having a lower version of jaxrs that does not have these classes. I / we cannot fix that here.
Item 2 was discussed above. Full publish makes it work again.
Marking as closed.
> Incremental publish not working with WF13, WF12 and WF11
> --------------------------------------------------------
>
> Key: JBIDE-26147
> URL: https://issues.jboss.org/browse/JBIDE-26147
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.6.0.AM3
> Reporter: Jeff MAURY
> Assignee: Rob Stryker
> Fix For: 4.9.0.Final
>
> Attachments: helloworld-rs.zip
>
>
> Deployed a JAX-RS application to WF11, WF12 and WF13. This application is using JAX-RS 2.1 server side event Sse injected into method parameter through @Context.
> This application is deployed but when an endpoint is used, an error is raised probably because WF is still on JAX-RS 2.0.
> Then this code is commented out, the application is incrementally published but the error persists
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (JBIDE-26147) Incremental publish not working with WF13, WF12 and WF11
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-26147?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-26147:
--------------------------------
Fix Version/s: 4.9.0.Final
(was: 4.9.0.AM3)
> Incremental publish not working with WF13, WF12 and WF11
> --------------------------------------------------------
>
> Key: JBIDE-26147
> URL: https://issues.jboss.org/browse/JBIDE-26147
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.6.0.AM3
> Reporter: Jeff MAURY
> Assignee: Rob Stryker
> Fix For: 4.9.0.Final
>
> Attachments: helloworld-rs.zip
>
>
> Deployed a JAX-RS application to WF11, WF12 and WF13. This application is using JAX-RS 2.1 server side event Sse injected into method parameter through @Context.
> This application is deployed but when an endpoint is used, an error is raised probably because WF is still on JAX-RS 2.0.
> Then this code is commented out, the application is incrementally published but the error persists
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
