db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Levitt <de...@mylevita.com>
Subject Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Tue, 12 Jul 2005 22:41:29 GMT
David, I've been thinking about your idea suggested
fairly recently concerning generating the
documentation page of the error messages from the
code.  Would that complicate things too much if we
combined that work with this effort?

My thought (and please let me know if this is
something we should perhaps do later, after your
proposal is implemented...) is that perhaps we can
store metadata about a message in a comment within the
code.  So for example, the string for message 22015
might be stored in the code like this currently:

The %1 function is not allowed on the following set of
types. First operand is of type %2. Second operand is
of type %3. Third operand (start position) is of type
'%4'.

So after that string, maybe we have a comment that
looks like this:

// metadata message="22015" begin parameters
p1="functionName" p2="typeName" p3="typeName"
p4="typeName" end parameters

(note that I am not proposing this exact syntax for
the comment, just showing the logic)

Thus, your DITA doc file generation script would be
modified so that when it prints the message string to
the dita file, if it comes to a "%x" parameter in the
string, it searches the comment for the "px" value for
that parameter and replaces the token with the value:

The '<functionName>' function is not allowed on the
following set of types. First operand is of type
'<typeName>'. Second operand is of type '<typeName>'.
Third operand (start position) is of type
'<typeName>'.

Is that kind of logic possible?  I think it might be
easy to write some sort of script to make the one-time
conversion of the existing messages in the doc to this
code + comment layout, and then we could say that any
new messages written by any contributors in the future
must follow this procedure of identifying labels for
their parameters in comments.

Thoughts?




--- "David Van Couvering (JIRA)"
<derby-dev@db.apache.org> wrote:

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