> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > My question about the containers was not about whether I > should use one (Merlin,Fortress,or Phoenix) and what would be > the benefit, it was about why subclassing AbstractContainer > in Fortress :) For example, I didn't have to subclass ECM to > make things work. I talked about the examples of Marcus > because he did subclass AbstractContainer for each example : > servlet example, and swing example. > > My concerns were about the best practices when using > Fortress, not about whether I should use it or not ;) >
Ah. As we keep saying Fortress is functional, but needs polishing. What I want to do is have an AbstractContainer to make it easier to customize, and eventually have a concrete container. So far, all the example containers we have done only expose the getComponentManager() method publically and use the default logic. We need to separate out what is really abstract, and what should be a concrete implementation feature. When we are satisfied with the split, we will have a concrete container. For now, you do need to subclass the AbstractContainer to use Fortress. The idea behind it is to make it easy to customize how the container creates components. I have forced it to load a default implementation of a critical component if none were specified in the configuration file. Such a thing is hard to accomplish in a generic sense. You have to have knowledge of your system to make that happen. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
