[JBoss JIRA] (JBIDE-22667) Automation of manual test case in batch integration tests, Reference check
by Ondrej Dockal (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22667?page=com.atlassian.jira.plugi... ]
Ondrej Dockal closed JBIDE-22667.
---------------------------------
We usually do not create jiras for new tests in integrations tests, thus, I am closing this one.
> Automation of manual test case in batch integration tests, Reference check
> --------------------------------------------------------------------------
>
> Key: JBIDE-22667
> URL: https://issues.jboss.org/browse/JBIDE-22667
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: qa
> Affects Versions: 4.4.x
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Fix For: 4.4.1.Final
>
>
> Based on not automated polarion test case: JBDS-5994 - Search for artifact references
> which is covering this features: Check that it is possible to find references for artifacts in job.xm file. See JBIDE-19507 for more details.
> Should include this test cases:
> Check references for artifacts (also use custom name)
> Check references for properties (also use custom name)
> Check references for exceptions
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23040) NPE in ELReference when validating non-synchronized resources
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23040?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-23040.
---------------------------------
Verified by [~lvalach]. (create jsf project, edit in external editor, go through build and search)
> NPE in ELReference when validating non-synchronized resources
> -------------------------------------------------------------
>
> Key: JBIDE-23040
> URL: https://issues.jboss.org/browse/JBIDE-23040
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.4.1.AM3
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Fix For: 4.4.1.Final
>
>
> Open in Eclipse workspace with a jsf project. Open one of page files in an external editor and modify it. Do not open the file in an editor inside Eclipse. Rebuild project.
> {code}
> org.jboss.tools.common.validation.JBTValidationException
> at org.jboss.tools.common.validation.ValidatorManager.validate(ValidatorManager.java:147)
> at org.jboss.tools.common.validation.ValidatorManager.validateInJob(ValidatorManager.java:81)
> at org.eclipse.wst.validation.internal.core.ValidatorLauncher.start(ValidatorLauncher.java:77)
> at org.eclipse.wst.validation.Validator$V1.validate(Validator.java:768)
> at org.eclipse.wst.validation.Validator.validate(Validator.java:405)
> at org.eclipse.wst.validation.internal.ValManager.validate(ValManager.java:704)
> at org.eclipse.wst.validation.internal.ValManager$1.visit(ValManager.java:665)
> at org.eclipse.wst.validation.internal.ValManager.accept(ValManager.java:810)
> at org.eclipse.wst.validation.internal.ValManager.validate(ValManager.java:669)
> at org.eclipse.wst.validation.internal.ValidationRunner.execute(ValidationRunner.java:134)
> at org.eclipse.wst.validation.internal.ValidationRunner.validate(ValidationRunner.java:68)
> at org.eclipse.wst.validation.ui.internal.ManualValidationRunner.runInWorkspace(ManualValidationRunner.java:83)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.NullPointerException
> at org.jboss.tools.common.el.core.ELReference.getText(ELReference.java:175)
> at org.jboss.tools.common.el.core.ELReference.getSourceText(ELReference.java:134)
> at org.jboss.tools.common.el.core.ELReference.getEl(ELReference.java:164)
> at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validateEL(ELValidator.java:336)
> at org.jboss.tools.jst.web.kb.internal.validation.ELValidator.validate(ELValidator.java:209)
> at org.jboss.tools.common.validation.ValidatorManager.validate(ValidatorManager.java:140)
> ... 13 more
> {code}
> If the file is open in editor in Eclipse, its content is stored in a buffer, and method FileUtil.getContentFromEditorOrFile(IFile) takes it from the buffer. When the file was not open in editor in Eclipse, the content is not buffered, and the method accesses the file but fails if it is not synchronized. However, clients of the method (e.g. search) may need the content even if the file is not synchronized in order to check its relevance and report synchronization problem only if the case is relevant. As it is, an error is logged now any time when user's resources are not synchronized. So, I suggest not only checking for null in ELReference but also returning in FileUtil.getContentFromEditorOrFile(IFile) content from the file on disk (if it exists) for not synchronized files.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22916) Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22916?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-22916:
-------------------------------
Attachment: 2016-09-06 at 14-19-31.mp4
> Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata
> ----------------------------------------------------------------------------------------------
>
> Key: JBIDE-22916
> URL: https://issues.jboss.org/browse/JBIDE-22916
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.4.1.Final
>
> Attachments: 2016-09-06 at 14-19-31.mp4
>
>
> When I am trying to deploy a docker image from context menu of a project in OpenShift explorer view and I paste image name (e.g. docker.io/openshift/hello-openshift), image metadata are not fetched/processed and thus there are no environment variables in the wizard and routing (routing wizard page is empty and cannot finish dialog - requires manual entry). This force user to enter the details manually, otherwise he would get deployed not working pod. This is happening only in case when user provide an image without any tag and thus there is/supposed to be assumed tag "latest".
> You can observe that it works when using tag v1.2.1. Difference between images with tag v1.2.1 and latest is that v1.2.1 contains exposed ports also in container config, not just in general config of the image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22916) Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22916?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-22916:
------------------------------------
I tested with the same build (on Windows) and it worked for me: see [^2016-09-06 at 14-19-31.mp4]
> Deploy Docker Wizard: Deploying a docker image from OpenShift explorer does not fetch metadata
> ----------------------------------------------------------------------------------------------
>
> Key: JBIDE-22916
> URL: https://issues.jboss.org/browse/JBIDE-22916
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.1.AM3
> Reporter: Marián Labuda
> Assignee: Jeff MAURY
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.4.1.Final
>
> Attachments: 2016-09-06 at 14-19-31.mp4
>
>
> When I am trying to deploy a docker image from context menu of a project in OpenShift explorer view and I paste image name (e.g. docker.io/openshift/hello-openshift), image metadata are not fetched/processed and thus there are no environment variables in the wizard and routing (routing wizard page is empty and cannot finish dialog - requires manual entry). This force user to enter the details manually, otherwise he would get deployed not working pod. This is happening only in case when user provide an image without any tag and thus there is/supposed to be assumed tag "latest".
> You can observe that it works when using tag v1.2.1. Difference between images with tag v1.2.1 and latest is that v1.2.1 contains exposed ports also in container config, not just in general config of the image.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBTIS-851) Cannot checkout the repository on Windows slaves
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-851?page=com.atlassian.jira.plugin.... ]
Andrej Podhradsky closed JBTIS-851.
-----------------------------------
Fix Version/s: 4.3.2.CR1
Resolution: Done
Pushed to master
> Cannot checkout the repository on Windows slaves
> ------------------------------------------------
>
> Key: JBTIS-851
> URL: https://issues.jboss.org/browse/JBTIS-851
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: QE
> Affects Versions: 4.3.1.Final
> Reporter: Andrej Podhradsky
> Assignee: Tomáš Sedmík
> Fix For: 4.3.2.CR1
>
>
> It seems that some paths are too long.
> {code}
> C:\hudson\workspace\jbdsis9x.test.smoke\jdk\oraclejdk1.8\label\w7>git clone https://github.com/jbosstools/jbosstools-integration-s
> tack-tests.git
> Cloning into 'jbosstools-integration-stack-tests'...
> remote: Counting objects: 35930, done.
> remote: Compressing objects: 100% (38/38), done.
> remote: Total 35930 (delta 6), reused 0 (delta 0), pack-reused 35886
> Receiving objects: 100% (35930/35930), 7.62 MiB | 2.07 MiB/s, done.
> Resolving deltas: 100% (16132/16132), done.
> error: unable to create file tests/org.jboss.tools.fuse.ui.bot.test/resources/projects/wildfly-transformation/src/main/java/org/jb
> oss/tools/fuse/transformation/editor/function/BooleanFunctions.java (No such file or directory)
> error: unable to create file tests/org.jboss.tools.fuse.ui.bot.test/resources/projects/wildfly-transformation/src/main/java/org/jb
> oss/tools/fuse/transformation/editor/function/Function.java (No such file or directory)
> error: unable to create file tests/org.jboss.tools.fuse.ui.bot.test/resources/projects/wildfly-transformation/src/main/java/org/jb
> oss/tools/fuse/transformation/editor/function/NumericFunctions.java (No such file or directory)
> error: unable to create file tests/org.jboss.tools.fuse.ui.bot.test/resources/projects/wildfly-transformation/src/main/java/org/jb
> oss/tools/fuse/transformation/editor/function/StringFunctions.java (No such file or directory)
> Checking out files: 100% (1708/1708), done.
> fatal: unable to checkout working tree
> warning: Clone succeeded, but checkout failed.
> You can inspect what was checked out with 'git status'
> and retry the checkout with 'git checkout -f HEAD'
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22617) Integrate DockViz in to Docker Tooling
by Josef Kopriva (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22617?page=com.atlassian.jira.plugi... ]
Josef Kopriva closed JBIDE-22617.
---------------------------------
Image Hierarchy view is included in Docker Tooling
Verified in:
Version: 10.1.0.GA
Build id: GA-v20160902-1725-B43
Build date: 20160902-1725
> Integrate DockViz in to Docker Tooling
> --------------------------------------
>
> Key: JBIDE-22617
> URL: https://issues.jboss.org/browse/JBIDE-22617
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: docker, upstream
> Affects Versions: 4.4.0.Alpha2
> Reporter: Mustafa Musaji
> Assignee: Xavier Coulon
> Priority: Optional
> Fix For: 4.4.1.Final
>
>
> DockVIz is a tool used to provide a way to view docker information on a system in a number of ways, one of which is a tree like structure to be able to visualise docker layers.
> This would be a nice thing to include in our docker toolset.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-23130) JMX connection to remote server does not work (fs operations, runtime)
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23130?page=com.atlassian.jira.plugi... ]
Martin Malina reassigned JBIDE-23130:
-------------------------------------
Assignee: Rob Stryker
> JMX connection to remote server does not work (fs operations, runtime)
> ----------------------------------------------------------------------
>
> Key: JBIDE-23130
> URL: https://issues.jboss.org/browse/JBIDE-23130
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx
> Affects Versions: 4.4.1.Final
> Reporter: Martin Malina
> Assignee: Rob Stryker
>
> This is basically a follow up of JBIDE-22741.
> It turns out even if I have a local runtime, jmx connection to a remote fs server still doesn't work for me.
> 1. Set up a remote WildFly 8.2 server over ssh (use fs operations, local runtime)
> 2. Make sure the user is set up correctly both on the server and in server editor in Eclipse
> 3. Start the remote server
> 4. Try to connect to the server in JMX Navigator
> You'll get this in the error log view:
> {code}
> Error connecting to jmx for server WildFly 8.2 marvin
> org.jboss.tools.jmx.core.JMXException: There was an error connecting to WildFly 8.2 marvin via JMX. Please ensure your server is up and exposes its management ports via the -Djboss.bind.address.management=yourwebsite.com launch arguments
> at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:98)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:211)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:162)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connectToStartedServer(JBossServerConnection.java:341)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connect(JBossServerConnection.java:76)
> at org.jboss.tools.jmx.core.ConnectJob.run(ConnectJob.java:29)
> at org.jboss.tools.jmx.ui.internal.actions.DoubleClickAction$1.run(DoubleClickAction.java:71)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:319)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:335)
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:232)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:151)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:102)
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:84)
> ... 7 more
> {code}
> {code}
> There was an error connecting to WildFly 8.2 marvin via JMX. Please ensure your server is up and exposes its management ports via the -Djboss.bind.address.management=yourwebsite.com launch arguments
> java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:319)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:335)
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:232)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:151)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:102)
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
> at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:84)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:211)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:162)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connectToStartedServer(JBossServerConnection.java:341)
> at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connect(JBossServerConnection.java:76)
> at org.jboss.tools.jmx.core.ConnectJob.run(ConnectJob.java:29)
> at org.jboss.tools.jmx.ui.internal.actions.DoubleClickAction$1.run(DoubleClickAction.java:71)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
> So it tells me that I need to expose the managerment port. But we never did that for fs operations, no? And indeed it's not exposed:
> {code}
> 2810 pts/1 Sl 0:06 \_ java -Dprogram.name=JBossTools: WildFly 8.2 marvin -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/home/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/log/boot.log -Dlogging.configuration=file:/home/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone/configuration/logging.properties -Djboss.home.dir=/home/rasp/jbossqa/runtimes/wildfly-8.2.0.Final -Dorg.jboss.logmanager.nocolor=true -jar /home/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/jboss-modules.jar -mp /home/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/modules -jaxpmodule javax.xml.jaxp-provider -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b 0.0.0.0 --server-config=standalone.xml -Djboss.server.base.dir=/home/rasp/jbossqa/runtimes/wildfly-8.2.0.Final/standalone
> {code}
> But even if I do expose the management port, it still won't work - then I hit JBIDE-20108 .
> Anyway, I think we didn't need to expose the management port in the past. Or did we?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22741) JMX connection to remote server does not work (fs operations, no runtime)
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22741?page=com.atlassian.jira.plugi... ]
Martin Malina closed JBIDE-22741.
---------------------------------
I can confirm that the error is now better and hopefully a desperate user will be able to make sense of it. But unfortunately it won't work even if you do have a local runtime. So I created another JIRA for that: JBIDE-23130
And there is still an open JIRA for remote+management: JBIDE-20108
So basically I haven't managed to get a remote jmx connection to work in any form whatsoever in a long time now.
But at least this JIRA can be closed now.
> JMX connection to remote server does not work (fs operations, no runtime)
> -------------------------------------------------------------------------
>
> Key: JBIDE-22741
> URL: https://issues.jboss.org/browse/JBIDE-22741
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jmx
> Affects Versions: 4.4.1.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.1.Final
>
>
> I wanted to replicate JBIDE-17181 today. And I cannot replicate that problem.
> But I noticed that jmx connection to a remote wf 8.2 with fs operations doesn't seem to work. I thought there was a long standing issue open for this already, but it turns out this other JIRA is for management mode: JBIDE-20108
> So it seems that neither works right now.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBIDE-22725) Provided wrong credentials, CDK adapter creates openshift connection with a strange IP
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22725?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-22725:
------------------------------------
I add also something weird: if after the first vagrant up I run vagrant destro, I have the following output:
C:\Apps\cdk2.1\components\rhel\rhel-ose>vagrant halt
The VirtualBox VM was created with a user that doesn't match the
current user running Vagrant. VirtualBox requires that the same user
be used to manage the VM that was created. Please re-run Vagrant with
that user. This is not a Vagrant issue.
The UID used to create the VM was: 0
Your UID is: 1001
The only way to get rid is to delete the VM using VirtualBox
> Provided wrong credentials, CDK adapter creates openshift connection with a strange IP
> --------------------------------------------------------------------------------------
>
> Key: JBIDE-22725
> URL: https://issues.jboss.org/browse/JBIDE-22725
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk, upstream
> Affects Versions: 4.4.1.AM1
> Reporter: Martin Malina
> Fix For: 4.4.x
>
>
> When you start CDK with wrong credentials, service manager will return this strange IP:
> {code}
> # docker env:
> # Copying TLS certificates to /Users/rasp/jbossqa/cdk2.1/cdk2.1.rc5/components/rhel/misc/shared_folder/rhel-ose/.vagrant/machines/default/virtualbox/docker
> # Set the following environment variables to enable access to the docker daemon running inside of the vagrant virtual machine:
> export DOCKER_HOST=tcp://10.0.2.15:2376
> export DOCKER_CERT_PATH=/Users/rasp/jbossqa/cdk2.1/cdk2.1.rc5/components/rhel/misc/shared_folder/rhel-ose/.vagrant/machines/default/virtualbox/docker
> export DOCKER_TLS_VERIFY=1
> export DOCKER_API_VERSION=1.21
> # run following command to configure your shell:
> # eval "$(vagrant service-manager env)"
> {code}
> This has been reported upstream here:
> https://github.com/projectatomic/vagrant-service-manager/issues/299
> Let's use this JIRA to track the upstream issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months