Hi again, answer inline: > -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 9:56 PM > > ... > > However if you recall back to our original discussions on > ComponentManager vs > ComponentSelector vs NamedComponentManager. I didn't really like > NamedComponentManager or ComponentSelector and tried to stop it > but gave up - > it was 3 vs 1 and even I get bored of arguing ... well on very > rare occasions > ;)
I also see no need for the ComponentSelector as a main component interface. I think it is even a bit confusing. It should just be an "implementation detail". I also like much more the idea of having _some_ unique key that we probably should avoid calling Role. Maybe it should even be just an java.lang.Object key. Hey, it is not so weird: the Context also has an Object key and after being quite skeptical about that I ended up learning it is the best way... not to talk about java.util.Map!!! > Personally I used to think hierarchical ComponentManagers was the > go ... but I think your Query object is another interesting idea. Hierarchical is interesting but than you get a bit lost at times just like with JNDI. It is better if one is not pushed in that direction but can still go there, as it happens with the Query solution. > > The issue is that we need to figure out what to do to handle > n-dimensional > > lookup. Is the Query Object idea worth persuing? > > Persue = yes, put in framework imediately = no. I think it is a > good idea to > look at this and it matches somethings found in some service > directories. For > instance it is similar to JMX where the "name" is essentially > made up by a > listing of attributes - so their lookup strings look like > > MyDomain:role=com.biz.Foo,type=DefaultFoo,capacity=3,... > > And you can search for services based on their attributes. Very directory service like. Looks like LDAP. =:o) > > BTW, Such a fundamental change might require a 5.0 path for Framework. > > That would allow us to clean some other stuff up in the mean time. > > Definetly. Other things work looking at > > * remove all deprecated stuff > * reconsider removing Component interface YESSSssss!!! > * reconsider not having Initializable/Disposable in separate interfaces Great! > * consider adding a base class that implements all the activity interfaces I have one, with checks and all!!! (Ok, you probably have 2 or 3!) > * consider removing ThreadSafe and friends Yesss!!!! > * consider adding a Level object to logger and extra methods > > log( Level, message ) > log( Level, message, exception ) Argh! I used to believe on that one and then went the Avalon way. I find the interface much cleaner. Which experience makes you change your mind on this one? > I already have a fork that does this. Cool! I am curious! > However it may be a good idea to change package names so I can continue > relying on Framework4.0 until next version is ready. Perhaps > something like > > org.apache.framework > org.apache.avalon.framework2 > > or similar > > -- > Cheers, > > Pete Have fun, Paulo Gaspar http://www.krankikom.de http://www.ruhronline.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
