[JBoss JIRA] (JBDS-3798) Repeated component detection keeps stale values
by Jan Richter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3798?page=com.atlassian.jira.plugin.... ]
Jan Richter updated JBDS-3798:
------------------------------
Attachment: screenshot-1.png
> Repeated component detection keeps stale values
> -----------------------------------------------
>
> Key: JBDS-3798
> URL: https://issues.jboss.org/browse/JBDS-3798
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.1.0.CR1
> Environment: Setup-bundled-0.0.2-20160413-107
> Reporter: Jan Richter
> Assignee: Denis Golovin
> Labels: havoc
> Attachments: screenshot-1.png
>
>
> Installer detects existing tools on confirmation page. If after that a change happens (like the user uninstalls VirtualBox) and then the user goes to the previous page and to confirm page again - the change is correctly detected, but instead of replacing the old option, there are now both options for 'install' and 'use existing'.
> Using the existing (no longer existing in fact) installation fails, naturally.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3798) Repeated component detection keeps stale values
by Jan Richter (JIRA)
Jan Richter created JBDS-3798:
---------------------------------
Summary: Repeated component detection keeps stale values
Key: JBDS-3798
URL: https://issues.jboss.org/browse/JBDS-3798
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: installer
Affects Versions: 9.1.0.CR1
Environment: Setup-bundled-0.0.2-20160413-107
Reporter: Jan Richter
Assignee: Denis Golovin
Installer detects existing tools on confirmation page. If after that a change happens (like the user uninstalls VirtualBox) and then the user goes to the previous page and to confirm page again - the change is correctly detected, but instead of replacing the old option, there are now both options for 'install' and 'use existing'.
Using the existing (no longer existing in fact) installation fails, naturally.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3795) Cant start CDK
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3795?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov reassigned JBDS-3795:
------------------------------------
Assignee: Rob Stryker (was: Hardy Ferentschik)
[~rob.stryker] please take a look. CDK seems to work fine from CLI.
> Cant start CDK
> --------------
>
> Key: JBDS-3795
> URL: https://issues.jboss.org/browse/JBDS-3795
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: cdk, installer
> Affects Versions: 9.1.0.CR1
> Reporter: Alexey Kazakov
> Assignee: Rob Stryker
> Priority: Blocker
> Labels: havoc, respin-c
> Fix For: 9.1.0.CR1
>
> Attachments: screenshot-1.png
>
>
> CDK server adapter is not started when using JBDS + CDK April 8th build even after updating vagrant-service-manager to 1.0.1.
> "Unable to configure docker and openshift. Calls to vagrant service-manager are returning empty environments."
> I can access the OS console: https://10.1.2.2:8443/console
> The console output looks OK too:
> {code}
> Bringing machine 'default' up with 'virtualbox' provider...
> ==> default: Importing base box 'cdkv2'...
> [KProgress: 10%
> [KProgress: 20%
> [KProgress: 90%
> [K==> default: Matching MAC address for NAT networking...
> ==> default: Setting the name of the VM: rhel-ose_default_1460496916213_82608
> ==> default: Clearing any previously set network interfaces...
> ==> default: Preparing network interfaces based on configuration...
> default: Adapter 1: nat
> default: Adapter 2: hostonly
> ==> default: Forwarding ports...
> default: 22 => 2222 (adapter 1)
> ==> default: Running 'pre-boot' VM customizations...
> ==> default: Booting VM...
> ==> default: Waiting for machine to boot. This may take a few minutes...
> default: SSH address: 127.0.0.1:2222
> default: SSH username: vagrant
> default: SSH auth method: private key
> default: Warning: Connection timeout. Retrying...
> default: Warning: Remote connection disconnect. Retrying...
> default:
> default: Vagrant insecure key detected. Vagrant will automatically replace
> default: this with a newly generated keypair for better security.
> default:
> default: Inserting generated public key within guest...
> default: Removing insecure key from the guest if it's present...
> default: Key inserted! Disconnecting and reconnecting using new SSH key...
> ==> default: Machine booted and ready!
> ==> default: Checking for guest additions in VM...
> default: No guest additions were detected on the base box for this VM! Guest
> default: additions are required for forwarded ports, shared folders, host only
> default: networking, and more. If SSH fails on this machine, please install
> default: the guest additions and repackage the box to continue.
> default:
> default: This is not an error message; everything may continue to work properly,
> default: in which case you may ignore this message.
> ==> default: Configuring and enabling network interfaces...
> ==> default: Registering box with vagrant-registration...
> ==> default: Copying TLS certificates to C:/DeveloperPlatform/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> ==> default: Rsyncing folder: /cygdrive/c/DeveloperPlatform/cdk/components/rhel/rhel-ose/ => /vagrant
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default:
> ==> default: Successfully started and provisioned VM with 2 cores and 3072 MB of memory.
> ==> default: To modify the number of cores and/or available memory set the environment variables
> ==> default: VM_CPU respectively VM_MEMORY.
> ==> default:
> ==> default: You can now access the OpenShift console on: https://10.1.2.2:8443/console
> ==> default:
> ==> default: To use OpenShift CLI, run:
> ==> default: $ vagrant ssh
> ==> default: $ oc login 10.1.2.2:8443
> ==> default:
> ==> default: Configured users are (<username>/<password>):
> ==> default: openshift-dev/devel
> ==> default: admin/admin
> ==> default:
> ==> default: If you have the oc client library on your host, you can also login from your host.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3795) Cant start CDK
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBDS-3795?page=com.atlassian.jira.plugin.... ]
Alexey Kazakov commented on JBDS-3795:
--------------------------------------
Just tried the latest CDK from April 13th. The same error: "Unable to configure docker and openshift. Calls to vagrant service-manager are returning empty environments."
> Cant start CDK
> --------------
>
> Key: JBDS-3795
> URL: https://issues.jboss.org/browse/JBDS-3795
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: cdk, installer
> Affects Versions: 9.1.0.CR1
> Reporter: Alexey Kazakov
> Assignee: Hardy Ferentschik
> Priority: Blocker
> Labels: havoc, respin-c
> Fix For: 9.1.0.CR1
>
> Attachments: screenshot-1.png
>
>
> CDK server adapter is not started when using JBDS + CDK April 8th build even after updating vagrant-service-manager to 1.0.1.
> "Unable to configure docker and openshift. Calls to vagrant service-manager are returning empty environments."
> I can access the OS console: https://10.1.2.2:8443/console
> The console output looks OK too:
> {code}
> Bringing machine 'default' up with 'virtualbox' provider...
> ==> default: Importing base box 'cdkv2'...
> [KProgress: 10%
> [KProgress: 20%
> [KProgress: 90%
> [K==> default: Matching MAC address for NAT networking...
> ==> default: Setting the name of the VM: rhel-ose_default_1460496916213_82608
> ==> default: Clearing any previously set network interfaces...
> ==> default: Preparing network interfaces based on configuration...
> default: Adapter 1: nat
> default: Adapter 2: hostonly
> ==> default: Forwarding ports...
> default: 22 => 2222 (adapter 1)
> ==> default: Running 'pre-boot' VM customizations...
> ==> default: Booting VM...
> ==> default: Waiting for machine to boot. This may take a few minutes...
> default: SSH address: 127.0.0.1:2222
> default: SSH username: vagrant
> default: SSH auth method: private key
> default: Warning: Connection timeout. Retrying...
> default: Warning: Remote connection disconnect. Retrying...
> default:
> default: Vagrant insecure key detected. Vagrant will automatically replace
> default: this with a newly generated keypair for better security.
> default:
> default: Inserting generated public key within guest...
> default: Removing insecure key from the guest if it's present...
> default: Key inserted! Disconnecting and reconnecting using new SSH key...
> ==> default: Machine booted and ready!
> ==> default: Checking for guest additions in VM...
> default: No guest additions were detected on the base box for this VM! Guest
> default: additions are required for forwarded ports, shared folders, host only
> default: networking, and more. If SSH fails on this machine, please install
> default: the guest additions and repackage the box to continue.
> default:
> default: This is not an error message; everything may continue to work properly,
> default: in which case you may ignore this message.
> ==> default: Configuring and enabling network interfaces...
> ==> default: Registering box with vagrant-registration...
> ==> default: Copying TLS certificates to C:/DeveloperPlatform/cdk/components/rhel/rhel-ose/.vagrant/machines/default/virtualbox/docker
> ==> default: Rsyncing folder: /cygdrive/c/DeveloperPlatform/cdk/components/rhel/rhel-ose/ => /vagrant
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default: Running provisioner: shell...
> default: Running: inline script
> ==> default:
> ==> default: Successfully started and provisioned VM with 2 cores and 3072 MB of memory.
> ==> default: To modify the number of cores and/or available memory set the environment variables
> ==> default: VM_CPU respectively VM_MEMORY.
> ==> default:
> ==> default: You can now access the OpenShift console on: https://10.1.2.2:8443/console
> ==> default:
> ==> default: To use OpenShift CLI, run:
> ==> default: $ vagrant ssh
> ==> default: $ oc login 10.1.2.2:8443
> ==> default:
> ==> default: Configured users are (<username>/<password>):
> ==> default: openshift-dev/devel
> ==> default: admin/admin
> ==> default:
> ==> default: If you have the oc client library on your host, you can also login from your host.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-22157) On deployoment, utility JAR projects are being exploded on WEB-INF/LIB
by Tiago Matias (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22157?page=com.atlassian.jira.plugi... ]
Tiago Matias edited comment on JBIDE-22157 at 4/13/16 7:41 AM:
---------------------------------------------------------------
I've attached a sample project which, when deployed via eclipse+Jboss tools causes the framework JAR to be exploded and the referenced tag to cause an exception when rendering the JSP.
I did my best to make a POM that compiles on the console and also deploys via eclipse.
was (Author: tiago.matias):
Sample Project
> On deployoment, utility JAR projects are being exploded on WEB-INF/LIB
> ----------------------------------------------------------------------
>
> Key: JBIDE-22157
> URL: https://issues.jboss.org/browse/JBIDE-22157
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Eclipse: Mars, latest version.
> Webserver: Wilfly 10.0.0
> Maven: 3.3.3
> JBoss Tools: Latest version.
> Reporter: Tiago Matias
> Assignee: Rob Stryker
> Fix For: 4.4.0.Alpha1
>
> Attachments: JBIDE22157.zip
>
>
> Consider two eclipse maven projects: A Web project (WAR) and a Utility project JAR with a JSP TLD file inside.
> After building the project and deploying to Wildfly the utiltiy JAR will be exploded under WEB-INF/LIB of the WAR project.
> An exploded jar is incompatible with TLD files since the JSP engine search for the TLD file and then try to open/unzip the JAR. Since the JAR is just a folder, it causes an "Access Denied" exception, as shown below:
> org.apache.jasper.JasperException: java.io.FileNotFoundException: C:\Program Files\Java\wildfly-10.0.0.Final\standalone\deployments\portal.web.war\WEB-INF\lib\portal.framework-0.0.1-SNAPSHOT.jar (Acesso negado)
> org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:151)
> org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:412)
> org.apache.jasper.compiler.Parser.parseDirective(Parser.java:475)
> org.apache.jasper.compiler.Parser.parseElements(Parser.java:1456)
> org.apache.jasper.compiler.Parser.parse(Parser.java:143)
> A possible alternative would be to turnoff the option "Resolve dependencies from workspace projects" in Eclipse. In this scenario the JAR won't get exploded on WAR's WEB-INF/lib and everything works. However, any change to the JAR project won't get picked up and deployed to the target unless it's POM version is incremented which is incompatible with a development scenario where the projects are constantly updated and built.
> I request that the eclipse wildfly connector provides an option to control weather the dependency JAR's are exploded or not into the final deployment.
> Please note, this only applies to dependencies that are workspace projects. All the other dependencies (spring, hibernate, etc...) are simply copied as a JAR archive, as expected.
> Thank you.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBIDE-22157) On deployoment, utility JAR projects are being exploded on WEB-INF/LIB
by Tiago Matias (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22157?page=com.atlassian.jira.plugi... ]
Tiago Matias updated JBIDE-22157:
---------------------------------
Attachment: JBIDE22157.zip
Sample Project
> On deployoment, utility JAR projects are being exploded on WEB-INF/LIB
> ----------------------------------------------------------------------
>
> Key: JBIDE-22157
> URL: https://issues.jboss.org/browse/JBIDE-22157
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Eclipse: Mars, latest version.
> Webserver: Wilfly 10.0.0
> Maven: 3.3.3
> JBoss Tools: Latest version.
> Reporter: Tiago Matias
> Assignee: Rob Stryker
> Fix For: 4.4.0.Alpha1
>
> Attachments: JBIDE22157.zip
>
>
> Consider two eclipse maven projects: A Web project (WAR) and a Utility project JAR with a JSP TLD file inside.
> After building the project and deploying to Wildfly the utiltiy JAR will be exploded under WEB-INF/LIB of the WAR project.
> An exploded jar is incompatible with TLD files since the JSP engine search for the TLD file and then try to open/unzip the JAR. Since the JAR is just a folder, it causes an "Access Denied" exception, as shown below:
> org.apache.jasper.JasperException: java.io.FileNotFoundException: C:\Program Files\Java\wildfly-10.0.0.Final\standalone\deployments\portal.web.war\WEB-INF\lib\portal.framework-0.0.1-SNAPSHOT.jar (Acesso negado)
> org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:151)
> org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:412)
> org.apache.jasper.compiler.Parser.parseDirective(Parser.java:475)
> org.apache.jasper.compiler.Parser.parseElements(Parser.java:1456)
> org.apache.jasper.compiler.Parser.parse(Parser.java:143)
> A possible alternative would be to turnoff the option "Resolve dependencies from workspace projects" in Eclipse. In this scenario the JAR won't get exploded on WAR's WEB-INF/lib and everything works. However, any change to the JAR project won't get picked up and deployed to the target unless it's POM version is incremented which is incompatible with a development scenario where the projects are constantly updated and built.
> I request that the eclipse wildfly connector provides an option to control weather the dependency JAR's are exploded or not into the final deployment.
> Please note, this only applies to dependencies that are workspace projects. All the other dependencies (spring, hibernate, etc...) are simply copied as a JAR archive, as expected.
> Thank you.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3653) User's home folder with spaces cannot be used by vagrant during install
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/JBDS-3653?page=com.atlassian.jira.plugin.... ]
Pavol Pitonak commented on JBDS-3653:
-------------------------------------
Is this going to be fixed for 9.1.0.GA?
> User's home folder with spaces cannot be used by vagrant during install
> -----------------------------------------------------------------------
>
> Key: JBDS-3653
> URL: https://issues.jboss.org/browse/JBDS-3653
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 9.1.0.Beta2
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Blocker
> Labels: havoc
> Fix For: 9.1.0.GA
>
> Attachments: install(1).log
>
>
> Vagrant complains about
> {quote}Wed, 02 Mar 2016 18:04:21 GMT-ERROR: cdk - Error: Command failed: C:\WINDOWS\system32\cmd.exe /s /c "vagrant plugin install c:\DeveloperPlatform\cdk\plugins\vagrant-registration-1.0.0.gem"
> The directory where plugins are installed (the Vagrant home directory)
> has a space in it. On Windows, there is a bug in Ruby when compiling
> plugins into directories with spaces. Please move your Vagrant home
> directory to a path without spaces and try again
> {quote}
> When user home directory have spaces in it, because .vagrant.d file path in turn has spaces as well. For instance:
> {code}C:\Users\User Name\.vagrant.d{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3797) Installer: temporary files are not removed when window is closed
by Pavol Pitonak (JIRA)
Pavol Pitonak created JBDS-3797:
-----------------------------------
Summary: Installer: temporary files are not removed when window is closed
Key: JBDS-3797
URL: https://issues.jboss.org/browse/JBDS-3797
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: installer
Reporter: Pavol Pitonak
# download installer exe
# run DeveloperPlatformInstaller*.exe
# when installer's window opens, close the window
# look into _C:\Users\yourusername\AppData\Local\Temp_
result:
Temp folder contains several files and directories with name starting *7zS*, with total size of about *1.7GB*, when you open start the installer multiple times, it appears multiple times in Temp
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JBDS-3780) Lots of errors of type HTTP Server 'Gateway Timeout'
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBDS-3780?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky commented on JBDS-3780:
-----------------------------------------
I saw this error this night and it was in a test (on a jenkins) which uses p2 director installation. Let's have one or two days to observer whether the issue is gone.
> Lots of errors of type HTTP Server 'Gateway Timeout'
> ----------------------------------------------------
>
> Key: JBDS-3780
> URL: https://issues.jboss.org/browse/JBDS-3780
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: updatesite
> Affects Versions: 9.1.0.CR1
> Reporter: Andrej Podhradsky
> Assignee: Andrej Podhradsky
> Priority: Blocker
> Labels: respin-c
> Fix For: 9.1.0.CR1
>
>
> Recently I'm often getting lots of errors such as
> {code}
> !ENTRY org.eclipse.equinox.p2.transport.ecf 4 1002 2016-04-06 21:42:20.140
> !MESSAGE HTTP Server 'Gateway Timeout': https://devstudio.redhat.com/9.0/development/updates/compositeArtifacts.xml
> !STACK 1
> org.eclipse.ecf.filetransfer.BrowseFileTransferException: HttpComponents connection error response code 504.
> at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:289)
> at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> !SUBENTRY 1 org.eclipse.ecf.identity 4 0 2016-04-06 21:42:20.142
> !MESSAGE HttpComponents connection error response code 504.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years