You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David Van Couvering (JIRA)" <de...@db.apache.org> on 2005/07/13 00:00:25 UTC
[jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
[ 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
Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby
client and engine
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, Jeff. I like your ideas, I think there's something we can do here.
I need to think about it further. There are any number of ways we can
accomplish having a single source for the messages so that you can
generate DITA and the message properties file. An XML file might be a
good approach. This requires further thought.
That said, I agree with your thought that it probably belongs as a
separate task. Would you be willing to create a JIRA item for this?
Thanks,
David
Jeff Levitt wrote:
> One addendum to that idea:
>
> In the future, we could implement addition information
> about the message such as a suggested user response
> and a more detailed explanation of the error. This
> could also be stored in the comment for that message,
> and then propogated to the DITA file generated from
> the code. So my example comment might be modified to
> look like this:
>
> // message metadata id="22015"
> // begin parameters
> // p1="functionName" p2="typeName" p3="typeName"
> p4="typeName"
> // end parameters
> // userresponse="This would be text of what the user
> should do to correct the problem"
> // explanation="This would be more detailed
> information about the error that might not be
> appropriate to display for each time that error
> occurs, but might be useful in the documentation for
> that error."
> // end message metadata
>
>
> --- Jeff Levitt <de...@mylevita.com> wrote:
>
>
>>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)"
>><de...@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.
>>>
>>
> === message truncated ===
>
Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Posted by Jeff Levitt <de...@mylevita.com>.
One addendum to that idea:
In the future, we could implement addition information
about the message such as a suggested user response
and a more detailed explanation of the error. This
could also be stored in the comment for that message,
and then propogated to the DITA file generated from
the code. So my example comment might be modified to
look like this:
// message metadata id="22015"
// begin parameters
// p1="functionName" p2="typeName" p3="typeName"
p4="typeName"
// end parameters
// userresponse="This would be text of what the user
should do to correct the problem"
// explanation="This would be more detailed
information about the error that might not be
appropriate to display for each time that error
occurs, but might be useful in the documentation for
that error."
// end message metadata
--- Jeff Levitt <de...@mylevita.com> wrote:
> 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)"
> <de...@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.
> >
>
=== message truncated ===
Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Posted by Jeff Levitt <de...@mylevita.com>.
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)"
<de...@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
>
>