db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: [jira] Commented: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
Date Fri, 29 Apr 2005 04:45:05 GMT
David Van Couvering wrote:
> Whoa, I was just trying to fix the System.exit() problem :)
> 
> I agree with you that there is a bit too many responsibilities for one 
> object, and that parsing of arguments should be separated from execution 
> of logic.  However, I don't think that I should attack the separation of 
> establishing a remote connection and driving the wire protocol as part 
> of this bug.  I think we should log a separate bug for that issue, I 
> think it's a great thought for a more flexible design.
> 

I tend to agree. KISS for now and let's tackle the bigger issue when it 
has had a bit more thought.

<snip/>
> 
> However, other Derby tools, however, like ij and dblook, don't have this 
> command-based interface.  They do need some kind of "execute" method 
> that matches the way it is invoked from the command-line.  As discussed, 
> if the behavior of exit status when returning from main() is well 
> defined by the Java spec, then we can just use main with no call to 
> System.exit().  Otherwise, we should provide a separate execute() method 
> for embedding applications.
> 

ij seems wierd to me as I would expect an app just to use raw JDBC - 
perhaps commands to execute a script would be useful.

> If we decide upon a separate execute() method, my question still is, 
> what is the easier way to invoke this execute method, using an arg 
> array, or by instantiating an instance and setting bean properties?   I 
> think this is an indepedent question from any separation of concern 
> issues within the tool itself.  I personally think an arg array is 
> easier, but perhaps I'm missing an important architectural issue.
> 

What I don't like with the arg array is the lack of context and type safety.

For example, I find

cmd.execute(new String[]{"-p", "1567", "-h", "localhost" })

less meaningful than

cmd.setPort(1567);
cmd.setHost("localhost");
cmd.execute();

and probably harder to implement when you add in error checking.

--
Jeremy

Mime
View raw message