Paulo Gaspar wrote:
> Hi Berin,
>
>
>
> 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.
Yes, assuming the Token aspect is part of the core. Looking at the
current needs and comments, we would have to retrofit the Token.
Also keep in mind that according to my tests, there is little to be
gained by not releasing certain components as opposed to others.
> I still think there should be a base ObjectManager on top of
> which you could have a ComponentManager or a ServiceManager
> or whatever...
Compiler usually complains when you specialize return methods.
>
>>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/avalon-dev@jakarta.apache.org/msg06057.html
:/ I'm not sold. A simple interface without specific wrappers
are good enough.
>
>
>>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.
The reason I have String, Object is to allow the ability for the
Container to mandate the policy. IOW, In Cocoon, the String is
the role of the component we need, where the Object can be the
Environment object and complex decisions based on the Environment
can be made.
>>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!!!
A Resolver is another name for the ComponentManager/ServiceManager/ObjectManager
that basically has one function. Resolve request X with resource Y. It is
very simple.
In Phoenix, Blocks only need the core Resolver interface, so they don't need
to do anything special. The initialize() method would look like this:
(DataSourceSelector) m_resolver.lookup( DataSourceSelector.ROLE );
In the event we are using it to lookup file resources, we would have something
like this:
(Resource) m_resolver.lookup( "context://my/file.xml" );
If we needed a JNDI, RMI, or CORBA resource, we can lookup our resources like
this:
{JNDIObject) resolver.lookup("jndi://context/JNDIObject");
(RMIObject) resolver.lookup("rmi://rmiresource");
(CORBAObject) resolver.lookup("corba://namingdirectory/object");
The all the keys go to the Container which manages the policies of the "psuedo"
protocols or whatever the lookup policy is. It is a function of the Container
to provide the resources that the children need. One simple interface to allow
that to happen makes the system easier to use.
People are familiar with the concepts of a protocol, and know that they expect
the system to behave in a certain manner when they use that protocol. Granted,
I am perfectly fine with doing away with the concept of protocol.
The whole purpose of using a String is that the Container can be as simple or
as flexible as you need.
Simple component resolution is the core responsibility, although you can lookup
other types of resources.
In cases where you need a specific instance of a Component you use the
QueriableResolver.
QueriableResolver m_resolver;
void setResolver (Resolver resolver)
{
m_resolver = (QueriableResolver)resolver; // policy is system wide
}
void myMethod( Environment e )
{
Transformer defaultTrans = m_resolver.lookup(Transformer.ROLE);
Transformer specificTrans = m_resolver.lookup(Transformer.ROLE, "specific");
Transformer complextTrans = m_resolver.lookup(Transformer.ROLE, e);
}
As you can see the policy is set system wide. You have the flexibility to do
what you need, with an interface that is easy to use. It makes the easy stuff
easy, and the hard stuff possible.
--
"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]>
