July 2017 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-24702) Refactor usage of AbstractWait.sleep in CDK3ServerEditorTest with async saving of editor

by Ondrej Dockal (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24702?page=com.atlassian.jira.plugi... ] Ondrej Dockal updated JBIDE-24702: ---------------------------------- Labels: cdk (was: ) > Refactor usage of AbstractWait.sleep in CDK3ServerEditorTest with async saving of editor > ---------------------------------------------------------------------------------------- > > Key: JBIDE-24702 > URL: https://issues.jboss.org/browse/JBIDE-24702 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: integration-tests > Affects Versions: 4.5.0.AM2 > Reporter: Ondrej Dockal > Assignee: Ondrej Dockal > Labels: cdk > Fix For: 4.5.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24702) Refactor usage of AbstractWait.sleep in CDK3ServerEditorTest with async saving of editor

by Ondrej Dockal (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24702?page=com.atlassian.jira.plugi... ] Ondrej Dockal updated JBIDE-24702: ---------------------------------- Fix Version/s: 4.5.0.Final (was: 4.5.x) > Refactor usage of AbstractWait.sleep in CDK3ServerEditorTest with async saving of editor > ---------------------------------------------------------------------------------------- > > Key: JBIDE-24702 > URL: https://issues.jboss.org/browse/JBIDE-24702 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: integration-tests > Affects Versions: 4.5.0.AM2 > Reporter: Ondrej Dockal > Assignee: Ondrej Dockal > Labels: cdk > Fix For: 4.5.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24680) Update itests for latest thym

by Radim Hopp (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24680?page=com.atlassian.jira.plugi... ] Radim Hopp reassigned JBIDE-24680: ---------------------------------- Assignee: Radim Hopp (was: Rastislav Wagner) > Update itests for latest thym > ----------------------------- > > Key: JBIDE-24680 > URL: https://issues.jboss.org/browse/JBIDE-24680 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: integration-tests > Reporter: Rastislav Wagner > Assignee: Radim Hopp > Fix For: 4.5.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-16161) Tycho tests against Luna have extra dependency on org.eclipse.e4.rcp (need to be cleaned)

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-16161?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-16161: --------------------------------------- [~nickboldt], I just checked and integration tests don't have the dependency in tests/pom.xml anymore. Using git bisect I found out that this commit in August 2016 removed it: https://github.com/jbosstools/jbosstools-integration-tests/commit/26675c4... Although it's not exactly clear why - perhaps [~rawagner] somehow figured out that it was no longer needed. > Tycho tests against Luna have extra dependency on org.eclipse.e4.rcp (need to be cleaned) > ----------------------------------------------------------------------------------------- > > Key: JBIDE-16161 > URL: https://issues.jboss.org/browse/JBIDE-16161 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, upstream > Affects Versions: 4.2.0.Alpha2 > Reporter: Snjezana Peco > Assignee: Mickael Istria > Fix For: 4.3.x, 4.5.x > > > Since Tycho requires the PlatformAdmin service, we have to add the org.eclipse.osgi.compatibility.state fragment to tycho-surefire-plugin. > The easiest way is to add the org.eclipse.e4.rcp feature to the main build. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24704) Add Win7 with pre-installed virtualbox as template into jenkins for cdk3 testing

by Ondrej Dockal (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24704?page=com.atlassian.jira.plugi... ] Ondrej Dockal resolved JBIDE-24704. ----------------------------------- Resolution: Done > Add Win7 with pre-installed virtualbox as template into jenkins for cdk3 testing > -------------------------------------------------------------------------------- > > Key: JBIDE-24704 > URL: https://issues.jboss.org/browse/JBIDE-24704 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: integration-tests, qa > Affects Versions: 4.5.0.AM2 > Reporter: Ondrej Dockal > Assignee: Ondrej Dockal > Labels: cdk, central-ci, jenkins > Fix For: 4.5.0.Final > > > It was found out, that cdk3 can be started in CLI on win7-x64 slave with pre-installed virtualbox in central ci env. and so, I am planning to: > * prepare machine as a new snapshot in openstack images section, tune possible bugs > * create new template/label in jenkins for this machine > * create a job in jenkins that would test cdk3 start up on this slave -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24760) Add windows as supported platform for cdk-scripts

by Ondrej Dockal (JIRA)

Ondrej Dockal created JBIDE-24760: ------------------------------------- Summary: Add windows as supported platform for cdk-scripts Key: JBIDE-24760 URL: https://issues.jboss.org/browse/JBIDE-24760 Project: Tools (JBoss Tools) Issue Type: Feature Request Components: integration-tests, qa Affects Versions: 4.5.0.AM2 Reporter: Ondrej Dockal Assignee: Ondrej Dockal See https://github.com/odockal/cdk-scripts/issues/4. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3588) Central shows 'Early access installed' after installing SOA 5.x Development

by Josef Kopriva (JIRA)

[ https://issues.jboss.org/browse/JBDS-3588?page=com.atlassian.jira.plugin.... ] Josef Kopriva closed JBDS-3588. ------------------------------- Closing - issue is no longer reproducible. Verified in: Red Hat JBoss Developer Studio Version: 11.0.0.GA Build id: GA-v20170725-0331-B596 Build date: 20170725-0331 > Central shows 'Early access installed' after installing SOA 5.x Development > --------------------------------------------------------------------------- > > Key: JBDS-3588 > URL: https://issues.jboss.org/browse/JBDS-3588 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: central > Affects Versions: 9.1.0.Beta2 > Reporter: Jan Richter > Assignee: Paul Leacu > Priority: Minor > Fix For: 10.4.0.GA, 11.0.0.GA > > > JBoss SOA 5.x Development feature is not shown as early access in the software/update list. Still, when installed, the welcome page will say that early access is installed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBDS-4281) Early Access Banner disappears after restart

by Josef Kopriva (JIRA)

[ https://issues.jboss.org/browse/JBDS-4281?page=com.atlassian.jira.plugin.... ] Josef Kopriva closed JBDS-4281. ------------------------------- Closing - cannot reproduce. Verified in: Red Hat JBoss Developer Studio Version: 11.0.0.GA Build id: GA-v20170725-0331-B596 Build date: 20170725-0331 > Early Access Banner disappears after restart > -------------------------------------------- > > Key: JBDS-4281 > URL: https://issues.jboss.org/browse/JBDS-4281 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: central > Affects Versions: 10.2.0.GA > Reporter: Andrej Podhradsky > Assignee: Paul Leacu > Fix For: 11.0.0.GA > > Attachments: ea_banner.png > > > After restarting Devstudio 10.2.0.GA the EA banner dissappears. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-24184) Server adapter: DEV_MODE, DEBUG_MODE, DEBUG_PORT keys (and default values) are hard-coded, not read from docker image

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-24184?page=com.atlassian.jira.plugi... ] Jeff MAURY updated JBIDE-24184: ------------------------------- Sprint: (was: devex #135 July 2017) > Server adapter: DEV_MODE, DEBUG_MODE, DEBUG_PORT keys (and default values) are hard-coded, not read from docker image > --------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-24184 > URL: https://issues.jboss.org/browse/JBIDE-24184 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.4.AM2 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Labels: openshift_v3, server_adapter > Fix For: 4.5.0.Final > > > to turn on/off debugging and dev_mode for an app, one needs to set env variables. The keys that are used to set the values are all defined in the docker image labels (inspectable by doing {code}docker inspect <docker-image-id>{code}: > * nodejs > {code} > "Labels": { > ... > "com.redhat.dev-mode": "DEV_MODE:false", > "com.redhat.dev-mode.port": "DEBUG_PORT:5858", > ... > {code} > * eap > {code} > "Labels": { > ... > "com.redhat.dev-mode": "DEBUG:true", > "com.redhat.dev-mode.port": "DEBUG_PORT:8787", > ... > {code} > Our code on the other hand is hard-coding these, not reading the keys from the docker image: > {code} > public class OpenShiftDebugUtils { > private static final String DEBUG_KEY = "DEBUG"; > private static final String DEBUG_PORT_KEY = "DEBUG_PORT"; > ... > {code} > {code} > public class OpenShiftLaunchController extends AbstractSubsystemController > implements ISubsystemController, ILaunchServerController { > ... > private static final String DEV_MODE = "DEV_MODE"; //$NON-NLS-1$ > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19182) Incremental Publish after Full Publish WRT dodeploy markers

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19182?page=com.atlassian.jira.plugi... ] Martin Malina closed JBIDE-19182. --------------------------------- Closing. > Incremental Publish after Full Publish WRT dodeploy markers > ----------------------------------------------------------- > > Key: JBIDE-19182 > URL: https://issues.jboss.org/browse/JBIDE-19182 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.2.0.Final > Reporter: Rob Stryker > Assignee: Rob Stryker > Fix For: 4.5.0.AM1 > > > THis issue is opened in regards to comments by [~dlmiles] on https://issues.jboss.org/browse/JBIDE-18862 > I am saying you should block all 'deployment directory' file modifications when you know the AS is busy using the 'deployment directory' to "deploy" (a.k.a. starting) or "undeploy" (a.k.a. stopping) of a module (or the AS itself is starting/stopping in certain scenarios). Ideally you use a file watcher API when available so there is no busy/wait loop adding additional milliseconds of delays because the wait part is never instant. > But in an example scenario where you perform a Full Publish then 2 additional Incremental Publish ops immediately after, there is no reason to block the incrementals if you know the AS has not picked up the original Full Publish yet. You can effectively merge those two incrementals into the full publish operation behind the back of the AS. > But you are presented with a race scenario, you have already laid down the *.dodeploy at the end of the original Full Publish. So Eclipse needs to effectively notice that scenario exists, revoke and remember that instruction to the AS in an atomic way (what I mean by this is Eclipse knows for sure if it cancelled it in time, or if it was too late and the AS got to the full publish first and started deploying). > You need to do this so Eclipse can make file change modifications to the 'deployment directory' again. > Once Eclipse has completed the file change operations, if takes that remembered state and puts back the *.dodeploy file (even though this is an Incremental Publish operation). You can think of this like a "save state" and "restore state" pattern if that helps. Or you can think of this like the Eclipse target goal state for the AS (such as "AS:started" and "module.abc:started") is compared to the actual AS state (such as "AS: started" and "module.abc:stopped"), and Eclipse then brings them into alignment to do this it realizes it needs to lay down the *.dodeploy marker file (even though this is an incremental publish). > I think with the current marker file arrangements there maybe a tiny window of time where Eclipse IDE will get things wrong in respect of the AS ? But maybe ensuring both Eclipse IDE and the AS check the return value of the file delete for *.dodeploy whomever was successful in deleting the file wins, whichever party got the error "No Such File" loses and performs a rollback/cleanup of the situation to ensure it tries again soon. > So you can speak for the JBIDE side but can someone check the AS side ? File#delete(new File("foobar.dodeploy")) != true. The AS has to delete the command instruction file before it starts to process that command, but after it has laid down a state change file (*.isdeploying). > One of the goals of the marker files is that at no point in time is there a snapshot of the files that exist in the directory; that would leave an observer to interpret the wrong state. For example deleting one marker file before laying down the next would be bad, because there is a snapshot of time when no state marker file exists in the directory, leaving the observer to interpret that nothing is happening with that module. The alternative is to lay both the new file first then delete the old one, now there is a window of time when 2 marker files indicate state for 1 module, this is good and valid since the observer can clearly see the correct state. > So if you got here and are still with me, then you can see how things should only slow down, when they need to slow down. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues July 2017