avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Component <> Object (and never will be).
Date Mon, 11 Feb 2002 19:48:06 GMT
Berin,

>> Berin is putting up a good fight against the changes (as we present 
>> them) being talked about.  Being proposed is JNDI as an alternative. 
>> <footnote>One reason I started EOB was because I wanted a one line 
>> CompMgr style lookup for *anything* and dislike the wieght of JNDI in 
>> its usage</footnote>.  Reading Berin's opinion it seems that 
>> ComponentManager is still the preferred tool for Components and that 
>> if there is something else needed, it is for non-components.
>>
>> Perhaps this is true, and there is no overlap. Perhaps a completely 
>> fresh (not clone) package is required for non-components.  It could 
>> serve the needs of Object lookup and be reusable or reimplementable 
>> by Stephen's CORBA work in Cornerstone, EOB (sourceforge) and Peter's 
>> needs.
>>
>> We could roll in some naming contexts.  I.e. "jndi:",  "phoenix:", 
>> <insert Stephen's needs> <insert Peter's needs>
>
>
>
> My main points have always been that we shouldn't be too hasty just 
> because
> we have a possible solution (out of many).
>
> Notice that I also did not put up a fight without proposing a solution.
> It is true that Object != Component (although the reverse is true). 

My feeling is that although physically Comp is an Obj, it is 
intellectually different, given your case.  As such if we defined an 
Object (rather than Compoent) orientated form of lookup, we should not 
deprecate the ComponentManager as the two are different.  I.e. this is 
not an evolution or a "fix" to an original design, it is different.

> With an ORB, there is another naming and lookup service that is part of
> the CORBA spec--for those, it would be better to handle references 
> through
> that.
>
> I understand the desire, and even need for having one unified way of
> looking up object references--that is simple and elegant, and can differ
> to the heavier JNDI and ORB Naming service.
>
> That is why I proposed the resolver interfaces, to solicit feedback on
> that.  Is this something that will satisfy everyone's need? 

Swap "resolve" for "resolver" method name in Resolverable interface ? 
(better English?)

I think for my needs the Query object is overkill.  99% of the time EOB 
will simply lookup a simple string term : "StockQuoteFacade"

Could we have an additonal design inspired by URLs (http:// rmi:// 
jdbc:// )  Perhaps internally it could be run through a factory to make 
a Query object.  Perhaps that factory is pluggable or chainable.

In EOB, I allow an escape like so "phoenix:web-server" to allow access 
to Jo!  If there is no prefix, then the assumption is that it is an 
internal EOB lookup.  Of course it hosts multiple applications (or 
multiple versions of the same application) so it is important that it 
establishes an application context on the outgoing lookup.  Thus for me 
(hack) it prepends the application name and a dash to the lookup on the 
way to the bean respoitory.  It is, so far, a cheap naming convention 
solution.  Perhaps the impl of the Resolver interface could take a 
setContext(..) method.

Regards,

- Paul H


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message