[JBoss JIRA] Created: (JBIDE-9358) PollThread: separate alerting behaviour from alerting event log
by Andre Dietisheim (JIRA)
PollThread: separate alerting behaviour from alerting event log
---------------------------------------------------------------
Key: JBIDE-9358
URL: https://issues.jboss.org/browse/JBIDE-9358
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: JBossAS
Affects Versions: 3.3.0.M3
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 3.3.0.M3
The current impl of PollThread does inform the event log in a method that does alert the server behavior of the outcome of the polling ( if(finalAlert) ... ) in #alertBehavior:
{code}
protected void alertBehavior(boolean currentState, boolean finalAlert) {
if (currentState != expectedState) {
// it didnt work... cancel all processes! force stop
behavior.stop(true);
if (finalAlert)
alertEventLogFailure();
} else {
if (currentState == IServerStatePoller.SERVER_UP)
behavior.setServerStarted();
else
behavior.stop(true);
if (finalAlert)
alertEventLogSuccess(currentState);
}
}
{code}
This shall be separated into into its own method.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBIDE-9200) cleanup launch config classes
by Andre Dietisheim (JIRA)
cleanup launch config classes
------------------------------
Key: JBIDE-9200
URL: https://issues.jboss.org/browse/JBIDE-9200
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: JBossAS
Affects Versions: 3.3.0.M1
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 3.3.0.M3
We decided to improve maintability of our code base and do cleanups. In terms of launch config classes there are the following improvements in the current code:
* static methods in stateful classes shall be moved to util classes
* static methods in stateful classes that shall not be static
* duplicate code
* etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBIDE-9367) Launch remote server: build command from scratch, dont take the local launch and convert it
by Andre Dietisheim (JIRA)
Launch remote server: build command from scratch, dont take the local launch and convert it
-------------------------------------------------------------------------------------------
Key: JBIDE-9367
URL: https://issues.jboss.org/browse/JBIDE-9367
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: JBossAS
Affects Versions: 3.3.0.M3
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 3.3.0.M3
The current implementation that launches remote servers takes the current configuration (launch config tab) for local launches and changes it so that it works for remote servers. We have to build that remote launch from scratch instead since our goal would be to offer the local OR the remote launch (depending on the server config) at some point.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (JBIDE-9359) Refactor PollThread so that it does not call server behavior but informs a listener
by Andre Dietisheim (JIRA)
Refactor PollThread so that it does not call server behavior but informs a listener
-----------------------------------------------------------------------------------
Key: JBIDE-9359
URL: https://issues.jboss.org/browse/JBIDE-9359
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: JBossAS
Affects Versions: 3.3.0.M3
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 3.3.0.M3
The current impl of PollThread is instantiated by the server behavior and then calls the server behavior again (calls stop(force) on it). This is pretty much not what a dumb user programmer would expect. He would expect the poll thread to poll and return it's result to its caller. Furthermore this is not ideal in terms of separations of concerns, since the poll thread implements a strategy to apply if the polling did not reach the expected state (server is up / server is down). A proper design would be to have a poller that polls for the state only and then passes back to the server behavior that then decides what to do in these cases.
We can achieve this by replacing the call to the behavior by a listener.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years