Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Message-ID: <3BC9D913.50508@yahoo.com>
Date: Sun, 14 Oct 2001 19:27:31 +0100
From: Paul Hammant <Paul_Hammant@yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.5) Gecko/20011011
MIME-Version: 1.0
To: Avalon Development <avalon-dev@jakarta.apache.org>
Subject: Re: Deprecations - 59 occurrences in 35 files
References: <3BC821DA.5050502@yahoo.com>
 <20011014134605.XNFZ13193.mss.rdc2.nsw.optushome.com.au@there>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Peter,

>>Can we start to delete some deprecations?  It's not like we are the
>>servlet API with tens of thousands of detached users.. I think that all
>>are on this list and savvy enough to cope given that that methods have
>>been marked as deprecated for many months now.
>>
>
>Depends on which parts. I can't see the advantage in changing some code even 
>though it is deprecated (ie logkit). With Phoenix I actuallly want to force 
>all the incompatible changes at once to make the transition from alpha->beta 
>as easy as possible on users. Other stuff would need to be done on a case by 
>case basis.
>
Good point.  I had just noticed that BlockContext.getDefaultThreadPool() 
forced a runtime exception rather than behaved in a backwards compatible 
way, thus forcing the migration early ;-)

Perhaps we could limit the purges to Phoenix and Cornerstone then as 
considerably less people/teams use those APIs.

Regards,

- Paul H


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org