> From: Peter Donald [mailto:[EMAIL PROTECTED]]
>
> At 01:10 AM 6/10/2002 -0400, you wrote:
> > > >That way we can have a look at and play with the
> interfaces until
> > > >we like them.
> > >
> > >
> > > Dont like the idea of hints and especially hate the idea
> that hints
> > > be objects
> >
> >Pete, what's wrong with this?
>
> Do I have to say it again? ;) Okay lets try it another way ...
Yes you do.
> Why is it needed?
Let me remind you that you need it as well. Let's say we are
implementing an HTTP server. The HTTP server needs to set up
both SSL enabled and non SSL enabled connections. You can't
cleanly expect to be able to do this:
ConnectionManager regular =
(ConnectionManager)m_manager.lookup(ConnectionManager.ROLE);
ConnectionManager ssl =
(ConnectionManager)m_manager.lookup(ConnectionManager.ROLE);
It's just plain ludicrous to be able to keep track of requests
for a component and then return different instances for each one.
You know it and I know it.
Now, to get around that, you happen to use ROLE + "/extention".
What is the difference between this:
ConnectionManager ssl = (ConnectionManager)
m_manager.lookup(ConnectionManager.ROLE + "/SSL");
and this:
ConnectionManager ssl = (ConnectionManager)
m_manager.lookup(ConnectionManager.ROLE, "SSL");
?
It makes it a lot cleaner to have "ROLE, EXTENTION" than
it is to do "ROLE + '/EXTENTION'". It is more semantically
clear.
> Lets assume component A requires the GreasyBurger service.
> There is two
> types of GreasyBurder service "McChucks" and "GooberBurger".
>
> When A looks up the service it does not care that there are two
> varitys/hints it just cares about the one that it has been
> assigned BY THE
> ASSEMBLER. So it does not need to worry about hints or
> anything like that.
And that does not describe the need well. Of course not. It is
your contrived example.
> So what type of component will use the hints? Any component
> that has to
> access multiple different types of same service. Component B
> is one such
> service - it uses one burger at breakfast and one at
> lunchtime. So it uses
> the hint "lunchtime" to access lunchtime GreasyBurger
> instance. Note it is
> UP TO THE ASSEMBLER to wire the correct components in. The
> ASSEMBLER could
> quite easily wire the McChucks in as breakfast or lunchtime
> with equal ease.
It could.
> So why did the notion of hints ever infect the framework? It
> was introduced
> because people wanted a global namespace (erk) as they were
> treating the
> ComponentManager as a container (erk erk) and they wanted to have the
> component develoeprs mix concerns with assembler (erk erk erk).
Bringing it back to the stage where the design was origianally
conseived, actors have understudies. Those understudies can
replace the actor any time the director desires.
A hint is not a hard and fast contract. All it accomplishes
is "If I have any influence at all, I would prefer to have
XYZ". It does not force the container to reply in kind.
> >It is more clear to the user that what we are trying to get. It
> >follows a standard that is used to obtain i18n, JSSE, JCE, etc.
> >objects. You have the default no-arg lookup, and then one
> to fine tune
> >it.
>
> You cite that you want the ComponentManager to be a
> ServiceDirectory yet
> you site examples of ResourceManagers and Factorys as why you
> should have a
> feature. Can you site a ServiceDirectory that has similar
> features. As far
> as I am aware none of JNDI, LDAP, ActiveDirectory, NDIS, DNS
> or any other
> directory service that I know of has any such notion of hints.
They have notions of directories and subdirectories which we
don't. Would you rather go down that path and add complexity
to an otherwise simple lookup service?
What's the difference between:
context.lookup("java:/comp/ConnectionManager/ssl")
and
manager.lookup(ConnectionManager.ROLE, "SSL");
Don't forget that JNDI has a lot more other tricks up its sleeve.
It can have a lot more information bound to a particular location
with its attributes features. DO you want to replecate that?
> >What do you see as being better?
>
> Simple string lookup - no hints or any second parameter -
> like all the
> other directy apis except simpler.
And I really don't like the String. It forces bad performance
and weak contracts. I am trying to have something with good
contracts. All my attempts to try something other than a
String lookup--while plausible and decent proposals--have been
shot down because you want _String_ lookups.
I am sticking to my guns on this one. It is semantically
cleaner to enforce ROLE matching, with an option for hints.
If you don't want hints, then your container can ignore hints.
If I want hints, then I need the mechanism available to me.
We do a lot of things differently than JNDI, ActiveDirectory,
and the other directory services. Why should we stick to their
limitation on this point?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
