db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Tue, 12 Jul 2005 22:00:25 GMT
    [ http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12315632 ] 

David Van Couvering commented on DERBY-289:
-------------------------------------------

I would like to modify the network client to use localized messages.
However, the right way to do this is using message ids, and these
message ids probably should be based on SQL states, just as with
the embedded code.  We should also take advantage of the existing
infrastructure for properly loading and composing message strings,
rather than build a duplicate infrastructure for the client code.

As a first step towards fixing exception handling in the client, I am
therefore planning on working on creating a common package hierarchy 
that contains code that can be shared across client and server code.

Here are the steps I am planning on taking.  Your comments are most welcome.

- Create a new top-level directory under trunk/java called "common".  All
  packages under this directory would have the prefix org.apache.derby.common

- Refactor the existing service classes under org.apache.derby.iapi.services
  and org.apache.derby.impl.services into common code and engine-specific
  code.  I would do the minimum possible so that the error and i18n
  services can move over to the common directory.  I do not intend to move
  over other services even if they could be considered common; I feel this
  work should be done only as needed.
  
  At first glance, the packages impacted by this refactoring effort would be:
    org.apache.derby.iapi.services.Monitor
    org.apache.derby.impl.services.Monitor
    org.apache.derby.iapi.services.i18n
    org.apache.derby.iapi.error

  There may be other packages impacted due to dependencies I have yet to
  discover.

  I have noticed that some of the code seems to have some fairly strong
  ties to the engine environment.  I hope to solve this by 
  splitting some classes into a generic superclass in the common 
  hierarchy and a subclass in the engine hierarchy.  

- In terms of the build environment, the easy approach, and the approach 
  that matches what already exists, would suggest creating a new jar file, 
  derbyclient.jar.  

  However, we already have a large number of jar files, and adding one 
  more I feel is going in the wrong direction.  I would like to better 
  understand the motivation for having multiple jar files when I think 
  we could do with two: one for engine/server-side code and one for 
  client code, e.g.  

    derby.jar
    derbyclient.jar
    <locale_jar_files>

  Comments on this are most appreciated.

  Thanks,

  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
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> 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.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message