Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42718B33.5050600@apache.org>
Date: Thu, 28 Apr 2005 18:17:39 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [jira] Commented: (DERBY-214) Remove System.exit() calls from
 the DB2jServerImpl.java
References: <124244851.1114624173884.JavaMail.jira@ajax.apache.org>
 <42707488.4060107@sbcglobal.net> <4270E3CF.5050204@sun.com>
 <4270E927.9020107@sbcglobal.net> <4270F0A1.2070608@apache.org>
 <4270FA03.1010802@sun.com> <4270FE2C.1070309@apache.org>
 <427160E8.4020208@sun.com>
In-Reply-To: <427160E8.4020208@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Van Couvering wrote:
> 
> Also, the JavaBean approach assumes you create an instance of the beast, 
> and I have noticed that many command-line classes have most of their 
> code in static methods and use static variables (not that they should, 
> but that's what they do).  Also, it might actually be easier to set up 
> an array of Strings rather than call a bunch of set methods, especially 
> if you can create the array in-place, e.g.
> 
> DB2jServerImpl.main(new String[] { "ping", "-p", "2000"} );
> 
> rather than
> 
> DB2jServerImpl impl = new DB2jServerImpl()
> impl.setCommand("ping");
> impl.setPort("2000");
> impl.execute();
> 

My concern here is coming from confusion in the responsibilities between 
NetworkServerControl and DB2jServerImpl. For example, there are two ways 
to set the maxthreads:

1) new NetworkServerControl().setMaxThreads(100);

2) NetworkServerControl.main(
      new String[]{"maxthreads", "100"});

Ultimately these both end up calling DB2jServerImpl.netSetMaxThreads()

DB2jServerImpl is doing three completely different things here: it is 
setting up the remote connection, it is driving the wire protocol to the 
remote server (see the impl of netSetMaxThreads), and it is responsible 
for parsing and verifying the command line arguments passed in. I think 
these concerns can be separated resulting in a simpler implementation 
that is easier to embed and use from other tools such as Eclipse.

I would first suggest factoring out the connection setup and teardown - 
perhaps a NetworkServerConnection class with hostname and port 
properties (perhaps username, password or other credential) and an 
execute method that takes a command object e.g.

public class NetworkServerConnection {
    public void connect() throws TransportException;
    public void close() throws TransportException;

    public Object execute(NetworkServerCommand cmd)
       throws TransportException, CommandException;
}

Each command (ping, maxthreads, etc) is represented by an object that 
implements NetworkServerCommand and which can be set up with the 
appropriate properties e.g.

public class SetMaxThreadsCommand implements NetworkServerCommand {
    public void setMaxThreads(int threads);
}

Each command would know how to write itself to the wire; heck if you 
were prepared to break backward compatibility you could simplify things 
further by just using serialization.

For command line support, NetworkServerControl.main parses the 
arguments, creates a NetworkServerConnection and the appropriate command 
  and then submits it to the remote server. Basically it just contains 
implementation for handling the command line syntax.

For embedded use, a tool can create and maintain a connection for as 
long as necessary, getting the connection parameters any way it wants 
(e.g. a host/user/password dialog). The commands can be created and 
submitted in response to UI events just like any others. Both the 
connection and the commands can use beaninfo to define their properties.

Although there are more moving parts in this, I think overall it is a 
more maintainable solution as the concerns of connection, commands and 
UI have been clearly separated.

--
Jeremy