> From: Leo Simons [mailto:[EMAIL PROTECTED]]
>
> > > > However, for most people it is just quicker to do this:
> > > >
> > > > manager.lookup (Generator.ROLE + "/fooo");
> > >
> > > make sure you tell everyone you can influence not to! We
> > > really need that "best practices" stuff =)
> >
> > It gets tiring. Why not just not make it possible?
>
> why, to improve the world, of course!
>
> > Rewritten because all Requests were handled in the compose() method:
>
> here it is: a-hah! Make it a contract that Request can only
> ever be created during compose() (pre-init()) and there you
> go: no more misuse.
But then you can not create a Request based on (for example) the
incoming
HTTP request (as in Cocoon). Unless you prepopulate a HashMap or
something
with all possible requests.
I'm all for Berin's query object approach - the only thing lacking is
the
neatness of a
lookup( ISeeExactlyWhatInterfaceImGetting.ROLE );
I do not consider going from:
MyComponent myComponent = null;
try {
myComponent = (MyComponent) manager.lookup (MyComponent.ROLE);
// Do stuff that may throw Exception (which is the typical case in
my experience)
} catch (ComponentException ce) {
// Ugh.
} catch (Exception e) {
// Ugh.
} finally {
manager.release (myComponent);
}
to:
MyComponent myComponent = manager.lookup (myComponentRequest);
try {
// Do stuff that may throw exceptions (which is the typical case in
my experience)
} catch (Exception ce) {
// Awwww...
} finally {
manager.release (myComponent);
}
a killer feature, but getting those ComponentSelectors out of my code
makes it worth
the extra instance variable and stuff.
What I do consider a
--~~==��**++:::::>>> KILLER FEATURE <<<:::::++**��==~~--
would be the incorporation of Peter's Phoenix
<component ...>
<provide .../>
</component>
way of linking components as described here:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102266947408779&w=2
into Fortress. Remember, in the ComponentManager spec., a component
should *only* be given those components it needs to work, not any other!
Having <provide/> would not only enable that, but also solve the initial
problem:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102260094419459&w=2
Component A requires a component with role B. For example, a
QueryEngine
requires a DBConnectionPool.
Now, we add component C that also requires a component with role B.
Like, a Logger requires a DBConnectionPool to log into a database.
Stuffing A and C into the same Container so that they get the same
CM
makes it necessary to have them either use the same implmentation of
B
or use a ComponentSelector. But then they have to be written to use
a
CS.
which was described in a different way by Marc Scheier here:
http://marc.theaimsgroup.com/?l=avalon-dev&m=102312257108468&w=2
(Killer Feature End)
As for the directory-should-not-do-pooling: If I put a DataSource in the
directory, I do:
Connection conn = ((DataSource) manager.lookup
(DataSource.ROLE)).getConnection ();
Now since I'll always want the connection, why not just give me the
connection
right away?
Connection conn = (Connection) manager.lookup (Connection.ROLE);
I do not see the scalability problem here. With the DataSource approach
I just see
it as not quite as clear when reading the code just what is happening.
The lookup
should, IMO, be for "what I want to use" not "what I want in order to
get what I
want to use". (This is my problem with exposing the ComponentSelector
interface -
I want the component, and I want it in *one* lookup. Not some two-stage
process.)
A few notes on scalability - with the BucketMap the thread conflicts
inside the
container are basically eliminated. Any threading issues will then be in
the pooling
code - making access via DataSource (which must have a pool) as
efficient as access
through a PoolableComponentHandler or equivalent (which has a pool).
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
