[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 1/21/15 7:32 AM:
---------------------------------------------------------------
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS. File changes can be made in Stopped and Started states, but not in Stopping and Starting states.
was (Author: dlmiles):
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying marker has been removed by the AS.
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles commented on JBIDE-18862:
--------------------------------------
If you are checking for *.isdeploying (which is also a server managed marker file).
Then yes you can remove a *.dodeploy marker that still exists from a previous publish that has not yet been actioned by the AS.
Multiple sequential publishes in the Eclipse are normal, the first might take 10 seconds to project build and publish the next 2 publish operations (due to editor file saves) might take 1 second for each to complete. It is normal for the AS to not notice the *.dodeploy yet.
If the AS did notice then the publish operation (and has started to deploy) Eclipse should be blocking due to the *.isdeploying marker being down. Since it should not be performing any file change operations in the deployment/ directory until there *.isdeploying market has been removed by the AS.
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-19042) Cannot login via Openshift Explorer on Openshift "Can not verify User"
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19042?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-19042 at 1/21/15 6:35 AM:
-------------------------------------------------------------------
[~steljboss] JBDS 7 is outdated, the latest is 8. Does your issue also happen with JBDS 8?
was (Author: adietish):
[~steljboss] JBDS 7 is old, the latest is 8. Does your issue also happen with JBDS 8?
> Cannot login via Openshift Explorer on Openshift "Can not verify User"
> ----------------------------------------------------------------------
>
> Key: JBIDE-19042
> URL: https://issues.jboss.org/browse/JBIDE-19042
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.x, 4.2.x
> Environment: Win7, jdk7, Openshift Online
> Reporter: Stylianos Koussouris
> Assignee: Andre Dietisheim
> Priority: Critical
> Attachments: CannotVerifyUser.JPG
>
>
> Trying to connect via Openshift explorer to Openshift Online, the credentials are correct and working from the Web UI, I receive
> Unknown error, can not verify user
> and in the log
> !ENTRY org.jboss.tools.openshift.express.ui 4 4 2015-01-15 15:01:37.848
> !MESSAGE
> !STACK 0
> java.lang.NullPointerException
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:196)
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.get(UrlConnectionHttpClient.java:113)
> at com.openshift.internal.client.RestService.request(RestService.java:151)
> at com.openshift.internal.client.RestService.request(RestService.java:107)
> at com.openshift.internal.client.RestService.request(RestService.java:100)
> at com.openshift.internal.client.RestService.request(RestService.java:81)
> at com.openshift.internal.client.AbstractOpenShiftConnectionFactory.getConnection(AbstractOpenShiftConnectionFactory.java:34)
> at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:134)
> at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:103)
> at org.jboss.tools.openshift.express.internal.core.connection.Connection.createUser(Connection.java:219)
> at org.jboss.tools.openshift.express.internal.core.connection.Connection.connect(Connection.java:199)
> at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPageModel.connect(ConnectionWizardPageModel.java:252)
> at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPage$ConnectJob.run(ConnectionWizardPage.java:474)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
> Similar Issue reported: https://forums.openshift.com/unknown-error-can-not-verify-user
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-19042) Cannot login via Openshift Explorer on Openshift "Can not verify User"
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19042?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-19042:
------------------------------------------
[~steljboss] JBDS 7 is old, the latest is 8. Does your issue also happen with JBDS 8?
> Cannot login via Openshift Explorer on Openshift "Can not verify User"
> ----------------------------------------------------------------------
>
> Key: JBIDE-19042
> URL: https://issues.jboss.org/browse/JBIDE-19042
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.x, 4.2.x
> Environment: Win7, jdk7, Openshift Online
> Reporter: Stylianos Koussouris
> Assignee: Andre Dietisheim
> Priority: Critical
> Attachments: CannotVerifyUser.JPG
>
>
> Trying to connect via Openshift explorer to Openshift Online, the credentials are correct and working from the Web UI, I receive
> Unknown error, can not verify user
> and in the log
> !ENTRY org.jboss.tools.openshift.express.ui 4 4 2015-01-15 15:01:37.848
> !MESSAGE
> !STACK 0
> java.lang.NullPointerException
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:196)
> at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.get(UrlConnectionHttpClient.java:113)
> at com.openshift.internal.client.RestService.request(RestService.java:151)
> at com.openshift.internal.client.RestService.request(RestService.java:107)
> at com.openshift.internal.client.RestService.request(RestService.java:100)
> at com.openshift.internal.client.RestService.request(RestService.java:81)
> at com.openshift.internal.client.AbstractOpenShiftConnectionFactory.getConnection(AbstractOpenShiftConnectionFactory.java:34)
> at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:134)
> at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:103)
> at org.jboss.tools.openshift.express.internal.core.connection.Connection.createUser(Connection.java:219)
> at org.jboss.tools.openshift.express.internal.core.connection.Connection.connect(Connection.java:199)
> at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPageModel.connect(ConnectionWizardPageModel.java:252)
> at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPage$ConnectJob.run(ConnectionWizardPage.java:474)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
> Similar Issue reported: https://forums.openshift.com/unknown-error-can-not-verify-user
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-19043) Error publishing jar inside utility project inside ear project
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19043?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19043:
-------------------------------------
[~mmalina] I've committed to master. Try to test it when you have time so we can consider it for 4.2.3.
> Error publishing jar inside utility project inside ear project
> --------------------------------------------------------------
>
> Key: JBIDE-19043
> URL: https://issues.jboss.org/browse/JBIDE-19043
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.2.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Beta1
>
>
> While verifying JBIDE-18862 I wanted to have some really big file to deploy so that I could see is an existing *.dodeploy marker is removed before the copying begins.
> So I created an ear project with a nested dynamic web project and utility project. Inside this utility project's src dir I copied JBDS installer jar. Then I tried to deploy the ear to a WildFly 8.2 server (both stopped and running).
> It seemed to work, the utility jar had 574 MB. But the tooling showed me this error:
> Publishing to wildfly has encountered a problem:
> {code}
> Error renaming /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/tmp/tmp582268190747176162.jar to /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
> It's true that this was on a different FS, but both the tmp and deploy dirs were one FS, so that should be fine.
> And just to be sure, I tried the same on the same FS and the error was the same:
> {code}
> Error renaming /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/tmp/tmp7876542570838575938.jar to /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-19043) Error publishing jar inside utility project inside ear project
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19043?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19043:
-------------------------------------
Basically, wtp is somehow treating the jar inside the utility project as yet another child module. This means it gets its own publish call. Due to some bad logic in my code, we were actually attempting this publish when we should have been ignoring it. Why should we be ignoring it? Because the utility project was already zipped, which means the installer jar is already in the zipped util output jar, and further requests can be ignored.
Basically, when we zip the util, it already has the installer... so when we get a request to publish the installer (or any other "child" of the utility project) directly after that, we should ignore it.
> Error publishing jar inside utility project inside ear project
> --------------------------------------------------------------
>
> Key: JBIDE-19043
> URL: https://issues.jboss.org/browse/JBIDE-19043
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.2.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Beta1
>
>
> While verifying JBIDE-18862 I wanted to have some really big file to deploy so that I could see is an existing *.dodeploy marker is removed before the copying begins.
> So I created an ear project with a nested dynamic web project and utility project. Inside this utility project's src dir I copied JBDS installer jar. Then I tried to deploy the ear to a WildFly 8.2 server (both stopped and running).
> It seemed to work, the utility jar had 574 MB. But the tooling showed me this error:
> Publishing to wildfly has encountered a problem:
> {code}
> Error renaming /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/tmp/tmp582268190747176162.jar to /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
> It's true that this was on a different FS, but both the tmp and deploy dirs were one FS, so that should be fine.
> And just to be sure, I tried the same on the same FS and the error was the same:
> {code}
> Error renaming /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/tmp/tmp7876542570838575938.jar to /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-19043) Error publishing jar inside utility project inside ear project
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19043?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-19043:
--------------------------------
Fix Version/s: 4.2.3.Final
4.3.0.Beta1
> Error publishing jar inside utility project inside ear project
> --------------------------------------------------------------
>
> Key: JBIDE-19043
> URL: https://issues.jboss.org/browse/JBIDE-19043
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.2.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.2.3.Final, 4.3.0.Beta1
>
>
> While verifying JBIDE-18862 I wanted to have some really big file to deploy so that I could see is an existing *.dodeploy marker is removed before the copying begins.
> So I created an ear project with a nested dynamic web project and utility project. Inside this utility project's src dir I copied JBDS installer jar. Then I tried to deploy the ear to a WildFly 8.2 server (both stopped and running).
> It seemed to work, the utility jar had 574 MB. But the tooling showed me this error:
> Publishing to wildfly has encountered a problem:
> {code}
> Error renaming /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/tmp/tmp582268190747176162.jar to /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
> It's true that this was on a different FS, but both the tmp and deploy dirs were one FS, so that should be fine.
> And just to be sure, I tried the same on the same FS and the error was the same:
> {code}
> Error renaming /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/tmp/tmp7876542570838575938.jar to /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBIDE-19043) Error publishing jar inside utility project inside ear project
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19043?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19043:
-------------------------------------
Replicated. Patch coming.
> Error publishing jar inside utility project inside ear project
> --------------------------------------------------------------
>
> Key: JBIDE-19043
> URL: https://issues.jboss.org/browse/JBIDE-19043
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.2.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> While verifying JBIDE-18862 I wanted to have some really big file to deploy so that I could see is an existing *.dodeploy marker is removed before the copying begins.
> So I created an ear project with a nested dynamic web project and utility project. Inside this utility project's src dir I copied JBDS installer jar. Then I tried to deploy the ear to a WildFly 8.2 server (both stopped and running).
> It seemed to work, the utility jar had 574 MB. But the tooling showed me this error:
> Publishing to wildfly has encountered a problem:
> {code}
> Error renaming /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/tmp/tmp582268190747176162.jar to /Volumes/Data/jbossqa/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
> It's true that this was on a different FS, but both the tmp and deploy dirs were one FS, so that should be fine.
> And just to be sure, I tried the same on the same FS and the error was the same:
> {code}
> Error renaming /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/tmp/tmp7876542570838575938.jar to /Users/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/deployments/earproj.ear/lib/utilproj.jar/jboss-devstudio-8.0.2.GA-v20150114-2029-B382-installer-standalone.jar.
> This may be caused by incorrect file permissions, or your server's temporary deploy directory may be on a different filesystem than the final destination.
> You may adjust these settings in the server editor.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months