Leo Simons wrote: > > a few observations: > > - we have a DB > - we have an FTP server > - we have an event driven server architecture in the works > - we have something called overlord and I can't really figure > out what it does > - we no longer like Poolables for some reason? > - we no longer like ComponentManager/Selector??
More specifically we don't like "Component" as a type constraint on a method parameter. > - phoenix is working pretty well, the thing it really needs now > being better management options Yep!!!! > ------ > I've been reading the archives on the ServiceManager discussion, > but am quite failing to follow it all. What is the problem, what > is the solution, do we agree on that yet and what will be the > migration path? The ComponentManager problem: The ComponentManager family of interfaces use Component as a type that constrains objects that are supplied to be derived from the Component maker interface. This artefact meant that many "components" (note the lowercase usage) found in the real world (e.g. CORBA service, components, applications, AltRMI, etc.) had to be wrapped within something implementing Component. The issues raised in the process: Several proposal were made towards solutions which resulted in deeper discussions about the semantics of component management and pooling. The subject of the addition of a token argument on the lookup and related operations was raised, chewed over, and eventually dropped as too-hard now given the concurrent discussion on the semantics of the XxxxManager release operation. The "release" operation caused a lot of discussion because there we some that felt that the manager should always be notified of the release of an object acquired through lookup, and others that felt that the client should be explicitly aware of release obligations. This discussion did not reach a conclusion. The result: A proposal for ServiceMangager that basically paralleled the ComponentManager was agreed to is now in the framework service package. Some of us are already using Serviceable in anger in our own projects and it has also been picked up in a least two outside projects since inclusion in the framework. > I read up on SEDA, and really like it. Berin, you encountered > problems with implementing it? > > Finally, I think Paul and Pete have been looking at all the > management stuff. Is there any work still going on atm? Where > are we at? Waiting for your return ? > good to be back :-) Good to have you back! Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
