[JBoss JIRA] (JBIDE-16720) Server Adapter: Allow easier access to openshift operations from jboss servers
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16720?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-16720:
------------------------------------------
re-targeting to 4.3.x
> Server Adapter: Allow easier access to openshift operations from jboss servers
> ------------------------------------------------------------------------------
>
> Key: JBIDE-16720
> URL: https://issues.jboss.org/browse/JBIDE-16720
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift, server
> Affects Versions: 4.1.1.Final
> Reporter: Mark Drilling
> Labels: server_adapter
> Fix For: 4.3.x
>
>
> We currently have a couple issues with connecting to an OpenShift Data Virtualization instance from the tooling. I'm aware that issues are being addressed for future release, others I'm not sure. This is intended to help guide your development to accommodate this use case.
> Our expected usage with Data Virtualization is a bit different than some others. With DV we expect to deploy via a DV cartridge to OpenShift, then connect to the OpenShift DV instance as a remote server. We typically would not deploy using git push.
> Currently, we connect to an OpenShift DV instance like this:
> 1) Deploy DV cartridge via OpenShift web console.
> 2) Port forward from command line using rhc port-forward
> 3) Set up EAP server instance in the tooling, mark as externally managed and start it. From there we can connect to the DV instance and continue with modeling and deployments in Teiid Designer perspective
> The issues we observed:
> 1) Creation of the OpenShift 'server' forces a git repo to be copied locally. We'd like to simply create the 'OpenShift server' without cloning the repo.
> 2) Can't deploy our downloadable cartridge from the wizard. I believe OpenShift is now (or will soon) allow downloadable carts to be registered, so this problem should be solved as the cart will show up in the cartridge list.
> Our current method of connecting is ok for now, but a simpler usage of the OpenShift server adapter would allow us to more easily manage the instance (e.g. port-forward without going to the command line, viewing logs, etc.)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBDS-3253) devstudio.jboss.com/updates/8.0/ says it dontains dev milestones which it should not
by Martin Malina (JIRA)
Martin Malina created JBDS-3253:
-----------------------------------
Summary: devstudio.jboss.com/updates/8.0/ says it dontains dev milestones which it should not
Key: JBDS-3253
URL: https://issues.jboss.org/browse/JBDS-3253
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Components: updatesite
Affects Versions: 8.0.0.GA
Reporter: Martin Malina
Assignee: Nick Boldt
I was just reviewing Michelle's doc on updating from JBDS 8.0.0 to 8.0.1
(JBQA-11231) and it says you need to make sure this update site is listed in Eclipse:
https://devstudio.jboss.com/updates/8.0/
And I verified that this is exactly the update site that is set up automatically when you install JBDS 8.0.0.GA.
But that says:
This site contains the latest Development Milestone updates for JBoss Developer Studio 8.x.
We need an update site with released versions, but milestones. So either just the description is wrong or it's the wrong update site that we use?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18366) Sometimes, EAP6/WildFly8/AS7 fails to start - Failed initializing module org.jboss.as.logging
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18366?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-18366:
---------------------------------------
Sure. But as I said to Rob, it's not like I can just verify it's fixed. It happens randomly, but very rarely. So I would say if this doesn't happen in a week, then we can be pretty confident that it's gone.
> Sometimes, EAP6/WildFly8/AS7 fails to start - Failed initializing module org.jboss.as.logging
> ---------------------------------------------------------------------------------------------
>
> Key: JBIDE-18366
> URL: https://issues.jboss.org/browse/JBIDE-18366
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Critical
> Labels: respin-a
> Fix For: 4.2.1.CR1, 4.3.0.Alpha1
>
>
> Sometimes, right after start of the IDE, a server fails to start. When this happens, it produces something like this in the server log:
> {code}
> INFO: JBoss MSC version 1.1.5.Final-redhat-1
> Sep 17, 2014 11:27:40 AM org.jboss.as.server.ApplicationServerService start
> INFO: JBAS015899: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) starting
> Sep 17, 2014 11:27:40 AM org.jboss.as.controller.AbstractOperationContext executeStep
> ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([])
> java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:111)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:611)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:489)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:290)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:285)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1132)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:299)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:292)
> at org.jboss.as.server.ServerService.boot(ServerService.java:346)
> at org.jboss.as.server.ServerService.boot(ServerService.java:321)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:254)
> at java.lang.Thread.run(Thread.java:695)
> Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:103)
> ... 11 more
> Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
> at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:106)
> at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:97)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:139)
> at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:125)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:695)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Sep 17, 2014 11:27:40 AM org.jboss.as.server.ServerService boot
> FATAL: JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> Unfortunately I don't have a reliable way to reproduce this. It happened to me like 3 times over the last few days.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18818) Test timeout in org.jboss.tools.jsf.verification.test
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18818?page=com.atlassian.jira.plugi... ]
Alexey Kazakov edited comment on JBIDE-18818 at 12/5/14 2:56 AM:
-----------------------------------------------------------------
I noticed that actually in all javaee test timeouts o.j.t.jsf.ui.test killed first but despite of that sometimes jsf.verification.test is started anyway and killed too.
Both jsf.ui and verification tests pass when I run them locally on my machine (mvn clean install ...) but I tend to blame *Display.getCurrent().readAndDispatch()* method which we use wildly in our tests and which may cause a deadlock and sometimes I see it when running locally too.
I have no idea how we can fix this problem w/o removing a majority of our UI tests :(
But again, if jenkins could provide a stack trace before killing the job it would be very useful to spot the problematic code in our tests.
Can we run a script in parallel with jenkins build and run jstack or any other tool which can provide a stack trace of the jvm process just before the timeout is reached?
The idea is to get a stack trace of the jvm process which is about to killed by timeout. Console output and Eclipse/Surefire logs are not very useful here.
[~nickboldt], [~mickael_istria], [~dgolovin], WDYT?
was (Author: akazakov):
I noticed that actually in all javaee test timeouts o.j.t.jsf.ui.test killed first but despite of that sometimes jsf.verification.test is started anyway and killed too.
Both jsf.ui and verification tests pass when I run them locally on my machine (mvn clean install ...) but I tend to blame Display.getCurrent().readAndDispatch() method which we use wildly in our tests and which may cause a deadlock and sometimes I see it when running locally too.
I have no idea how we can fix this problem w/o removing a majority of our UI tests :(
But again, if jenkins could provide a stack trace before killing the job it would be very useful to spot the problematic code in our tests.
Can we run a script in parallel with jenkins build and run jstack or any other tool which can provide a stack trace of the jvm process just before the timeout is reached?
The idea is to get a stack trace of the jvm process which is about to killed by timeout. Console output and Eclipse/Surefire logs are not very useful here.
[~nickboldt], [~mickael_istria], [~dgolovin], WDYT?
> Test timeout in org.jboss.tools.jsf.verification.test
> -----------------------------------------------------
>
> Key: JBIDE-18818
> URL: https://issues.jboss.org/browse/JBIDE-18818
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.2.1.CR1
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Priority: Blocker
> Fix For: 4.2.x, 4.3.x
>
>
> Tests that time out due to blocking UI or other thread lock result in builds that are recorded as ABORTED [0]. This isn't a problem in terms of publishing new content because the build runs quickly, publishes the new bits, and THEN starts running tests.
> [0] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4....
> But where it IS a problem is where we use a buildflow job to run the whole stack of JBT projects. Buildflows will also abort if they encounter an aborted job [1].
> [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-buildflow...
> Why is this a problem? Because when we do a weekend spin (or respin) not all the projects in the stack are guaranteed to rebuild to verify all the downstream component tests all still work.
> --
> If you cannot fix these tests so they run cleanly in Jenkins, please disable them or move them such that they can still be run LOCALLY using a profile, but will be skipped in Jenkins.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBIDE-18818) Test timeout in org.jboss.tools.jsf.verification.test
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18818?page=com.atlassian.jira.plugi... ]
Alexey Kazakov commented on JBIDE-18818:
----------------------------------------
I noticed that actually in all javaee test timeouts o.j.t.jsf.ui.test killed first but despite of that sometimes jsf.verification.test is started anyway and killed too.
Both jsf.ui and verification tests pass when I run them locally on my machine (mvn clean install ...) but I tend to blame Display.getCurrent().readAndDispatch() method which we use wildly in our tests and which may cause a deadlock and sometimes I see it when running locally too.
I have no idea how we can fix this problem w/o removing a majority of our UI tests :(
But again, if jenkins could provide a stack trace before killing the job it would be very useful to spot the problematic code in our tests.
Can we run a script in parallel with jenkins build and run jstack or any other tool which can provide a stack trace of the jvm process just before the timeout is reached?
The idea is to get a stack trace of the jvm process which is about to killed by timeout. Console output and Eclipse/Surefire logs are not very useful here.
[~nickboldt], [~mickael_istria], [~dgolovin], WDYT?
> Test timeout in org.jboss.tools.jsf.verification.test
> -----------------------------------------------------
>
> Key: JBIDE-18818
> URL: https://issues.jboss.org/browse/JBIDE-18818
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: jsf
> Affects Versions: 4.2.1.CR1
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Priority: Blocker
> Fix For: 4.2.1.Final
>
>
> Tests that time out due to blocking UI or other thread lock result in builds that are recorded as ABORTED [0]. This isn't a problem in terms of publishing new content because the build runs quickly, publishes the new bits, and THEN starts running tests.
> [0] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4....
> But where it IS a problem is where we use a buildflow job to run the whole stack of JBT projects. Buildflows will also abort if they encounter an aborted job [1].
> [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-buildflow...
> Why is this a problem? Because when we do a weekend spin (or respin) not all the projects in the stack are guaranteed to rebuild to verify all the downstream component tests all still work.
> --
> If you cannot fix these tests so they run cleanly in Jenkins, please disable them or move them such that they can still be run LOCALLY using a profile, but will be skipped in Jenkins.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months