I was just thinking through how the framework and a container based on Fortress would port over to C# and had some things I wanted to throw out there for thought. Mind you, I'm not an Avalon expert by any means so bare with me.
Fortress (and Merlin) is built with the concept of a hierarchical container. This is a wonderful concept that allows for a lot of flexibility within the container and the components within it. This concept seems to be built around how Java's hierarchical class loaders (hopefully I'm not sticking my foot in my mouth here), giving each container (potentially) its own class loader and a degree on independence from its peers. A similar concept is used in J2EE containers with Web Applications for example; where each Web App can have its own class loader (actually has to have its own). While this concept works well for Java based applications it doesn't quite port as well to C# and .NET because there is no concept of a class loader. Instead, when you need a type (analogous to a Java class), the DLL where that type is defined is loaded globally within the application domain (an application domain is essentially a light-weight process). Once it is loaded it is the one that is used until the app domain exits. There is no means to unload a DLL, which would make it hard to "hot-redeploy" applications (components) since once it was loaded, a newer version could not be loaded (at lease not without affecting the entire app domain, if it could be at all). One possible solution to this would be to load each application into its own app domain. This would allow each application its own DLL suite to be loaded, however, no DLLs could be shared between any two, and they would each have to have their own copies. The major downside of this approach is it would make it more difficult to share information between applications since all communications would have to be remote communications. In the web app example, this would mean all session data would have to be accessed remotely (there would have to be a master (I was going to say root, however there is no hierarchy in app domains) node everyone had access to) and every application that wanted to use that data would have to have access to the DLL the type came from (same name and version). These were just a few things I was thinking about for this port, but they are based on the concept I have of being able to deploy different groups of components as "applications/services" where each application could have its own semi-isolated environment. Another topic I was thinking about was management and security. For management Microsoft is pushing their WMI service which is their proprietary version of the DMI's WBEM initiative. The reason I say its proprietary is because the majority of the schema they use is not part of the standard and their communications mechanism is DCOM and not HTTP like the spec says it should be. While WMI does have the benefit of being integrated into the Windows OS it has some serious limitations when used from C# such as no cross DLL inheritance of management objects and no support for updatable properties or callable methods. I suspect these two issues will be fixed in .NET 2.0 but I haven't heard when that is supposed to arrive. Also, if this container is going to support Mono, I'm not sure how they are handling the WMI infrastructure. I wasn't sure what the approach for this would be so I'm curious what people are thinking. I'd be interested to see if there was a way to do a scaled down JMX port. As for security, there are quite a few issues there and I'm getting tired of this email so I'll put those off until later. As I mentioned in the beginning, I'm still pretty new to Avalon but am trying to learn it quickly. I am also very interested in a C# version of the framework and a container and would love to hear people's opinions/thoughts on what they would like to see and ideas of how to do it. Chris Geer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]