avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Phoenixs Deprecated features
Date Sat, 11 May 2002 02:07:02 GMT

Pete:

No problem with any of the proposed changes.
I would like to see addition of support for CascadingConfigurations 
together with the addition of extensions to the .xinfo file to contain a 
default confituation declararation (which would bring Phoenix and Merlin 
almost totally in sync). Any thoughts about how this can be achieved? 
 Inital ideas are either (a) implict addition of default configuration 
handling within Phoenix, or (b) the ability to declare an 
alternative/pluggable configuration resolver.  

Cheers, Steve.


Peter Donald wrote:

>Hi,
>
>I am slowly going through and preparing Phoenix for another release. This 
>involves cleaning up bits and pieces and making sure everything that is 
>supposed to work, actually works. 
>
>Some of the following things are deprecated and have been for a while. I would 
>like to know if anyone is using any of these features and if so tell me so 
>they can be preserved. 
>
>NOTE: Please send replies to the avalon-phoenix-dev mailing list so that this 
>can be coordinated in one place.
>
>Heres the list of changes that I want to implement. If there is no negative 
>responses by next weekend I will go ahead and do it.
>
>----------------------------------------------------------------------------------------
>Feature: Threads pools accessible from BlockContext
>Deprecated since: 2001/09/20
>
> ie The check if the following methods are used anywhere in your code.
>  BlockContext.getThreadPool(String)
>  BlockContext.getDefaultThreadPool()
>----------------------------------------------------------------------------------------
>Feature: BaseLogger accessible from BlockContext
>Deprecated since: Sometime before 2001/04/27
>
> ie The check if the following methods are used anywhere in your code.
>  BlockContext.getBaseLogger()
>----------------------------------------------------------------------------------------
>Feature: Using elements named "block-listener" in assembly.xml
>Deprecated since: 2002/01/26
>
>ie the correct element name is <listener/> now so as not to confuse 
>differences between Block and Applicaiton Listeners.
>----------------------------------------------------------------------------------------
>Feature: Using config elements named"management" to expose services as MBeans
>Was only Non-deprecated between 2002/01/12 and 2002/01/25
>
>ie the correct element name is <management-access-points/>
>----------------------------------------------------------------------------------------
>Feature: Using Service class
>Deprecated since: 2001/09/25
>
>Deprecated with no replacement.
>----------------------------------------------------------------------------------------
>Feature: Old .sar packaging format
>Deprecated since: 2001/10/22
>
>The .sar format previously allowed all blocks to be stored in 
>blocks/*.bar and libraries to be stored in lib/*.zip, lib/*.jar. This has been 
>changed so that all jars/libraries are stored in SAR-INF/lib/*.jar and also 
>allows class files in SAR-INF/classes. The configuration files have also 
>moved into SAR-INF/*.xml
>----------------------------------------------------------------------------------------
>Feature: Directly Using LogKit Logger
>Deprecated since: 2001/10/31
>
>We have been using a Logging facade (in o.a.a.framework.logger.*) for a while 
>now but have had to support the old form of using the LogKit logger directly. 
>Dropping support for non-facade would allow us to remove yet another 
>dependenancy from deployed applications (and allow us to use JDK1.4 Logging 
>where supported).
>----------------------------------------------------------------------------------------
>Feature: Use old config file name server.xml
>Deprecated since: 2001/11/10
>
>SAR-INF/server.xml was renamed to SAR-INF/environment.xml because phoenix and 
>this configuration was not specific to servers but to the environment in 
>which the applicaiton executes.
>----------------------------------------------------------------------------------------
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message