What if the marking of single-theaded, poolable was all done in the configuration? For example
<component-instance class="ThreadSafeClass" role="role1" thread-safe="true"/> <component-instance class="PoolableClass" role="role2" thread-safe="false" poolable="true"/> Then we don't have to worry about the ThreadSafe/Poolable marker interfaces. The component manager would handle it all for us when it read in the configuration. Maybe the RoleManager could also read in this information from the roles.conf (though this would require changing the RoleManager interface to return more than just the component class name for a role, e.g. ComponentDescriptor) Regards, --mike On Mon, 7 Jan 2002, Berin Loritsch wrote: > Paulo Gaspar wrote: > > > Answer inline: > > > > >>Can I ask a couple questions? How do you propose to handle the difference > >>between a Component that is ThreadSafe (i.e. can be used simultaneously > >>by multiple clients) and one that is SingleThreaded (i.e. must have a > >>unique instance for each client)? > >> > > > > What I do in my framework is to ALWAYS have a factory which takes care of > > reading and holding the component configuration, creating it, initializing, > > disposing, etc. It works a bit like a component factory for a pool. > > > Which is exactly what ExcaliburComponentManager does. There are necessary > improvements, but they will come. > > > > That factory only implements enough functionality to "make the bridge" > > between the framework and the specifics of each component and the factory > > interface has a function to describe what is the component's lifestyle. > > > > Another object takes care of managing the components depending on that > > lifestyle (I do not rely on the factory for that, of course). > > > > > > > >>They do have purpose. If all you deal with are ThreadSafe Components, > >>then the DefaultComponentManager would be enough for you. Unfortunately, > >>not all projects have that luxury. Creating a new instance for every > >>client is wasteful and causes more work for the server than is necessary. > >> > > > > I understand that. > > > > At the moment, the only components I use that are not ThreadSafe are those > > that are pooled - like database Connections - and some special cases that > > do not match Avalon current scope (like sql queries and other stuff > > specific to my framework). > > > > I do NOT, however, mark (trough their factory) those components as > > Poolable. I just mark them as SingleThreaded and hide the specifics of the > > pool behind the component factory. > > > Which was the point of this thread. > > > > > > This way, using a third party component or pool is trivial. > > > True. > > > > >>The next question is why make everything more "bean" like. JavaBeans, > >>while usable, do have a distinct disadvantage in that they are not > >>clearly marked. > >> > > > > I do not see much use for most pure (no methods) markers. I ended up > > deleting them some 3 months ago and I do not miss them a bit. > > > The Idea of a Component being marked explicitly as a Component does > have some value to me. It forces you to think in terms of what a Component > is supposed to do. That way you don't run into the JavaBeans antipattern > of everything (data objects included) being a Bean. You encapsulate > data accessor logic apart from the data itself. It is not a correct > pattern to implement Data as a Component. > > > > > > Of course that for many objects (including the above mentioned > > Component factories) I do use interfaces like: > > Initializable > > Disposable > > Startable > > Contextualizable > > Configurable > > Loggable (like your LogEnabled) > > etc. > > > That's good. I'd hate to see it all merged together into one large > monolithic interface. That way you only use what you need. > > > > >>A Role defines the logical use of the Component in the system. If > >>the Role interface extends the Component interface, all the hard > >>work is done for you and you don't have to recast the Component > >>to release it. > >> > > > > I understand and I do not have to recast any component since my > > component manager returns Object instead of Component. > > > And if your Role interface extends Component, you have the same > convenience--while maintaining the protection that forces you to > separate data and the interface to get the data. > > > > > Since I focus on building components that are as independent from > > the framework as possible (which makes them more reusable) I always > > use a component factory. Even if only to take care of configuration. > > > That's fine. I just would have a hard time with a ComponentManager > that is really simply an ObjectManager. That would be bad. > > > > >>>If you change this one I will only miss having an easy to use > >>>component manager that can manage several components for the same > >>>role (naming them). If one day you want to do this one, I would > >>>like to contribute. > >>> > >> > >>We had explored this in the past. We had big, very impassioned > >>discussions. The result of that is the ComponentSelector interface. > >>You use a ComponentManager to get the ComponentSelector for a role > >>that will have many implementations. The ComponentSelector will > >>select your exact implementation of the Role based on an arbitrary > >>Object as a hint (the most common being a string name). > >> > > > > I also understand that. I tried to use that mechanism as it is but, > > in the end, I found it simpler to change it since my needs are quite > > different. > > > > I know the Avalon Framework (and some other bits) quite well (at > > least last Summer's version) since it was my starting code base for > > the component management and other parts of my framework and I > > rewrote or rearranged most of it to suite my needs. > > > > I am only focusing on the parts of what I have that can be done in > > Avalon since what I have is quite a bit different. > > > How much so? > > > > > To give you a slight idea, I am building something like Cocoon with > > much less XML and I use my standard ComponentManager to build a kind > > of SiteMap. (Obviously I also studied quite a bit of Cocoon.) > > > And this forces differences how? > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
