db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Wed, 09 Nov 2005 17:32:58 GMT
JIRA appears to be down, so I will respond via email...

Rick Hillegas (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12357094 ]

> 
> Rick Hillegas commented on DERBY-289:
> -------------------------------------
> 
> o Yes, please. Please move SQLState.java to common.


OK, but I'll do this as a separate change

> 
> o CommonFeatures doesn't seem to provide much value. Could it be merged into SharedComponentInfo?
>

The intent with splitting out CommonFeatures is that over time its size 
could grow, and keeping it separate would allow it to not be included in 
the release jars as all it contains is constants.  This is in line with 
the overall goal of keeping jar size commensurate with actual 
functionality provided.

Also note that there will be other shared components, each of which will 
have their own feature constants (see my unit tests for one example). 
Each shared component will also have its own Info class that extends 
SharedComponentInfo.  This is another reason it doesn't make sense to me 
to merge the CommonFeatures constants (which are specific to one shared 
component, "Common") into SharedComponentInfo (which is going to be used 
across multiple shared components).

If *anything* CommonFeatures should be merged into CommonInfo, but see 
my point in the previous paragraph about why I think there is merit in 
keeping them separate.


> o I'm curious about the catching of ShutdownException in MessageServices after calling
MessageUtil.getCompleteMessage(). Do you understand how this exception is raised?

I have no idea.  I am just keeping existing old behavior that caught 
this exception.  I think the idea is that you never know when you may 
get a Shutdown and you have to handle it appropriately.

> 
> o You might want to hold off on this submission until you check in my compatibility test
patch which moves the JUnit tests under their own subdirectory in the code tree. That will
avoid the nasty svn-moving of your tests.

Yep

David

> 
> 
>>Enable code sharing between Derby client and engine
>>---------------------------------------------------
>>
>>         Key: DERBY-289
>>         URL: http://issues.apache.org/jira/browse/DERBY-289
>>     Project: Derby
>>        Type: Improvement
>>  Components: Network Client
>>    Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.1.0
>> Environment: N/A
>>    Reporter: David Van Couvering
>>    Assignee: David Van Couvering
>>    Priority: Minor
>>     Fix For: 10.2.0.0
>> Attachments: DERBY-289.diff
>>
>>Right now, there is no way for the Derby network client to share code with the Derby
engine.  We should have a separate jar file, e.g. derby_common.jar, that contains shared code
and is used by both the client and the engine.  
> 
> 

Mime
View raw message