Answer inline: > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 07, 2002 3:16 PM > > Paulo Gaspar wrote: > > > GREAT! > > > > I am using a lot of Avalon stuff in my Web-apps framework and one > > of the stronger reasons I am using modified Avalon code instead > > of the real thing is just the use of interfaces like those: > > - ThreadSafe; > > - SingleThreaded; > > - Poolable; > > and even > > - Component; > > > > Forcing a component to implement a load of interface markers in > > order to be used in the framework makes it harder to: > > 1. Use 3rd party components with Avalon; > > 2. Having Avalon components used by others. > > > > Because: > > 1. More work wrapping/inheriting from the original component in > > order to integrate it with Avalon; > > 2. Avalon components having more dependencies on other Avalon > > parts. > > > > Actually, the policy of forcing the use of those interfaces makes > > Avalon a bit monolithic. (Hey, before you flame me notice that I > > am saying just "a bit"!!!) > > > 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. 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. This way, using a third party component or pool is trivial. > 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. 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. > > My pool, database connection pool, component manager, cache and > > other generic "component managers" only impose interfaces on > > component factories and similar "per component class" adapters. > > (Hum... I am sure Peter would pick a better vocabulary!) > > > > > > The roles idea is interesting and works very well when we are > > talking about the roles managed by a ComponentManager. BUT it is > > confusing for a newbie to have all those interface defining > > roles, especially when some are just markers. > > > Hopefully you have Components that interact, and therefore provide > an interface. Do not confuse the difference between a Role and a > Lifecycle interface. No Sir. No confusion about that. > 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. 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. > > 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. 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.) Have fun, Paulo Gaspar -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
