Hi Berin,
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 18, 2002 6:16 PM
>
> In the end, we have these requirements (things we currently
> defined as needs)
>
> 1) Ability to test if a resource exists in the Manager
> - Allows conditional lookups without hefty exception handling
> - Usually lighter & quicker than the full lookup method
+1 if I could
> 2) Ability to release resources
> - Some resources are pooled, and the explicit test to see if
> a resource is
> poolable is bad, and a step backwards
> - A standard and uniform approach for all components is
> better than special
> handling for a certain class of components--esp. when the
> policy of whether
> a component is Pooled or not is dependant on the Container
> implementation
> - Switching containers needs to be as painless as possible,
> therefore we cannot
> have different request semantics for a resource.
This is the final bit of my lookup() method:
if (factory.getLifeStyle().mustBeReleased())
{
m_activeComponents.register(factory, i_token, component);
}
return component;
}
I think it is quite generic.
> 3) Ability to retrieve arbitrary resources from one interface
> - We cannot use the term Component or Service because Object
> is too general,
> therfore we use the term Resource
> - By restricting to Component the implementation is too restrictive
+1 if I could.
I still think there should be a base ObjectManager on top of
which you could have a ComponentManager or a ServiceManager
or whatever...
>From a previous post I made to which I noticed no reaction:
> -----Original Message-----
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 14, 2002 2:16 PM
> To: Avalon Developers List; [EMAIL PROTECTED]
> Subject: RE: [VOTE] RE: ComponentManager interface
>
> ...
>
> So, what I want to say is that I consider the problem of
> managing objects-with-a-LifeStyle important enough to deserve
> a separate layer. Then you could have
>
> ObjectManagerImplementation
> |
> ObjectManager
> (interface)
> |
> ComponentManagerWrapper
> |
> ComponentManager
> (interface)
>
> Meaning that you could have a specific implementation of an
> ObjectManager interface which, using a ComponentManager
> wrapper is exposed as a ComponentManager. The wrapper being
> something like the ClassicCM class in
>
> http://www.mail-archive.com/[email protected]/msg06057.html
>
>
> This means that you could easily replace the underlying
> object management implementation with ease and even reuse
> it for a ServiceManager like:
>
> ObjectManagerImplementation
> |
> ObjectManager
> (interface)
> |
> ServiceManagerWrapper
> |
> ServiceManager
> (interface)
>
> ...............
> 4) Ability to retrieve specific instance of a class of resource
> if multiple exist
> - Currently supplied by ComponentSelector interface--but
> semantics are clumsy
> - It would be preferable to merge the ComponentSelector
> select() method in with
> the lookup. In effect, make a Query out of a call.
Actually, me thinks you are talking "indexing strategies"
again/yet.
IMO there are a lot and the world population will never agree
about using just a couple of them.
> My proposed solution (as of right now) to support these NEEDS is this:
>
> Resolver
> {
> Object resolve( String key );
> boolean hasResource( String key );
> }
>
> ReleasableResolver extends Resolver
> {
> void release( Object resource );
> }
>
> QueriableResolver extends Resolver
> {
> Object resolve( String key, Object hint );
> boolean hasResource( String key, Object hint );
> }
>
> QueriableReleasableResolver extends QueriableResolver, ReleasableResolver
> {}
>
>
> This provides a solution where we can have a default interface
> that does not
> support pooled resources to satisfy the simplest needs (aka Peter
> and Stephen's
> needs). We have a version that allows you to release components
> when you may
> have pooled resources. We also have a version that allows you to
> do simple
> or complex queries based on a single key. Lastly we have a version that
> merges the pooled resource and query support.
>
> Unfortunately, while Tokens are a cool idea--they would have to
> be moved to
> a RequestResovler or some instance like that. Alternatively, we can have
> a Token object like I described earlier that you register your resources
> with, and release right away.
>
> Please post your comments.
I still don't "get" your resolvers!
Little sample of a bit of app code using them???
Pleaaaseeee!!!
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
