commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <rwald...@us.britannica.com>
Subject RE: minor commons-pool interface change
Date Wed, 01 May 2002 17:41:12 GMT
> Ummmmmmm....Jakarta projects aren't the only people who use your code.

Insightful.

Sorry for going out of my way to make life easier for the other Jakarta
folks.  I checked out everything that gump builds that depends upon
commons-pool, and we've talked about it in more than one thread (including
this appropriately titled one) on commons-dev. Don't know what else I can
do.

> really should follow standard deprecation 
> rules instead of just making
> changes like you are.

> If you deprecate the methods properly, it won't  break a gump build.

How exactly will "standard deprecation rules" allow one to make this change
(changing the signature of an interface method) without potentially breaking
a build?  We can leave the old method around, but if you don't have the new
one, any implementation will still be broken.  The base classes we've added
will minimize but not totally eliminate this problem in the future.

> That said, I will make the changes *after* 
> you make another pool release so
> that Fulcrum isn't dependent on CVS 
> head of pool.

And what release are you using now?

Are you saying go ahead and remove the methods, or that you'd like us to
keep 'em around in a 1.0 release.  I'm a little resistant to that
(deprecated methods in a 1.0 release seem a bit silly) but it's a
possibility.  Alternatively, change your ObjectPool reference to a
StackObjectPool reference (it's already hard coded to that anyway) and it'll
work with any existing or planned revision in CVS.
 
(If you want, the STRUTS_1_1_B1 tag is probably a reasonable "release"
before these changes.)

- Rod





Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message