Submitting shared i18n/error code separate from classloader work

["David W. Van Couvering" <Da...@Sun.COM>]

There are a number of folks who have mentioned they are depending on the 
code sharing framework to move forward with their work.  In particular 
the JDBC 4 exception subclass work depends on the exception framework I 
put together for client exceptions.  Also, Francois' encryption work 
includes shared code and he is waiting on the framework as well.

The classloader work I am doing to avoid code shadowing bugs in a mixed 
version environment is going well, most tests are passing but there are 
still some corner cases I have to work out.  I am thinking a week before 
I submit a patch, and then I expect (and rightly so) that this will go 
through a few weeks of review.

I was wondering if in the meantime I can unblock those who are waiting 
for me by checking in the code sharing framework *without* the 
classloader work.  This would be with the solemn promise to submit the 
classloader work soon thereafter, and definitely before the next patch.

If for some sad reason the classloader stuff gets a -1, we can revert to 
the somewhat more ungainly feature-management functionality I had 
submitted a month ago and which looked like it was moving towards 
acceptance.  If that doesn't pass muster, we can revert to generating 
copies of the shared code with separate package names for each jar file 
(as Kathey suggested).  So I think regardless of what choice we make 
there, the shared code can still be written and placed under the 
org.apache.derby.shared package hierarchy.  All that would change would 
be how this shared code would ultimately be packaged into jar files.

Is this acceptable?  If so I'll go ahead and clean up the i18n and 
error-handling shared code and get it submitted so folks can move forward.

Thanks,

David

Re: Submitting shared i18n/error code separate from classloader work

[Francois Orsini <fr...@gmail.com>]

Hi David,

Am not blocked by the code sharing framework at the moment - the few
candidate classes that were shareable can just be duplicated between the
client and the engine for now and I will revisit them (to be shared) when
the code sharing infrastructure is there.

Thanks,

--francois

On 1/6/06, David W. Van Couvering <Da...@sun.com> wrote:
>
> There are a number of folks who have mentioned they are depending on the
> code sharing framework to move forward with their work.  In particular
> the JDBC 4 exception subclass work depends on the exception framework I
> put together for client exceptions.  Also, Francois' encryption work
> includes shared code and he is waiting on the framework as well.
>
> The classloader work I am doing to avoid code shadowing bugs in a mixed
> version environment is going well, most tests are passing but there are
> still some corner cases I have to work out.  I am thinking a week before
> I submit a patch, and then I expect (and rightly so) that this will go
> through a few weeks of review.
>
> I was wondering if in the meantime I can unblock those who are waiting
> for me by checking in the code sharing framework *without* the
> classloader work.  This would be with the solemn promise to submit the
> classloader work soon thereafter, and definitely before the next patch.
>
> If for some sad reason the classloader stuff gets a -1, we can revert to
> the somewhat more ungainly feature-management functionality I had
> submitted a month ago and which looked like it was moving towards
> acceptance.  If that doesn't pass muster, we can revert to generating
> copies of the shared code with separate package names for each jar file
> (as Kathey suggested).  So I think regardless of what choice we make
> there, the shared code can still be written and placed under the
> org.apache.derby.shared package hierarchy.  All that would change would
> be how this shared code would ultimately be packaged into jar files.
>
> Is this acceptable?  If so I'll go ahead and clean up the i18n and
> error-handling shared code and get it submitted so folks can move forward.
>
> Thanks,
>
> David
>
>
>
>

Re: Submitting shared i18n/error code separate from classloader work

["David W. Van Couvering" <Da...@Sun.COM>]

Hi, Dan.  This looks very appealing.  The one area I'm a little 
uncertain about is with the messages that are common across client and 
server.  If the engine code doesn't use the shared mechanism to load 
messages (where the algorithm is look in the shared message bundle 
first, then look in your local message bundle), then these messages will 
be duplicated between engine and client (sharing the same SQL State).

Alternately I could duplicate the code to look in the shared area first, 
but if anything that seems worse.

I guess copying messages (IMHO temporarily) isn't too bad, especially if 
they're old, established messages.  Any comments?

David

Daniel John Debrunner wrote:
> Kathey Marsden wrote:
> 
> 
>>David W. Van Couvering wrote:
>>
>>
>>
>>>I was wondering if in the meantime I can unblock those who are waiting
>>>for me by checking in the code sharing framework *without* the
>>>classloader work.  This would be with the solemn promise to submit the
>>>classloader work soon thereafter, and definitely before the next patch.
>>>
>>
>>I am not comfortable having a regression like that committed, especially
>>one that has been so tricky  to fix.
>>For things that need to go in now,  I prefer the duplicate now and
>>cleanup later method that Francois suggests.
> 
> 
> For new shared code used by the client it could be added to the shared
> package while the engine continues to use its current code.
> 
> Dan.
> 

Re: Submitting shared i18n/error code separate from classloader work

[Daniel John Debrunner <dj...@apache.org>]

Kathey Marsden wrote:

> David W. Van Couvering wrote:
> 
> 
>>I was wondering if in the meantime I can unblock those who are waiting
>>for me by checking in the code sharing framework *without* the
>>classloader work.  This would be with the solemn promise to submit the
>>classloader work soon thereafter, and definitely before the next patch.
>>
> 
> I am not comfortable having a regression like that committed, especially
> one that has been so tricky  to fix.
> For things that need to go in now,  I prefer the duplicate now and
> cleanup later method that Francois suggests.

For new shared code used by the client it could be added to the shared
package while the engine continues to use its current code.

Dan.

Re: Submitting shared i18n/error code separate from classloader work

[Kathey Marsden <km...@sbcglobal.net>]

David W. Van Couvering wrote:

> I was wondering if in the meantime I can unblock those who are waiting
> for me by checking in the code sharing framework *without* the
> classloader work.  This would be with the solemn promise to submit the
> classloader work soon thereafter, and definitely before the next patch.
>
I am not comfortable having a regression like that committed, especially
one that has been so tricky  to fix.
For things that need to go in now,  I prefer the duplicate now and
cleanup later method that Francois suggests.

New year, old topic, same position.

Kathey