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/13 17:09:04 UTC
RE: [VOTE] (recap) New name for Version 5 ComponentManager
So far here are the votes:
3 ComponentDirectory
4 ComponentLocator/ServiceLocator
1 ComponentLookup (writein from Nicola Ken Barrozi)
1 ComponentResolver (writein from Marcus Crafter)
Breakdown even further:
ComponentDirectory
------------------
Marcus Crafter
Berin Loritsch
Leo Simmons
XXXXLocator
-----------
Leo Sutic
Gonzalo A. Diethelm
Stephen McConnel
Stephen Haberman
Now I realize that at least one or two of these is not
a committer, but since they are users/potential users
their oppinions should be used to come to a decision.
After I read Leo's link to the J2EE patterns page, I
really like the idea of "ServiceLocator" as the name.
I like the quote from Stephen Haberman:
"I agree; I'm very new to Avalon, but given my naïve
impression of what the component is supposed to do,
I like XXXLocator better also. As a newbie, I can
understand the concept quicker than with the
XXXDirectory."
Between Leo's page and Stephen's quote, I would like
to change my vote (yes I can be swayed :) ) to
"ServiceLocator"
That would make (on official voting):
ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
ComponentDirectory: 2 (Leo Simmons, MarcusCrafter)
And the two write-ins.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Peter Royal <pr...@apache.org>.
On Thursday 13 June 2002 11:09 am, Berin Loritsch wrote:
> 4 ComponentLocator/ServiceLocator
+1
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Peter Donald <pe...@apache.org>.
At 05:40 PM 6/13/2002 +0200, you wrote:
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
>
>Can someone to a newbie check on "You get your *Components* from
>the *Service*Locator"?
>
>I was against ServiceLocator not because I didn't see Components
>as being/providing a service, but if we are talking about
>Components, then we should apply that name throughout.
>
>I really dislike the shift in terminology we have here...
For all practical purposes
Component Orientated Programming == Service Orientated Programming
The distinction between the two being that in SOP you are usually required
to explicitly define the interface of communication between components. In
Avalon we enforce this in most cases (at least Phoenix and ECM enforce it -
not sure about other containers).
So there is little difference I think.
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: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Torsten Curdt <tc...@dff.st>.
On Thursday 13 June 2002 17:09, Berin Loritsch wrote:
> So far here are the votes:
>
> 3 ComponentDirectory
> 4 ComponentLocator/ServiceLocator
> 1 ComponentLookup (writein from Nicola Ken Barrozi)
> 1 ComponentResolver (writein from Marcus Crafter)
>
> Breakdown even further:
>
> ComponentDirectory
> ------------------
> Marcus Crafter
> Berin Loritsch
> Leo Simmons
>
> XXXXLocator
> -----------
> Leo Sutic
> Gonzalo A. Diethelm
> Stephen McConnel
> Stephen Haberman
>
>
> Now I realize that at least one or two of these is not
> a committer, but since they are users/potential users
> their oppinions should be used to come to a decision.
>
> After I read Leo's link to the J2EE patterns page, I
> really like the idea of "ServiceLocator" as the name.
>
> I like the quote from Stephen Haberman:
>
> "I agree; I'm very new to Avalon, but given my naïve
> impression of what the component is supposed to do,
> I like XXXLocator better also. As a newbie, I can
> understand the concept quicker than with the
> XXXDirectory."
>
> Between Leo's page and Stephen's quote, I would like
> to change my vote (yes I can be swayed :) ) to
> "ServiceLocator"
>
> That would make (on official voting):
>
> ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
> ComponentDirectory: 2 (Leo Simmons, MarcusCrafter)
>
> And the two write-ins.
add another write-in from a non-committer:
I also prefer "resolver" over "locator" in respect of the "SourceResolver".
And I also think it's pretty straight forward that a
Component(Resolver/Locator) returns a Component
while a
Service(Resolver/Locator) returns a Service (whether a Service is a Component
or not)
my 2 cents from Avalon user-land ;-)
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>>I like the quote from Stephen Haberman:
>>
>>"I agree; I'm very new to Avalon, but given my naïve
>> impression of what the component is supposed to do,
>> I like XXXLocator better also. As a newbie, I can
>> understand the concept quicker than with the
>> XXXDirectory."
>>
>>
>
>This is very important (I will know its meaning anyway =). I'd like to
>get input from other users.
>
>
>
>>That would make (on official voting):
>>
>>ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
>>ComponentDirectory: 2 (Leo Simmons, MarcusCrafter)
>>
>>
>
>I'm okay with ComponentXXXX (within some limits). I don't think it is
>smart to start using the word "service"...it might look good in
>management meetings ("so, does it support Web Services?"), but it is
>blurry.
>
>I'll even give you a -1 on that if neccessary :P. We do COP here, not
>SOP. Or are we changing that too?
>
>
I think Berlin meant the ComponentLocator/ServiceLocator pair. A CL for
Avalon 4.1 could be introduced providing it maintained the Component return
value. An equivalent SL could be added to the framework service package.
In both cases XxxxxLocator would be the base type for XxxxManager.
In A5 the service package would presumable dissapear because the
differences would would have been folded into a new component package
name. The result A5 component package would not container a CM.
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: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> > That would make (on official voting):
> >
> > ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
> > ComponentDirectory: 2 (Leo Simmons, MarcusCrafter)
>
> I'm okay with ComponentXXXX (within some limits). I don't
> think it is smart to start using the word "service"...it
> might look good in management meetings ("so, does it support
> Web Services?"), but it is blurry.
>
> I'll even give you a -1 on that if neccessary :P. We do COP
> here, not SOP. Or are we changing that too?
>
> - Leo
A conclusion that the JSF folks agreed upon is that a Service is
just another type of component. It's scope is a larger one than
the traditional component.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Leo Simons <le...@apache.org>.
> I like the quote from Stephen Haberman:
>
> "I agree; I'm very new to Avalon, but given my naïve
> impression of what the component is supposed to do,
> I like XXXLocator better also. As a newbie, I can
> understand the concept quicker than with the
> XXXDirectory."
This is very important (I will know its meaning anyway =). I'd like to
get input from other users.
> That would make (on official voting):
>
> ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
> ComponentDirectory: 2 (Leo Simmons, MarcusCrafter)
I'm okay with ComponentXXXX (within some limits). I don't think it is
smart to start using the word "service"...it might look good in
management meetings ("so, does it support Web Services?"), but it is
blurry.
I'll even give you a -1 on that if neccessary :P. We do COP here, not
SOP. Or are we changing that too?
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Leo's Reservations ( taken from vote recap )
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch wrote:
>>From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>>
>>Can we standardize on the ??????????? interface for
>>pooled/singlethreaded components? Then I can say:
>>
>>Use the ComponentLocator to get the ComponentManager.
>>
>>
>
>No need. The ComponentLocator is the ComponentManager with a
>new name.
>
I don't think that's what Leo is suggesting. My understanding is that
Leo is talking about standardizing an interface for type of component
that actuall *manages* a pool. I.e. a *real* component manager. He's
saying that he would access this manager via a ComponentLoacator.
>
>
>
>>Use the ComponentManager to get the Component.
>>
>>
>
>Uh, use the ComponentLocator to get the Component.
>
>
No. Use the *real* ComponentManager component returned from the
ComponentLocator to get a pooled component instance.
>
>
>>Once you are done, put the Component back into the ComponentManager.
>>
>>
>
>This is the step we are trying to avoid. It is the incorrect
>and damaging opinion that a component should be released to the
>lookup mechanism.
>
>
I absolutely confident that Leo isn't talking about lookup on a locator.
He's
talking about some form of lookup on a pool manager that he is
suggesting could
be standardized (i.e. a pattern equivalent to the existing CM interface
with
exposure of relase for pooled objects). I'm not going to get into the
question
of wether or not the usage of the word "ComponentManager" is a good idea or
not - but I do support the introduction of an interface that allows exlicit
request and release semantics for pooled objects. There is code in Merlin
(commentted out) that is ready to support exactly the pattern the Leo
suggested.
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>
Leo's Reservations ( taken from vote recap )
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> A4 was about components, period. They could be pooled,
> singlethreaded, etc., and they existed inside a container. A5
> components are all threadsafe (remember, "the thing you get
> out of the ComponentManager is threadsafe"). They can be
> pooled, but if you do that then you are getting a "processing
> artifact" or whatever...
We still haven't come to a full agreement on the interface methods.
The interface for the CM soon to be ComponentLocator or something
along those lines won't have a release() method. That does not
preclude us from using multiple instances of a component to process
requests.
Keep in mind that we can still have one instance per thread, etc.
I think you are getting ahead of yourself. All the vote was
concerned with is what is this thing going to be _named_. The
next phase is deciding on how to use it.
Also, check the post I did on clarifying what it means to be
threadsafe.
> The above does not make any sense whatsoever. Please
> rearrange and replace words until it does - but here's the point:
>
> It seems like in A5 we have this, for what in A4 was pooled
> components:
>
> Use a [Component/Service][Locator/Directory] to get a
> ??????????. Do this in compose().
>
> Use the ?????????? to get the Component (as you knew it).
>
> The ????????? was called XXXXXManager or "factory" in our previous
> discussion.
Ok. Now you have lost me.
> So really, we're not about COP anymore - it is more of a
> Service-oriented programming style we're going for. You use
> the ServiceLocator to get a Component factory service, but
> the Component is only seen as a by-product of it all.
Service oriented programming == component oriented programming
It's a new name for an old concept.
However, the key focus of services is what I prefer -> they *do*
something instead of *represent* something.
Either way, the XXXXLocator does the same thing, it locates the
component we want to use.
SOP uses the same principles as COP, as it is just an extension
of the same paradigm.
> Furthermore, since pooling etc. was handler by the manager in A4 and
> explicitly by the component in A5, A5 is more about services.
> We really only focus on service-oriented stuff, and not much
> on those little black boxes we called components.
No, the pooling, etc. was never supposed to be done by the manager.
It was supposed to be doing it in the container. This is one of the
reasons why we need to change the name of the manager.
ECM is a hack because it merges container and manager--i.e. it
lacks proper SOC. Please don't let it taint our discussion
about the relationships. Let's take it one step at a time.
> ------------------------------------------------------------
>
> Can we standardize on the ??????????? interface for
> pooled/singlethreaded components? Then I can say:
>
> Use the ComponentLocator to get the ComponentManager.
No need. The ComponentLocator is the ComponentManager with a
new name.
> Use the ComponentManager to get the Component.
Uh, use the ComponentLocator to get the Component.
> Once you are done, put the Component back into the ComponentManager.
This is the step we are trying to avoid. It is the incorrect
and damaging opinion that a component should be released to the
lookup mechanism.
Read this next equation carefully, and then reread it:
Lookup Mechanism != Container
Separate those concepts in your mind. No other component
architecture exposes a release() method to the client.
It is about being smart and hiding the fact that something
might happen to be pooled.
> interface ComponentLocator {
> public Object lookup ();
> }
You are way ahead of yourself. Let's figure out what it
is called, then how the interface looks.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
>
> Can someone to a newbie check on "You get your *Components*
> from the *Service*Locator"?
>
> I was against ServiceLocator not because I didn't see
> Components as being/providing a service, but if we are
> talking about Components, then we should apply that name throughout.
>
> I really dislike the shift in terminology we have here...
Leo, I hear you loud and clear. However you are adding things
in this thread that need to be handled in a different thread.
ComponentLocator--fine.
Not a big deal, really.
As to ComponentLocator->ComponentManager->Component, I think
you are on crack, but that is a different thread.
<snip>everything that does not have to do with the name of the
component lookup service</snip>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [A5] CL -> CM -> Component
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Right, I'm back and off the crack. ;)
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
> This is completely consistent with the A5 approach. What I
> like is the
> fact that Leo is suggesting the pooled resource management
> (refered to
> above as ComponentManager) can be formalized at the framework level.
Yes, that is my intention.
ComponentPool is not a good name, as the interface must work
with the A5 equivalent of A4 SingleThreaded components.
ComponentHandler or ComponentFactory are better, although I think
ComponentManager is the best.
When you convert an A4 app to A5, if the interface is there,
references to it will be used almost exactly in the same
places as you used A4 ComponentManager before.
So I would call it ComponentManager.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] CL -> CM -> Component
Posted by Stephen McConnell <mc...@osm.net>.
Stephen McConnell wrote:
>
> The CL->CM->C snippet from Leo:
> -------------------------------
>
>
> Use the ComponentLocator to get the ComponentManager.
> Use the ComponentManager to get the Component.
> Once you are done, put the Component back into the ComponentManager.
>
> interface ComponentLocator {
> public Object lookup ();
> }
>
> interface ComponentManager {
> public Object getInstance ();
> public void release (Object o);
> }
>
> I think this is in line with EJB (XXXHome interface) but with an
> explicit release(), as we have not found some kind of release()
> unneccesary.
This is completely consistent with the A5 approach. What I like is the
fact that Leo is suggesting the pooled resource management (refered to
above as ComponentManager) can be formalized at the framework level.
Ignoring the name for a moment - the important thing is that this is
not an interface that would be exposed by any lifecycle phases - it is
simply a utility interface which would enable component implementations
that want to explicity release object to do so in a consistent manner.
The second point concerns the name - and this is a two sided coin.
Calling it ComponentManager is consistent!
------------------------------------------
Bacause A4 component manager interface defines the this functionality.
The A4->A5 difference is that the functionality concerning pooled
object management can be handled either:
- implicitly by the container
- explicity by the component (using the proposed interface)
Secondly, maintaining the ComponentManager interface means less
changes to code that is migrated from A4 to A5 because the semantics
defined by interface are functionaly consitent with the current
A4 interface of the same name (with the only differences being that
it is resolved by the client using a locator instead of directly
via compose, secondly, lookup is repaced by getInstance (which is
more consistent in the context of a pool) and the lastly, the
absence of the Component marker interface on release.
Calling it ComponentManger is confusing!
----------------------------------------
There is a lot legacy documentation that we will have to deal with
and there is legecy mind-set that associated a ComponentManager with
the framework Composable.compose( ComponentManager ) pattern. Perhaps
a better name for what Leo is proposing is ComponentPool.
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: [A5] CL -> CM -> Component
Posted by Stephen McConnell <mc...@osm.net>.
Woops - left out the key bit of what Leo was describing:
(added in-line)
Stephen McConnell wrote:
>
> The the title of this thread as Berin suggested.
>
> Stephen Haberman wrote:
>
>>> Can someone to a newbie check on "You get your *Components* from
>>> the *Service*Locator"?
>>>
>>> I was against ServiceLocator not because I didn't see Components
>>> as being/providing a service, but if we are talking about
>>> Components, then we should apply that name throughout.
>>>
>>
>>
>> I didn't mean to say I'd like the ServiceLocator name for getting
>> Components. As a newbie, I completely agree that Components should come
>> from a ComponentLocator. I just used the XXXLocator to follow suit with
>> the mail I was responding to.
>>
>>
>>
>>> The ????????? was called XXXXXManager or "factory" in our previous
>>> discussion.
>>>
>>
>>
>> If it's already been discussed, I don't mean to bring up an old topic or
>> start any intense debates, but if a XxxManager is pretty much the same
>> as an XxxFactory, I think newbies would "get" the name XxxFactory much
>> more quickly as it's common.
>>
>
> Actually, what Leo's saying makes a lot of sence.
> A5-ComponentLocator returns a component. That component can be
> anything. Leo's example is a component that implements the A4
> ComponentManager interface (or something equivalent) and as such
> returns an object the implements the A4 Component interface (or
> equivalent). That means that a A4-A5 migration could be handled very
> easily because your changing one line of code in you component when
> invoking the lookup. The rest of the code base stays the same.
>
> Steve.
The CL->CM->C snippet from Leo:
-------------------------------
Use the ComponentLocator to get the ComponentManager.
Use the ComponentManager to get the Component.
Once you are done, put the Component back into the ComponentManager.
interface ComponentLocator {
public Object lookup ();
}
interface ComponentManager {
public Object getInstance ();
public void release (Object o);
}
I think this is in line with EJB (XXXHome interface) but with an
explicit release(), as we have not found some kind of release()
unneccesary.
/LS
--
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>
[A5] CL -> CM -> Component
Posted by Stephen McConnell <mc...@osm.net>.
The the title of this thread as Berin suggested.
Stephen Haberman wrote:
>>Can someone to a newbie check on "You get your *Components* from
>>the *Service*Locator"?
>>
>>I was against ServiceLocator not because I didn't see Components
>>as being/providing a service, but if we are talking about
>>Components, then we should apply that name throughout.
>>
>>
>
>I didn't mean to say I'd like the ServiceLocator name for getting
>Components. As a newbie, I completely agree that Components should come
>from a ComponentLocator. I just used the XXXLocator to follow suit with
>the mail I was responding to.
>
>
>
>>The ????????? was called XXXXXManager or "factory" in our previous
>>discussion.
>>
>>
>
>If it's already been discussed, I don't mean to bring up an old topic or
>start any intense debates, but if a XxxManager is pretty much the same
>as an XxxFactory, I think newbies would "get" the name XxxFactory much
>more quickly as it's common.
>
Actually, what Leo's saying makes a lot of sence.
A5-ComponentLocator returns a component. That component can be
anything. Leo's example is a component that implements the A4
ComponentManager interface (or something equivalent) and as such returns
an object the implements the A4 Component interface (or equivalent).
That means that a A4-A5 migration could be handled very easily because
your changing one line of code in you component when invoking the
lookup. The rest of the code base stays the same.
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: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Stephen Haberman <st...@chase3000.com>.
> Can someone to a newbie check on "You get your *Components* from
> the *Service*Locator"?
>
> I was against ServiceLocator not because I didn't see Components
> as being/providing a service, but if we are talking about
> Components, then we should apply that name throughout.
I didn't mean to say I'd like the ServiceLocator name for getting
Components. As a newbie, I completely agree that Components should come
from a ComponentLocator. I just used the XXXLocator to follow suit with
the mail I was responding to.
> The ????????? was called XXXXXManager or "factory" in our previous
> discussion.
If it's already been discussed, I don't mean to bring up an old topic or
start any intense debates, but if a XxxManager is pretty much the same
as an XxxFactory, I think newbies would "get" the name XxxFactory much
more quickly as it's common.
Though I'll admit that most Factory implementations don't have a release
method, so if that's your reason for using the Manager name instead of
Factory, I can see the motivation. Though I don't necessarily think you
have to use the Manager name to get the point across that's it not a
pure Factory implementation.
(I'm assuming a lot here, so just dismiss my arguments if I'm wrong.)
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] (recap) New name for Version 5 ComponentManager
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> ServiceLocator (XXXXLocator): 3 (Me, Leo Sutic, Stephen McConnel)
Can someone to a newbie check on "You get your *Components* from
the *Service*Locator"?
I was against ServiceLocator not because I didn't see Components
as being/providing a service, but if we are talking about
Components, then we should apply that name throughout.
I really dislike the shift in terminology we have here...
A4 was about components, period. They could be pooled, singlethreaded,
etc., and they existed inside a container. A5 components are all
threadsafe (remember, "the thing you get out of the ComponentManager is
threadsafe"). They can be pooled, but if you do that then you are
getting a "processing artifact" or whatever...
The above does not make any sense whatsoever. Please rearrange and
replace
words until it does - but here's the point:
It seems like in A5 we have this, for what in A4 was pooled components:
Use a [Component/Service][Locator/Directory] to get a ??????????. Do
this
in compose().
Use the ?????????? to get the Component (as you knew it).
The ????????? was called XXXXXManager or "factory" in our previous
discussion.
So really, we're not about COP anymore - it is more of a
Service-oriented
programming style we're going for. You use the ServiceLocator to get a
Component factory service, but the Component is only seen as a
by-product
of it all.
Furthermore, since pooling etc. was handler by the manager in A4 and
explicitly by the component in A5, A5 is more about services. We really
only focus on service-oriented stuff, and not much on those little
black boxes we called components.
------------------------------------------------------------
Can we standardize on the ??????????? interface for
pooled/singlethreaded
components? Then I can say:
Use the ComponentLocator to get the ComponentManager.
Use the ComponentManager to get the Component.
Once you are done, put the Component back into the ComponentManager.
interface ComponentLocator {
public Object lookup ();
}
interface ComponentManager {
public Object getInstance ();
public void release (Object o);
}
I think this is in line with EJB (XXXHome interface) but with an
explicit release(), as we have not found some kind of release()
unneccesary.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>