db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2412) Refactor NetworkServerControlImpl
Date Wed, 14 Mar 2007 00:05:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480614
] 

Daniel John Debrunner commented on DERBY-2412:
----------------------------------------------

bernt> Refactor ... bugs ...

When I'm refactoring code and start to see bugs I get very nervous about my own changes, because
the refactoring is only shuffling code around so it should be low risk for bugs. Even fixing
the bugs that the tests find doesn't make me completely happy because what about the bugs
I introduced that are not found by the tests.
So I often take the approach of "throwing away all the work" and starting again (having now
understood the direction I want to go), this time making small incremental steps and frequent
commits/patches having run tests on each change. This gives me as the contributor greater
confidence I'm not adding additional bugs and hopefully any reviewers greater confidence because
the commit messages/patches are smaller and easier to understand and review.

So may I propose (once you come back rested from what I hope is a vacation is Gran Canaria
:-) that you attack this issue in an incremental fashion. A 300k patch with bugs was not an
easy thing to look at.



> Refactor NetworkServerControlImpl
> ---------------------------------
>
>                 Key: DERBY-2412
>                 URL: https://issues.apache.org/jira/browse/DERBY-2412
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server
>            Reporter: Bernt M. Johnsen
>         Assigned To: Bernt M. Johnsen
>            Priority: Minor
>         Attachments: derby-2412-v1.diff, derby-2412-v1.stat
>
>
> NetworkServerControlImpl is overly complex and serves several purposes. This makes it
hard to penetrate the logic, to debug and to maintain. 
> I propose (actually, I've alread done a whole lot) to tear it apart and move the current
semantics into the following new classes:
> NetworkServer - the actual network server code
> NetworkAdminServer - the implementation of network administration commands (ping, shutdown
etc)
> NetworkAdminClient - the client for network administration of Derby
> NetworkAdminProtocol - the administration command protocol (as opposed to the DRDA protocol)
> plus a couple of utility classes (common methods, common constants, error messaging,
exceptions etc)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message