You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/06/07 21:26:02 UTC
[Proposal] Avalon 5.0 directory
I would like to create a scratchpad area/version 5.0 proposal area in
Framework. Would we be ammendable to start creating the 5.0 area?
I would like to include the CM we had the latest really long
conversation
about. I think 99% of us are on the same page.
interface ComponentManager
{
/** throws ComponentException */
Object lookup( String role );
/** throws ComponentException */
Object lookup( String role, Object hint );
boolean exists( String role );
boolean exists( String role, Object hint );
}
That way we can have a look at and play with the interfaces until we
like them.
Also, I would like to make as many of the exceptions to be
RuntimeExceptions
as possible. We should take a look at Stefano's concern for exception
throwing.
Version 5 should include the following:
* Clean room implementation--no deprecated methods/classes
* Unified CM/SM (i.e. the interface above)
* Simplified package name
- org.apache.avalon.**** ?
- org.apache.framework.**** ?
* Container abstraction
- Meta data info
- Possible interface to have DefaultComponentManager defer all
lookups to the Container
* Standard for Version info, and how we plan on handling that.
How does this sound to everyone?
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Avalon 5.0 directory
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch wrote:
>
>Version 5 should include the following:
>
>* Clean room implementation--no deprecated methods/classes
>
+1
>
>* Unified CM/SM (i.e. the interface above)
>
+1 on retraction of remove()
Not convinced on the topic concerning changes to the exception model.
>
>* Simplified package name
> - org.apache.avalon.**** ?
> - org.apache.framework.**** ?
>
+1 on a different package name to prevent collisions with 4.9.
>
>* Container abstraction
> - Meta data info
>
+1 on meta-data info in framework.
Somewhere between 0 and -1 on formalization of container in framework
(more discussion on that is needed). My own view is that a container is
implementation and I don't see a requirement for anything structural at
the framework level - as distinct for convinience tools, utilities and
default implementations in Excalibur.
>
> - Possible interface to have DefaultComponentManager defer all
> lookups to the Container
>
Don't like the sound of this bacause it will force the introduction of a
container defintion into the framework and I don't thing that's a good
thing to be doing.
>
>* Standard for Version info,
>
+1 assuming we are talking about for formal usage and association of the
org.apache.avalon.framework.Version class with a component.
>and how we plan on handling that.
>
on another thread.
>
>How does this sound to everyone?
>
So far so good.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Avalon 5.0 directory
Posted by Peter Royal <pr...@apache.org>.
On Friday 07 June 2002 03:26 pm, Berin Loritsch wrote:
> I would like to create a scratchpad area/version 5.0 proposal area in
> Framework. Would we be ammendable to start creating the 5.0 area?
+1
> Also, I would like to make as many of the exceptions to be
> RuntimeExceptions
> as possible. We should take a look at Stefano's concern for exception
> throwing.
We should look at each on a case-by-case basis. I have no gripes about the
exceptions thrown by framework.
> * Clean room implementation--no deprecated methods/classes
+1
> * Unified CM/SM (i.e. the interface above)
+1
> * Simplified package name
> - org.apache.avalon.**** ?
> - org.apache.framework.**** ?
+1
> * Container abstraction
> - Meta data info
+1
> - Possible interface to have DefaultComponentManager defer all
> lookups to the Container
IMHO container implementations belong in Excalibur or other projects. -0
> * Standard for Version info, and how we plan on handling that.
+1
> How does this sound to everyone?
A good kick-start :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Avalon 5.0 directory
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Leo Simons" <le...@apache.org>
> > I would like to create a scratchpad area/version 5.0 proposal area in
> > Framework. Would we be ammendable to start creating the 5.0 area?
>
> 'course.
+1
> > I would like to include the CM we had the latest really long
> > conversation
> > about. I think 99% of us are on the same page.
> >
> > interface ComponentManager
> > {
> > /** throws ComponentException */
> > Object lookup( String role );
> >
> > /** throws ComponentException */
> > Object lookup( String role, Object hint );
> >
> > boolean exists( String role );
> > boolean exists( String role, Object hint );
> > }
>
> nah. I still don't get why we need to use RuntimeExceptions. Also, I
> can't see why we would have roles be strings, and then hints be objects.
> It is either string or object, imo.
+1
Consistency is important, since they have a similar meaning
role
subrole=role flavor=hint
> object vs string
> ================
> The case you made for object is basically that it will bring higher
> perfomance because 'stupid' users will do less expensive string creation
> and the CM implementation can be optimized because it is no longer
> neccessary to have a hash with strings as keys.
Premature optimization is the root of all evil.
Well, allmost ;-)
> However, using objects can also mean creation of objects even more
> expensive than strings (when you talk about 'stupid' users...), and the
> hash will not be quicker. The real optimization would lie in using
> primitives or their object counterparts (Long).
;-)
> When we consider the added value of strings (easy for humans to read),
> it seems hint should be a string.
Going down the real object road, it would have to be a type of object,
something like "Role".
This will hide the implementation.
Of course, making Role have a getRoleAsString() would be plain stupid, since
it would just shift the problem.
> RuntimeException vs declared Exception vs no exception
> ======================================================
> The reason for using RuntimeExceptions instead of declared exceptions.
> is that it saves the component writer a try/catch/finally block. The
> disadvantage is that it is perfectly valid for lookup() to fail.
>
> When the only reason for lookup() to fail is nonexistence of a requested
> component, requiring a call of exists() before a lookup() removes the
> need for a declared exception, or even a RuntimeException.
>
> If we are sure that the only possible failure is a nonexistent component
> then no exception at all is necessary if calling exists() is mandatory.
>
> Is this true? I think so.
For lookups, generally yes.
> > Also, I would like to make as many of the exceptions to be
> > RuntimeExceptions
> > as possible. We should take a look at Stefano's concern for exception
> > throwing.
>
> some thoughts:
>
> if a method call may fail, this should be indicated to the caller using
> the language mechanism to indicate failure. In java, the way to do this
> is by using the exception handling mechanism.
>
> The problem raised by Stefano is that the exception handling mechanism
> is not very performant as it requires the JVM to track state
> information.
Premature optimization... bla bla bla
> Is this problem large enough to warrant not using the java exception
> handling mechanism as intended? I think the answer to that question
> answers whether this is a good idea.
Terrible idea.
When I call a method of the lifecycle, I give an order.
Since I assume that all that is to be done is execute that order, if he
fails, the order is not carried out.
I just need to know if it went through or not.
BBBZZZZZ... Wrong!
Anything can happen when the order is executed.
I repeat *anything*.
When an exception occurs, who will manage it?
Who is responsible?
The caller. -Always-
How can the caller be held responsible for it?
Catching the Exception.
> I have never written an application where any of the avalon framework
> methods had any kind of negative impact on performance. Until there is
> some actual perfomance data that makes clear the use of exceptions is a
> performance problem, I think we should keep the exception throwing.
>
> Note that the lifecycle methods throwing exceptions does not mean more
> work for the component developer as the only thing that ever calls those
> methods is the container.
That can decide to rethrow it or handle it by other means.
But it needs to be held responsible.
> > Version 5 should include the following:
> >
> > * Clean room implementation--no deprecated methods/classes
>
> +1
+1
> > * Unified CM/SM (i.e. the interface above)
>
> +1, though not for that interface.
idem
> > * Simplified package name
> > - org.apache.avalon.**** ?
> > - org.apache.framework.**** ?
>
> +1. Some people will not like it if we use org.apache.framework (as
> raised by -- I think -- Jason a few weeks ago).
On James they had the opposite reaction.
They say that they don't want Avalon interfaces in the new Mailet API.
It just seems that org.apache.framework would keep them calm... go figure
:-S
> > * Container abstraction
> > - Meta data info
>
> +1 if stable. Not a requirement -- this has no impact on the rest of the
> framework so it can always be added in later as well.
+1
> > - Possible interface to have DefaultComponentManager defer all
> > lookups to the Container
>
> ??
>
> Like Stephen, I wonder whether defining a Container interface is a good
> idea. Don't really see the need. Please elaborate?
I think that having a DefaultXXX class is bad.
We should have only interfaces and factories in framework.
> > * Standard for Version info, and how we plan on handling that.
>
> yup. This is related to the meta-info stuff though.
+1
> > How does this sound to everyone?
>
> generally cool, though I think you make some assumptions about
> agreements that I'm not sure exist. Each and every one of these bullets
> needs a separate thread, discussion and vote.
+1
> Also, framework as it currently stands is pretty cool; there's no need
> for revolutions; evolution is cool. We probably all agree, just wanted
> to say that.
I think it's really important you remind this.
Remember guys, that if we make a revolution, we are going to loose our
users.
Definately.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Avalon 5.0 directory
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
>
> RuntimeException vs declared Exception vs no exception
> ======================================================
> The reason for using RuntimeExceptions instead of declared
> exceptions. is that it saves the component writer a
> try/catch/finally block. The disadvantage is that it is
> perfectly valid for lookup() to fail.
>
> When the only reason for lookup() to fail is nonexistence of
> a requested component, requiring a call of exists() before a
> lookup() removes the need for a declared exception, or even a
> RuntimeException.
>
> If we are sure that the only possible failure is a
> nonexistent component then no exception at all is necessary
> if calling exists() is mandatory.
>
> Is this true? I think so.
I would be for just removing the exception altogether.
> > - Possible interface to have DefaultComponentManager defer all
> > lookups to the Container
>
> ??
>
> Like Stephen, I wonder whether defining a Container interface
> is a good idea. Don't really see the need. Please elaborate?
All I am talking about is something like this:
interface Container
{
Object getComponent(String name, String/*Object*/ hint);
}
The DefaultComponentManager would call the Container that was
passed in the constructor and that in turn would call the
getComponent(name, null) for default or getComponent(name,hint)
for more specific.
Kind of the way Fortress works--but more formally state it that
way.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Avalon 5.0 directory
Posted by Leo Simons <le...@apache.org>.
> I would like to create a scratchpad area/version 5.0 proposal area in
> Framework. Would we be ammendable to start creating the 5.0 area?
'course.
> I would like to include the CM we had the latest really long
> conversation
> about. I think 99% of us are on the same page.
>
> interface ComponentManager
> {
> /** throws ComponentException */
> Object lookup( String role );
>
> /** throws ComponentException */
> Object lookup( String role, Object hint );
>
> boolean exists( String role );
> boolean exists( String role, Object hint );
> }
nah. I still don't get why we need to use RuntimeExceptions. Also, I
can't see why we would have roles be strings, and then hints be objects.
It is either string or object, imo.
object vs string
================
The case you made for object is basically that it will bring higher
perfomance because 'stupid' users will do less expensive string creation
and the CM implementation can be optimized because it is no longer
neccessary to have a hash with strings as keys.
However, using objects can also mean creation of objects even more
expensive than strings (when you talk about 'stupid' users...), and the
hash will not be quicker. The real optimization would lie in using
primitives or their object counterparts (Long).
When we consider the added value of strings (easy for humans to read),
it seems hint should be a string.
RuntimeException vs declared Exception vs no exception
======================================================
The reason for using RuntimeExceptions instead of declared exceptions.
is that it saves the component writer a try/catch/finally block. The
disadvantage is that it is perfectly valid for lookup() to fail.
When the only reason for lookup() to fail is nonexistence of a requested
component, requiring a call of exists() before a lookup() removes the
need for a declared exception, or even a RuntimeException.
If we are sure that the only possible failure is a nonexistent component
then no exception at all is necessary if calling exists() is mandatory.
Is this true? I think so.
> Also, I would like to make as many of the exceptions to be
> RuntimeExceptions
> as possible. We should take a look at Stefano's concern for exception
> throwing.
some thoughts:
if a method call may fail, this should be indicated to the caller using
the language mechanism to indicate failure. In java, the way to do this
is by using the exception handling mechanism.
The problem raised by Stefano is that the exception handling mechanism
is not very performant as it requires the JVM to track state
information.
Is this problem large enough to warrant not using the java exception
handling mechanism as intended? I think the answer to that question
answers whether this is a good idea.
I have never written an application where any of the avalon framework
methods had any kind of negative impact on performance. Until there is
some actual perfomance data that makes clear the use of exceptions is a
performance problem, I think we should keep the exception throwing.
Note that the lifecycle methods throwing exceptions does not mean more
work for the component developer as the only thing that ever calls those
methods is the container.
> Version 5 should include the following:
>
> * Clean room implementation--no deprecated methods/classes
+1
> * Unified CM/SM (i.e. the interface above)
+1, though not for that interface.
> * Simplified package name
> - org.apache.avalon.**** ?
> - org.apache.framework.**** ?
+1. Some people will not like it if we use org.apache.framework (as
raised by -- I think -- Jason a few weeks ago).
> * Container abstraction
> - Meta data info
+1 if stable. Not a requirement -- this has no impact on the rest of the
framework so it can always be added in later as well.
> - Possible interface to have DefaultComponentManager defer all
> lookups to the Container
??
Like Stephen, I wonder whether defining a Container interface is a good
idea. Don't really see the need. Please elaborate?
> * Standard for Version info, and how we plan on handling that.
yup. This is related to the meta-info stuff though.
> How does this sound to everyone?
generally cool, though I think you make some assumptions about
agreements that I'm not sure exist. Each and every one of these bullets
needs a separate thread, discussion and vote.
Also, framework as it currently stands is pretty cool; there's no need
for revolutions; evolution is cool. We probably all agree, just wanted
to say that.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Avalon 5.0 directory
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> >What do you see as being better?
>
> Simple string lookup - no hints or any second parameter -
> like all the other directy apis except simpler.
But how do you solve the problem that the ComponentSelectors
attempted to solve? That is, being able to select a component
based on request parameters?
As I understand it, what you call the Assembler does all the
wiring at application startup.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Avalon 5.0 directory
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Simple string lookup - no hints or any second parameter - like all the
> other directy apis except simpler.
Hi Peter,
I think you are just trading a complication for a bigger one.
When people need a component key / "hint" with multiple values of multiple
types, a bean is a perfectly simple and intuitive way of representing it.
But if you want to map such values into text, there you are with the
additional complication of defining a mapping scheme, data formats and
even escape sequences.
And then, of course, your app needs to format such key just to parse it
back again somewhere inside de CM. I really dislike that.
=:o/
I would rather prefer no hint and an Object key, but we already went
trough such discussion before. String key and Object hint sounds much
better to me.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Monday, June 10, 2002 8:07 AM
>
>
> 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 ...
>
> Why is it needed?
>
> 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.
>
> 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.
>
> 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).
>
>
> >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.
>
> >What do you see as being better?
>
> Simple string lookup - no hints or any second parameter - like all the
> other directy apis except simpler.
>
>
> Cheers,
>
> Peter Donald
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
> - John Kenneth Galbraith
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Avalon 5.0 directory
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Peter Donald [mailto:peter@apache.org]
>>
>>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.
I second Berin.
One thing is a Role, another is a Flavor-Hint.
One is WHAT, the other is HOW.
"How" is less important than "what", as long as it gets done.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Avalon 5.0 directory
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Avalon 5.0 directory
Posted by Peter Donald <pe...@apache.org>.
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 ...
Why is it needed?
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.
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.
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).
>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.
>What do you see as being better?
Simple string lookup - no hints or any second parameter - like all the
other directy apis except simpler.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Avalon 5.0 directory
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> At 03:26 PM 6/7/2002 -0400, you wrote:
> >I would like to create a scratchpad area/version 5.0
> proposal area in
> >Framework. Would we be ammendable to start creating the 5.0 area?
> >
> >I would like to include the CM we had the latest really long
> >conversation about. I think 99% of us are on the same page.
> >
> >interface ComponentManager
> >{
> > /** throws ComponentException */
> > Object lookup( String role );
> >
> > /** throws ComponentException */
> > Object lookup( String role, Object hint );
> >
> > boolean exists( String role );
> > boolean exists( String role, Object hint );
> >}
> >
> >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?
I think it is much more elegant than even your
ConnectionManager.ROLE + "/SSL"
I would like to see a simple lookup that does this:
lookup(ConnectionManager.ROLE, "SSL");
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.
What do you see as being better?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Avalon 5.0 directory
Posted by Peter Donald <pe...@apache.org>.
At 03:26 PM 6/7/2002 -0400, you wrote:
>I would like to create a scratchpad area/version 5.0 proposal area in
>Framework. Would we be ammendable to start creating the 5.0 area?
>
>I would like to include the CM we had the latest really long
>conversation
>about. I think 99% of us are on the same page.
>
>interface ComponentManager
>{
> /** throws ComponentException */
> Object lookup( String role );
>
> /** throws ComponentException */
> Object lookup( String role, Object hint );
>
> boolean exists( String role );
> boolean exists( String role, Object hint );
>}
>
>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
>Also, I would like to make as many of the exceptions to be
>RuntimeExceptions
Why is that? The only thing that should catch such exception are the
Container and I don't have any problem with extra few keystrokes required
for type safety.
>* Clean room implementation--no deprecated methods/classes
+1
>* Unified CM/SM (i.e. the interface above)
+1 for unified SM but it wont be the one above ;)
>* Simplified package name
> - org.apache.avalon.**** ?
> - org.apache.framework.**** ?
+1 Something like that ;)
>* Container abstraction
> - Meta data info
> - Possible interface to have DefaultComponentManager defer all
> lookups to the Container
Depends on how far along it comes. It is not proven yet so we can keep it
into excalibur until it is
>* Standard for Version info, and how we plan on handling that.
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>