Avalon already has a rich lifecycle management system, but sometimes you need an application specific extension. Previously you had to find out how any one container defined meta information (like version, whether the component is threadsafe or not, etc.).Ģ) (Tentative but likely) Standard way of extending the component lifecycle. This allows the component to be used in any Avalon compliant container with zero issues. We are unifying the way we define meta data for the components. Slated for the next version of Avalon already:ġ) Enhanced Meta Data. What we want to find out from the community at large is:ġ) Are you currently using Avalon in one of your projects?Ģ) If not, what would it take for you to consider using it on a future project?ģ) If yes, what did you like best? What were your greatest challenges? If you could choose one way to improve Avalon, what would it be? The Avalon team has identified some anti-patterns related to its use, and wants to provide a way to make it easier to use correctly. The container is the code that manages all the components and how to access them. The changes are minimal, and focus on a tighter definition of the contract between the container and the component. ![]() The Avalon team is in the process of identifying the requirements for a new version of the Avalon Framework. If you would like to comment further on any of the highlighted discussions then please do so on the appropriate list, if you want to comment on the newsletter itself then please point your comments to Oxspring I'd like to thank those who contributed and hope that you enjoy the read. This month we have news based contributions from several projects and a plea for requirements from Avalon. My involvement at jakarta has been mainly as a user of various subprojects, a lurker on the general and commons-dev lists, a long time lurker and occasional conributor to Ant, and lately this Newsletter has become my pet project. So who's sending this to you? I'm a UK software developer working mainly with database webapps, with an interest in the development processes involved. The editorship of the various sections and overall will probably vary which should hopefully lead to a fairly dynamic monthly newsletter. The aim of the newsletter is to try and let people know what's been going on in the jakarta projects when they have been unable to monitor all of them themselves. ![]() Welcome to the issue #1 of the Jakarta Newsletter.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |