On Monday 18 October 2004 06:23, Morten Haavaldsen wrote: > regardless name, strange since I got the impression from the new look on > Avalon website that it was here to stay?
The 'commericial look' of the Avalon site, was possibly the last nail in the coffin. It triggered an uproar of emotions from powerful ASF members, and resulted in the actual downfall of Avalon as a project. > I think Java developers really need a server framework on which to build > servers. > Everybody seems to think that it is all about EJB's , servlets etc... > We really need a good, open, server framwork which enables developers to > make servers...as simple as that. YES! You got it all right. Outside of J2EE we basically have 3 main efforts; 1. Pico - essentially design pattern around injection of dependencies in constructors. Metro is working towards supporting Pico-developed components. 2. Sprint - nice framework which essentially focus on 'apparent features' for enterprise developers. I have two problems with it, JavaBeans (which essentially is what they are prescribing) has the nasty habit of never knowing when they are initialized. Secondly, it doesn't bother about classloading management, which I think is essential to build 24/7 servers. 3. Avalon-Merlin turned Metro. Strong focus on application Model, classloading management, integrated build system and flexible runtime. It is a platform that is easy to extend, and we are expected to support both Pico and Spring components in the not so distant future. > So, > what is the URL Metro? First, read the announcement. http://marc.theaimsgroup.com/?l=avalon-users&m=109782104930454&w=2 Secondly, I has just been informed that the "paris.dpml.net" DNS entry will not be operational until Wednesday :o( (should have opted to manage it ourselves) > I hope Metro gets more examples from the "developers" point of view. Yes. Those who has been around here for long, can probably testify that we do care about helping users with their problems. Very hands-on. Documentation is not our strong side, though, BUT the new community model makes all users committers, anyone who has something useful will commit by himself/herself. > A good example would be a case where a server terminates a protocol(e.g. > HTTP, or pure socket based for that matter), analyzes the incoming > request/mesage etc. and dispatches it to some sort of handler. The tutorial > could then also show logging etc. Yes. Agree. Timothy Bennett brought up a few months ago, that a 'request-driven' subsystem could be created, where the implementation components had a single view of requests, no matter if those were http, mail, soap or something else. The adapter was to be plugged outside. I think it is a great idea, and not that hard to implement on the platform either, even allowing that you can plug in new protocol handlers in runtime, without stopping the server. > One important aspect often forgotten is to have an example on how to > instrument(e.g. JMX?) the solution as well... Agree. Cameron Fieber is our JMX guy, but he has a pretty busy schedule at times, and there are 'spurted' efforts on this front every now and then. I am sure he would appreciate any help he can get. There are so much that can be done on the very solid foundation that mostly Stephen McConnell is responsible for. Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
