[JBoss JIRA] (JBIDE-22272) NPE when using LaunchBar to run an app on WildFly
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22272?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-22272.
---------------------------------
Resolution: Done
Fixed in linked (duplicate) issue
> NPE when using LaunchBar to run an app on WildFly
> -------------------------------------------------
>
> Key: JBIDE-22272
> URL: https://issues.jboss.org/browse/JBIDE-22272
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.4.0.Alpha1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.0.Final
>
>
> I tried to run jboss java ee web app from Central on WildFly 10 using launchbar. And it did work, but a NPE was thrown:
> {code}
> Plug-in: org.eclipse.debug.core
> An exception occurred during launch change notification.
> java.lang.NullPointerException
> at org.jboss.tools.wtp.server.launchbar.ModuleLaunchConfigurationProvider.getLaunchConfiguration(ModuleLaunchConfigurationProvider.java:84)
> at org.jboss.tools.wtp.server.launchbar.ModuleLaunchConfigurationProvider.launchDescriptorMatches(ModuleLaunchConfigurationProvider.java:128)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.launchDescriptorMatches(LaunchBarManager.java:964)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.getLaunchDescriptor(LaunchBarManager.java:942)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.setActive(LaunchBarManager.java:424)
> at org.eclipse.launchbar.core.internal.LaunchBarManager.access$0(LaunchBarManager.java:423)
> at org.eclipse.launchbar.core.internal.LaunchBarManager$2.launchAdded(LaunchBarManager.java:169)
> at org.eclipse.debug.internal.core.LaunchManager$LaunchNotifier.run(LaunchManager.java:446)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.debug.internal.core.LaunchManager$LaunchNotifier.notify(LaunchManager.java:433)
> at org.eclipse.debug.internal.core.LaunchManager.fireUpdate(LaunchManager.java:1043)
> at org.eclipse.debug.internal.core.LaunchManager.addLaunch(LaunchManager.java:703)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:834)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3556)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3492)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:367)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22578) Publishing sometimes recursively deletes parent to deploy directory
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22578?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22578:
--------------------------------
Sprint: devex #116 June 2017
> Publishing sometimes recursively deletes parent to deploy directory
> -------------------------------------------------------------------
>
> Key: JBIDE-22578
> URL: https://issues.jboss.org/browse/JBIDE-22578
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.1.Final
> Environment: Eclipse Mars.2 Release (4.5.2)
> Java 1.8.0_91
> Windows 7 64-bit
> JBoss EAP 6.4.0
> Reporter: Daniel Atallah
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.1.Alpha1
>
>
> For a number of weeks we've had a number of occurrences where a eclipse workspace will get corrupted due to the deletion of all files in it.
> It seems to have started happening at the time we updated to the 4.3.1 JBoss Tools from the 4.3.0 JBoss Tools.
> We've been able to track the process doing the deleting to the Eclipse process by using Sysinternals Process Monitor tool (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx).
> Our workspaces are structured as follows:
> {noformat}
> WORKSPACEROOT=$DEVROOT\workspacename
> # Custom deploy folder (as specified in the "Deployment" settings for the configured "Red Hat JBoss Enterprise Application Platform 6.1+") Server
> $WORKSPACEROOT\deploy
> # Version Control (Mercurial) working directory containing various Eclipse projects that get published to the Server by the tooling
> $WORKSPACEROOT\src
> # value specified as a "jboss.server.data.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/data
> # value specified as a "jboss.server.temp.dir" property in the Server launch configuration VM arguments
> $WORKSPACEROOT/server/tmp
> {noformat}
> The Server is configured to "Automatically publish when resources change".
> What we're seeing is that occasionally when the Server is running and the Mercurial working copy receives updates, the Incremental Publishing that results from these updates somehow tries to recursively delete $WORKSPACEROOT.
> The eclipse log includes the following:
> {noformat}
> !ENTRY org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problems occurred refreshing resources
> !SUBENTRY 1 org.eclipse.core.resources 4 1 2016-06-07 16:05:57.795
> !MESSAGE Problem finding next change, code: 5
> !ENTRY org.jboss.ide.eclipse.as.core 4 1644298244 2016-06-07 16:06:09.207
> !MESSAGE Incremental publish failed for module $MODULENAME
> !SUBENTRY 1 org.jboss.ide.eclipse.as.wtp.core 4 1644298251 2016-06-07 16:06:09.207
> !MESSAGE Could not delete $WORKSPACEROOT. May be locked by another process.
> {noformat}
> Any idea what might be happening?
> Is there some debug logging we can enable to get better visibility to what's going on?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22472) Improve UI of per-module zip settings
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22472?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22472:
--------------------------------
Sprint: devex #116 June 2017
> Improve UI of per-module zip settings
> -------------------------------------
>
> Key: JBIDE-22472
> URL: https://issues.jboss.org/browse/JBIDE-22472
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.4.0.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> This is a follow up of JBIDE-22157 and JBIDE-20577.
> When you were implementing JBIDE-22157, you asked me for feedback which I gave you but there was no further reply from you:
> https://github.com/jbosstools/jbosstools-server/pull/412
> {quote}
> what happens if I select to zip all? the new column does not apply then? it would be good to make this obvious somehow.
> also, could it be a checkbox instead of false/true?
> {quote}
> 1) Could we have checkboxes instead of true/false?
> 2) On a new server adapter, a "false" actually means "see default above" - once you change the default to compress all, each "false" will change to "true". But once you change a module to true and then back to false, changing the default will no longer affect the module settings anymore. This is counter intuitive.
> So what would make more sense in my opinion is to have checkboxes for each module and then perhaps a link called "all" at the column header? And get rid of the default settings? What do you think?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22591) Saving new username/pw during prompt for pw while starting cdk fails
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22591?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-22591:
--------------------------------
Sprint: devex #116 June 2017
> Saving new username/pw during prompt for pw while starting cdk fails
> ---------------------------------------------------------------------
>
> Key: JBIDE-22591
> URL: https://issues.jboss.org/browse/JBIDE-22591
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.0.Final
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.4.1.Alpha1
>
>
> When the server is in a project rather than in memory, persisting changes to the server (ie changing its username) will fail because the scheduling rule for starting the server does not include the ability to modify projects. This scenario will need to be identified (is server in memory or project) and a workspace job will need to be scheduled to properly persist the changes.
> java.lang.IllegalArgumentException: Attempted to beginRule: L/Servers/Container Development Environment.server, does not match outer scope rule: Container Development Environment
> at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
> at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:134)
> at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:333)
> at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:85)
> at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:307)
> at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:121)
> at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2188)
> at org.eclipse.core.internal.resources.File.setContents(File.java:334)
> at org.eclipse.core.internal.resources.File.setContents(File.java:434)
> at org.eclipse.wst.server.core.internal.Base.saveToFile(Base.java:251)
> at org.eclipse.wst.server.core.internal.Server.saveToFile(Server.java:471)
> at org.eclipse.wst.server.core.internal.Base.doSave(Base.java:264)
> at org.eclipse.wst.server.core.internal.Server.doSave(Server.java:466)
> at org.eclipse.wst.server.core.internal.ServerWorkingCopy.save(ServerWorkingCopy.java:434)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.CDKServer.getPassword(CDKServer.java:124)
> at org.jboss.tools.openshift.cdk.server.core.internal.adapter.controllers.CDKLaunchController.launch(CDKLaunchController.java:158)
> at org.jboss.ide.eclipse.as.wtp.core.server.launch.ControllableServerLaunchConfiguration.launch(ControllableServerLaunchConfiguration.java:52)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
> at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
> at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3556)
> at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3492)
> at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:367)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JBIDE-22261) Server Adapter: "Show in > Server Log" should open the current running pod log
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22261?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22261:
-------------------------------------
The server log references the server log view. Admittedly it's not a terribly useful view and is old and decaying. We should consider removing it entirely, or at least discussing it's future.
The goal of the view was to be be a unique error log where various status codes in an IStatus option can have icons associated with it, and events could be organized based on what 'type' they were (ie publish, start, poll, etc).
I think changing show in -> Server Log to have a different behavior in openshift is not a good idea unless we deprecate or rework the concept of the view.
> Server Adapter: "Show in > Server Log" should open the current running pod log
> ------------------------------------------------------------------------------
>
> Key: JBIDE-22261
> URL: https://issues.jboss.org/browse/JBIDE-22261
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.1.Final
> Reporter: Fred Bricon
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.x
>
>
> It's currently not practical to open the log for the running server adapter. Users need to open the pod log from the OpenShift Explorer.
> Instead, "Show in > Server Log" should open the current running pod log, from the OpenShift 3 Server adapter, in the Servers view.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months