[JBoss JIRA] (JBIDE-22878) EAR deployed from DevStudio to EAP contains errorneously named ejbs
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22878?page=com.atlassian.jira.plugi... ]
Rob Stryker reassigned JBIDE-22878:
-----------------------------------
Assignee: Martin Malina (was: Rob Stryker)
> EAR deployed from DevStudio to EAP contains errorneously named ejbs
> -------------------------------------------------------------------
>
> Key: JBIDE-22878
> URL: https://issues.jboss.org/browse/JBIDE-22878
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Final, 4.4.0.Final
> Environment: I've observed this problem on a Win7 64 bit machine with Oracle JRE 1.8.0_102 64 bit. It was present in both JBoss Developer Studio 8.1.0.GA and 10.0.0.GA when used in conjunction with embedded Maven installation and JBoss EAP 6.4 target runtime.
> Reporter: Mikhail Kalkov
> Assignee: Martin Malina
> Fix For: 4.4.2.AM2
>
> Attachments: JBIDE-22878-deployment-assembly.png, screendump.png, test-ear.ear, test-projects.zip
>
>
> I've created a maven-based EAR project that contains serveral ejb modules some of which come from workspace whereas others are downloaded from binary artifact repository. All modules have bundleFileName specified as module-name.jar in order to override the default module-name-version.jar.
> When I right-click on an EAR project and choose Export..., a correct EAR file is built, which looks exactly the same as when I build it from command line. However, when I add this project to an EAP 6.4 server, and check "Deploy projects as compressed archives" option, an EAR with erroneously named ejbs is deployed. the bundleFileName option is namely ignored for EJBs that come from binary artifact repository. See attached screenshot.
> This problem makes it extremely difficult to debug issues that arise only with zipped ear deployments. The only workaround is to comment out bundleFileName lines in test-ear pom.xml as well as possibly fix filenames in persistence.xml, and remember to revert these changes before committing!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-22878) EAR deployed from DevStudio to EAP contains errorneously named ejbs
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22878?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22878:
-------------------------------------
[~mmalina] Plesae try to replicate
> EAR deployed from DevStudio to EAP contains errorneously named ejbs
> -------------------------------------------------------------------
>
> Key: JBIDE-22878
> URL: https://issues.jboss.org/browse/JBIDE-22878
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Final, 4.4.0.Final
> Environment: I've observed this problem on a Win7 64 bit machine with Oracle JRE 1.8.0_102 64 bit. It was present in both JBoss Developer Studio 8.1.0.GA and 10.0.0.GA when used in conjunction with embedded Maven installation and JBoss EAP 6.4 target runtime.
> Reporter: Mikhail Kalkov
> Assignee: Martin Malina
> Fix For: 4.4.2.AM2
>
> Attachments: JBIDE-22878-deployment-assembly.png, screendump.png, test-ear.ear, test-projects.zip
>
>
> I've created a maven-based EAR project that contains serveral ejb modules some of which come from workspace whereas others are downloaded from binary artifact repository. All modules have bundleFileName specified as module-name.jar in order to override the default module-name-version.jar.
> When I right-click on an EAR project and choose Export..., a correct EAR file is built, which looks exactly the same as when I build it from command line. However, when I add this project to an EAP 6.4 server, and check "Deploy projects as compressed archives" option, an EAR with erroneously named ejbs is deployed. the bundleFileName option is namely ignored for EJBs that come from binary artifact repository. See attached screenshot.
> This problem makes it extremely difficult to debug issues that arise only with zipped ear deployments. The only workaround is to comment out bundleFileName lines in test-ear pom.xml as well as possibly fix filenames in persistence.xml, and remember to revert these changes before committing!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23266) CDK Server adapter: keeps starting CDK not aborting it when cancel button is pushed
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23266?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-23266:
-------------------------------------
If I misunderstand this jira, please re-open it.
As far as I can tell, the operation *IS* aborted. It just shows an error dialog additionally. The server is also set to 'stopped' on the abort.
If this isn't what you're seeing, please make a screencast
> CDK Server adapter: keeps starting CDK not aborting it when cancel button is pushed
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-23266
> URL: https://issues.jboss.org/browse/JBIDE-23266
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.2.AM1
> Reporter: Jeff MAURY
> Assignee: Rob Stryker
> Priority: Trivial
> Labels: cdk, server
> Fix For: 4.4.2.AM2
>
>
> When the credential dialog is show when starting the CDK server, if the user push the Cancel button, then an error dialog is then show where the operation should be aborted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBIDE-23266) CDK Server adapter: keeps starting CDK not aborting it when cancel button is pushed
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23266?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-23266.
---------------------------------
Resolution: Rejected
Unfortunately there's no way to fix this. The current error dialog is because I throw a CoreException during the launch. I do this intentionally, however, because if I don't, a generic error dialog shows up which only says
{code}
"Starting Container Development Environment" has encountered a problem:
Server Container Development Environment has failed to start."
{code}
This message is a default message any time a server's "launch" has been set to "starting" and then later set to "stopped". It's an automatic message and cannot be prevented. It can, however, be superceded if we throw our own CoreException which opens a more informative dialog.
You may think of a clever workaround: how about if we don't set it to starting at all, until AFTER we have all the info we need, and know the user didn't cancel? Well, WTP has us blocked there. If we are asked to 'start' the server, and our launch method returns without setting the server to starting, the same error dialog appears.
Basically,
1) if we don't set server to "starting", WTP will show error.
2) If we do set it to starting, but then to 'stopped' after, WTP will show error
3) There exists no way to suppress an error dialog,
4) Our CoreException is a bit more informative than what WTP shows.
Sucks to say, but there's no real workaround for this at all.
> CDK Server adapter: keeps starting CDK not aborting it when cancel button is pushed
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-23266
> URL: https://issues.jboss.org/browse/JBIDE-23266
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.2.AM1
> Reporter: Jeff MAURY
> Assignee: Rob Stryker
> Priority: Trivial
> Labels: cdk, server
> Fix For: 4.4.2.AM2
>
>
> When the credential dialog is show when starting the CDK server, if the user push the Cancel button, then an error dialog is then show where the operation should be aborted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBDS-3863) Platform Installer Hung after CDK install failed, no way to cancel, no info on error.
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3863?page=com.atlassian.jira.plugin.... ]
Denis Golovin updated JBDS-3863:
--------------------------------
Labels: ui (was: )
> Platform Installer Hung after CDK install failed, no way to cancel, no info on error.
> --------------------------------------------------------------------------------------
>
> Key: JBDS-3863
> URL: https://issues.jboss.org/browse/JBDS-3863
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: platform-installer
> Affects Versions: 1.1.0.GA, 9.1.0.Beta1
> Environment: Windows 7/64 bit.
> (Some components of previous manual CDK install on the system).
> Also Windows 10/64.
> Reporter: Robert Terzi
> Assignee: Denis Golovin
> Labels: ui
> Fix For: 10.2.0.AM2
>
> Attachments: box-add-fail-1.1.0-ga.txt, install.log, jbds-install-log-win7-error.txt
>
>
> Using the platform installer, CDK installation failed, progress shown as 99%. At this point the installer was hung.
> Note:
> * CDK install progress said Failed, with progress stuck at 99%.
> * There is no way to cancel out of the install.
> * There was no pop-up about error messages.
> * No indication of where to look for error messages/logs etc.was provided.
> * CDK was previously installed manually. However, the installer window didn't say a previous CDK installation was detected, but the log does show it deleted the previous cdkv2 box.
> From the log it looks like the box add command failed. When originally reported it might have been due to disk space, but it's not clear/obvious from the log. As of DevSuite 1.1.0 GA, the problems still exists if the vagrant box add command fails. Note: I've verified this isn't related to disk space and is a Vagrant problem.
> Note: after killing the installer and trying the `vagrant box add` command copied from the log file manually in Cygwin bash the box add command succeeded. The test system had 5-15 GB of free space between the installation started.
> Full log attached, excerpt here.
> Tue, 26 Apr 2016 18:05:38 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\rhel-vagrant-virtualbox.box to c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\rhel-vagrant-virtualbox.box to c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\pscp.exe to c:\sw\rhjbds\cdk\bin\pscp.exe
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Move C:\Users\rct\AppData\Local\Temp\7zSC53C.tmp\pscp.exe to c:\sw\rhjbds\cdk\bin\pscp.exe SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write c:\sw\rhjbds\cdk\components\rhel\rhel-ose\.cdk
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Write c:\sw\rhjbds\cdk\components\rhel\rhel-ose\.cdk SUCCESS
> Tue, 26 Apr 2016 18:05:43 GMT-INFO: cdk - Execute powershell -ExecutionPolicy,ByPass,-File,C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute powershell -ExecutionPolicy,ByPass,-File,C:\Users\rct\AppData\Local\Temp\set-pscp-path.ps1 SUCCESS
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - postVagrantSetup called
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute command vagrant plugin install "c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem"
> Tue, 26 Apr 2016 18:05:44 GMT-INFO: cdk - Execute options {
> "env": {
> "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;"
> }
> }
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Installing the 'c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem' plugin. This can take a few minutes...
> Installed the plugin 'vagrant-registration (1.2.1)'!
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute vagrant plugin install "c:\sw\rhjbds\cdk\plugins\vagrant-registration-1.2.1.gem" SUCCESS
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute command vagrant box remove cdkv2 -f
> Tue, 26 Apr 2016 18:05:55 GMT-INFO: cdk - Execute options {
> "env": {
> "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;"
> }
> }
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Removing box 'cdkv2' (v0) with provider 'virtualbox'...
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute vagrant box remove cdkv2 -f SUCCESS
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute command vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box"
> Tue, 26 Apr 2016 18:06:02 GMT-INFO: cdk - Execute options {
> "env": {
> "path": "C:\\HashiCorp\\Vagrant\\bin;C:\\Program Files\\Oracle\\VirtualBox\\;"
> }
> }
> Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk - Error: Command failed: vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box"
> The box failed to unpackage properly. Please verify that the box
> file you're trying to add is not corrupted and try again. The
> output from attempting to unpackage (if any):
> x box.ovf
> x Vagrantfile
> x vagrant-virtualbox-box.vmdk: Write failed
> x metadata.json
> bsdtar.EXE: Error exit delayed from previous errors.
> Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk - The box failed to unpackage properly. Please verify that the box
> file you're trying to add is not corrupted and try again. The
> output from attempting to unpackage (if any):
> x box.ovf
> x Vagrantfile
> x vagrant-virtualbox-box.vmdk: Write failed
> x metadata.json
> bsdtar.EXE: Error exit delayed from previous errors.
> Tue, 26 Apr 2016 18:06:10 GMT-ERROR: cdk failed to install: Error: Command failed: vagrant box add --name cdkv2 "c:\sw\rhjbds\cdk\boxes\rhel-vagrant-virtualbox.box"
> The box failed to unpackage properly. Please verify that the box
> file you're trying to add is not corrupted and try again. The
> output from attempting to unpackage (if any):
> x box.ovf
> x Vagrantfile
> x vagrant-virtualbox-box.vmdk: Write failed
> x metadata.json
> bsdtar.EXE: Error exit delayed from previous errors.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ERT-433) Invalid octal escape sequence (\8) causes IllegalArgumentException [EBZ#501790]
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/ERT-433?page=com.atlassian.jira.plugin.sy... ]
Victor Rubezhny updated ERT-433:
--------------------------------
Story Points: 2
> Invalid octal escape sequence (\8) causes IllegalArgumentException [EBZ#501790]
> -------------------------------------------------------------------------------
>
> Key: ERT-433
> URL: https://issues.jboss.org/browse/ERT-433
> Project: Eclipse Release Train
> Issue Type: Task
> Components: JSDT
> Reporter: Friendly Jira Robot
> Assignee: Victor Rubezhny
> Priority: Critical
> Labels: General, bzira
>
> Created attachment 264269
> Stack Trace
> Any file containing a string with '\8' or '\9' in it will cause an IllegalArgumentException whenever ASTParser executes on it. This prevents the JavaScript editor from being initialized, preventing normal opening of the file.
> '\#' in pre ES5 is used to denote an octal escape sequence, and so \8 and \9 are indeed invalid, but this should be reported as an error in the file.
> The error is thrown in org.eclipse.wst.jsdt.core.util.JsStringScanner#scanEscape() and is not caught.
> To reproduce: create a new JavaScript file, add the line `var x = "\8"` to it,
> and attempt to save the file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ERT-433) Invalid octal escape sequence (\8) causes IllegalArgumentException [EBZ#501790]
by Victor Rubezhny (JIRA)
[ https://issues.jboss.org/browse/ERT-433?page=com.atlassian.jira.plugin.sy... ]
Victor Rubezhny updated ERT-433:
--------------------------------
Sprint: devex #122 October 2016
> Invalid octal escape sequence (\8) causes IllegalArgumentException [EBZ#501790]
> -------------------------------------------------------------------------------
>
> Key: ERT-433
> URL: https://issues.jboss.org/browse/ERT-433
> Project: Eclipse Release Train
> Issue Type: Task
> Components: JSDT
> Reporter: Friendly Jira Robot
> Assignee: Victor Rubezhny
> Priority: Critical
> Labels: General, bzira
>
> Created attachment 264269
> Stack Trace
> Any file containing a string with '\8' or '\9' in it will cause an IllegalArgumentException whenever ASTParser executes on it. This prevents the JavaScript editor from being initialized, preventing normal opening of the file.
> '\#' in pre ES5 is used to denote an octal escape sequence, and so \8 and \9 are indeed invalid, but this should be reported as an error in the file.
> The error is thrown in org.eclipse.wst.jsdt.core.util.JsStringScanner#scanEscape() and is not caught.
> To reproduce: create a new JavaScript file, add the line `var x = "\8"` to it,
> and attempt to save the file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months