Details
-
Type:
Patch submission
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.4.4, 2.1.1
-
Fix Version/s: 2.1.2
-
Component/s: Core: Lifecycle, Core: Transports
-
Labels:None
-
Environment:
1.4.x trunk, Windows XP
-
Includes test case?:yes
-
User impact:Medium
-
Similar Issues:None
Description
org.mule.providers.AbstractConnector implements the basic lifecycle of a connector by defining several abstract methods (e.g., doInitialise, doConnect, doStart, doStop, doDisconnect, doDispose). These abstract methods should only called when the connector's state changes (i.e., calling AbstractConnector.startConnector twice results in the second call being a NOP).
Two issues:
1) AbstractConnector.initialise() throws an AlreadyInitialisedException if it is called when the connector has already been initialised. This behaviour is inconsistent with the way AbstractConnector.startConnector() and AbstractConnector.stopConnector() handle multiple calls (i.e., NOPs instead of exceptions). However, this patch does not address this difference as it's arguable which is the better behaviour.
2) AbstractConnector.dispose() does not throw an AlreadyDisposedException, nor does it perform a NOP if the connector is already disposed. Instead, it calls doDispose() regardless. It's a reasonable expection of a connector writer that doDispose() should only be called once. Because it is difficult to handle exceptions during disposal, it is understandable that no AlreadyDisposedException should be thrown; however, multiple disposal calls should be NOPs.
The attached patch changes AbstractConnector.dispose() so that it logs a message if the connector is already disposed instead of calling doDispose()
Issue Links
Activity
| Field | Original Value | New Value |
|---|---|---|
| Attachment | MulePatch.zip [ 11430 ] |
| Priority | To be reviewed [ 6 ] | Major [ 3 ] |
| Fix Version/s | 1.4.4 [ 10330 ] | |
| Labels |
| Workflow | Copy of Main Mule Workflow [ 58906 ] | Fixed Main Mule Workflow (after JIRA upgrade) [ 62577 ] |
| Fix Version/s | 1.4.4 [ 10330 ] |
| Workflow | Fixed Main Mule Workflow (after JIRA upgrade) [ 62577 ] | Copy of Main Mule Workflow [ 66476 ] |
| Workflow | Copy of Main Mule Workflow [ 66476 ] | Fixed Main Mule Workflow (after JIRA upgrade) [ 70100 ] |
| Assignee | Travis Carlson [ tcarlson ] |
| Status | Open [ 1 ] | Closed [ 6 ] |
| Fix Version/s | 2.0.0 [ 10438 ] | |
| Resolution | Fixed [ 1 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
| Status | Reopened [ 4 ] | In Progress [ 3 ] |
| Affects Version/s | 2.1.1 [ 10531 ] |
| Fix Version/s | 2.0.0 [ 10438 ] | |
| Fix Version/s | 2.1.x Backlog [ 10522 ] |
| Fix Version/s | 2.1.x Backlog [ 10522 ] | |
| Fix Version/s | 2.1.2 [ 10553 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |
| Transition | Time In Source Status | Execution Times | Last Executer | Last Execution Date | |||||
|---|---|---|---|---|---|---|---|---|---|
|
261d 11h 41m | 1 | Travis Carlson | 20/Nov/08 07:01 AM | |||||
|
13m 30s | 1 | Travis Carlson | 20/Nov/08 07:14 AM | |||||
|
26m 28s | 1 | Travis Carlson | 20/Nov/08 07:41 AM | |||||
|
2h 32m | 1 | Travis Carlson | 20/Nov/08 10:13 AM |
- Repository mule on http://foo.bar/ failed: Error in remote call to 'FishEye 0 (http://foo.bar/)' (http://foo.bar) [AbstractRestCommand{path='/rest-service-fe/changeset-v1/listChangesets/', params={expand=changesets[-21:-1].revisions[0:29], comment=MULE-3062, p4JobFixed=MULE-3062, rep=mule}, methodType=GET}] : java.net.UnknownHostException: foo.bar
Junit test and patch attached.
1) Unzip MulePatch.zip
2) Edit build.xml to set mule.home to your Mule installation
3) Run "ant test-broken" to run the Junit test with the unpatched code. Observe that one of the tests fails and consult test-report for details.
4) Run "ant test-fixed" to run Junit test with patched code and observer that all tests pass.