This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 33567 - Flaws in server execution
Summary: Flaws in server execution
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Nam Nguyen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-13 15:56 UTC by _ rkubacki
Modified: 2006-06-05 00:39 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2003-05-13 15:56:43 UTC
TargetServer.doDeploy method calls distribute() on
DeploymentManager and then immediately start().
This is wrong because distribute is asynchronous
operation and may not be finished before start()
is called and result status is not consulted.

Timers in TargetServer are useless except for
debug prints. We should avoid these two inner classes.

DeployProgressMonitor will not close when
operation is completed earlier than listener is
attached (ProgressObject can be set directly to
completed/failed status). It means that status has
to be consulted at the begining to check for
completed or failed value. BTW: this bug comes
from bad design in JSR88.
Comment 1 Nam Nguyen 2004-01-16 07:28:18 UTC
Actually the code in this file became a bit messy as it grows from
archive deployment into additional functionality like redeploy,
incremental and in-place deployment, touched by many people.  It is
time to cleanup.  The check for deployment status even before
attahcing a handler to the ProgressObject has already been added
during incremental deployment implementation.  The practice had not
been applied to other kind of deployements.

I has spent a day today cleaning-up and refactoring the deploy
code/logic to make it more bullet-proof and maintainable.

About JSR-88 deployemnet architecture, I am not sure I got your point.
   Maybe its better for the deployer to pass the ProgressObject as
argument instead of receiving as returned?  This way the calls could
be synchronous.
Comment 2 Nam Nguyen 2004-01-16 07:30:09 UTC
I think my cleanup is reasonable to close this issue.  Please reopen
if not so.