[JBoss JIRA] (JBIDE-16021) Revisit whether file transfer requests can trust rse's isConnected
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16021?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-16021:
--------------------------------
Fix Version/s: 4.2.0.Alpha2
(was: 4.2.0.Alpha1)
> Revisit whether file transfer requests can trust rse's isConnected
> -------------------------------------------------------------------
>
> Key: JBIDE-16021
> URL: https://issues.jboss.org/browse/JBIDE-16021
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: server, upstream
> Affects Versions: 4.2.0.Alpha1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.2.0.Alpha2
>
>
> With the large speed increases in jbt's RSE integration, the new bottleneck is during the beginning of the publish event.
> A block of code currently exists as follows:
> {code}
> boolean isConnected = fileSubSystem != null && fileSubSystem.isConnected();
> String connectionName = RSEUtils.getRSEConnectionName(behaviour.getServer());
> if( isConnected ) {
> // The RSE tools might be mistaken here. The user may in fact have lost internet connectivity
> NamedRunnableWithProgress run = new NamedRunnableWithProgress("Accessing Remote System Root") {
> public Object run(IProgressMonitor monitor) throws CoreException,
> SystemMessageException, RuntimeException {
> getFileService().getRoots(monitor);
> return Status.OK_STATUS;
> }
> };
> IProgressMonitor childMonitor = AbstractServerToolsPublisher.getSubMon(monitor, 100);
> Exception e = RSERemotePublishHandler.wrapRemoteCallStatusTimeLimit(run, "null", "null", null, 15000, childMonitor);
> {code}
> It would seem strange for the rse's isConnected() method to be incorrect. Investigate whether it is still possible it is incorrect, and file an appropriate upstream bug, or, if no bug, simply remove the lines and improve speed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-15917) Creation of subsystem framework
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15917?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-15917:
--------------------------------
Fix Version/s: 4.2.0.Alpha2
(was: 4.2.0.Alpha1)
> Creation of subsystem framework
> -------------------------------
>
> Key: JBIDE-15917
> URL: https://issues.jboss.org/browse/JBIDE-15917
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: server
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.2.0.Alpha2
>
>
> ASTools has a requirement for mixin-style behavior. The current similar API is called the BehaviorModel, however it does not allow for mixin-style behavior. The server can be in only 1 mode at any time, and so therefore can have only 1 set of systems at any time, and there are currently only 2 sets: a local set, and an rse set.
> The contents of these sets change based on server version, so for example, AS 6 in 'rse' mode may stop with a java command to the shutdown jar launched over a remote shell, while Wildfly 8 will shutdown with a call to management.
> A model needs to be created to resolve and load arbitrary systems, even those not declared by ASTools directly, or allow alternate implementations of the common systems for server types such as OpenShift or Teiid Designer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-14001) First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14001?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-14001:
--------------------------------
Fix Version/s: 4.2.0.Alpha2
(was: 4.2.0.Alpha1)
> First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
> -------------------------------------------------------------------------------------------------
>
> Key: JBIDE-14001
> URL: https://issues.jboss.org/browse/JBIDE-14001
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.0.1.Final
> Environment: Windows 7
> Reporter: David Stephan
> Assignee: Rob Stryker
> Fix For: 4.2.0.Alpha2
>
>
> After Marking a jar as deployable and deploying to EAP server, the jar is deployed correctly.
> Then, after restarting JBDS, then restarting the app server from within JBDS, the deployed jar is deleted.
> After restarting the server again, the jar is deployed, and subsequent restarts don't remove the jar.
> Possibly related, when you first mark the jar as deployable and deploy to a server, the context menu item changes to "Unmark as Deployable." After a restart of JBDS, this context menu item is back to "Mark as Deployable".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBIDE-15915) Large-scale refactor to split major functionality into clear systems with public API
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15915?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-15915:
--------------------------------
Fix Version/s: 4.2.0.Alpha2
(was: 4.2.0.Alpha1)
> Large-scale refactor to split major functionality into clear systems with public API
> ------------------------------------------------------------------------------------
>
> Key: JBIDE-15915
> URL: https://issues.jboss.org/browse/JBIDE-15915
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: server
> Affects Versions: 4.2.0.Alpha1
> Reporter: Rob Stryker
> Assignee: Rob Stryker
> Fix For: 4.2.0.Alpha2
>
>
> ASTools currently suffers from tight coupling, mixing of API and non-API classes, an API that is not clear, a very long unit test run, and other symptoms which stem from the above problems. Several newer use-cases are impossible to solve without making the problem worse.
> To solve these issues, ASTools needs to have its major functionality split up and separated. The API for each system needs to be clearly apparent and easy to use, from both core, ui, and other consumers. In general, if UI classes are not using the API and are reaching in to internal classes, then the API is insufficient and needs to be cleaned up.
> This large-scale refactor will focus first on the deploy-only server as an example and can eventually be (easily) extended to the other server types.
> https://community.jboss.org/wiki/JBossTools-DelegatingServersViaSubsystems
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months