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/01/31 22:45:04 UTC
Service Interface
Are we discontinuing the use of the Service Marker interface completely?
(phoenix client)
--
"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: Service Interface
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Feb 2002 08:45, Berin Loritsch wrote:
> Are we discontinuing the use of the Service Marker interface completely?
Yep. It was deprecated ages ago and will be removed when we go from
alpha->beta. Currently if any class still uses it they will have obnoxious
warnings generated in the log and to system.err to discourage its use ;)
--
Cheers,
Pete
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service Interface
Posted by Peter Donald <pe...@apache.org>.
On Sat, 2 Feb 2002 00:37, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Fri, 1 Feb 2002 09:17, Berin Loritsch wrote:
> >
> > Anyways if you get a chance checkout
> > proposal/myrmidon/src/java/org/apache/myrmidon/component/role
> > proposal/myrmidon/src/java/org/apache/myrmidon/component/type
>
> The time, the time...
:)
> (Speaking of which did you get my message I sent to
> you off list?)
Maybe ... still got 82 unanswered emails in my non-list, non-spam mailbox :)
> > I have an xpool package that I use for this that I could integrate into
> > mpool if it is compatible. However my xpool is mainly for managing
> > passive objects (ie. chunks of memory, packets, formatter objects) which
> > don't have any "lifecycle" as such. Would this fit in with what you are
> > doing with mpool?
>
> Probably. I still have a root ObjectFactory that can handle the process of
> making any object with the newInstance() method. The big difference is the
> asynchronous manager (or if no CommandManager is pressent--no management).
> I only have a really simple manager for the pool interface.
>
> Question:
>
> How do you feel about making the external pool interface more like the
> ThreadLocal interface? The ThreadLocal Interface is like this:
>
> ThreadLocal
> {
> public getObject()
> protected newObject()
> public setObject()
> }
>
> :/ Then again, I say we ought to KISS:
>
> Pool
> {
> Object get();
> void put( Object ); // although return does speak louder as to its
> purpose }
I actually prefer the aquire() / release() terminology - maybe I worked with
MS technology for too long ;)
However either interface is acceptable. If the pool was like ThreadLocal then
we would have a single pool per type and we would likely have a base class
that was extended by users to implement newObject?
So
class MyFooPool extends MPool
{
protected Object newObject()
{
return new Whazoo();
}
}
And we could also have a base class that uses delegation to an ObjectFactory?
I guess that would be kinda sweet. However KISS does dictate that it is the
simple get/put interface. SO maybe define pool by get/put and then havce
abstract class look like threadlocal and implement interface.
--
Cheers,
Pete
-----------------------------------------------------
First, we shape our tools, thereafter, they shape us.
-----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service Interface
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 1 Feb 2002 09:17, Berin Loritsch wrote:
>
> Anyways if you get a chance checkout
> proposal/myrmidon/src/java/org/apache/myrmidon/component/role
> proposal/myrmidon/src/java/org/apache/myrmidon/component/type
The time, the time... (Speaking of which did you get my message I sent to you
off list?)
>
> from ant CVS and see what you think. They are about to be updated in a bit to
> support the interspicing of factory between service and component (ie your
> equivelent of a handler I guess). But other than that it would be interesting
> to see where we could merge stuff.
>
>
>>I have yet to move my new managed pool stuff to a new mpool package.
>>That way I can get rid of the Poolable interface.
>>
>
> Hell yes!
>
> I have an xpool package that I use for this that I could integrate into mpool
> if it is compatible. However my xpool is mainly for managing passive objects
> (ie. chunks of memory, packets, formatter objects) which don't have any
> "lifecycle" as such. Would this fit in with what you are doing with mpool?
Probably. I still have a root ObjectFactory that can handle the process of making
any object with the newInstance() method. The big difference is the asynchronous
manager (or if no CommandManager is pressent--no management). I only have a
really simple manager for the pool interface.
Question:
How do you feel about making the external pool interface more like the ThreadLocal
interface? The ThreadLocal Interface is like this:
ThreadLocal
{
public getObject()
protected newObject()
public setObject()
}
:/ Then again, I say we ought to KISS:
Pool
{
Object get();
void put( Object ); // although return does speak louder as to its purpose
}
--
"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: Service Interface
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Feb 2002 09:17, Berin Loritsch wrote:
> Well, the Service is already deprecated. It is not used by the kernel, or
> referenced directly by any known API. Therefore it is superfluous (sp?).
> I was checking to see if my observation holds true.
It should still be used in the validator. The validator will check to see if
any service interface implements Service and if it does generate warnings.
> BTW, You and Peter will probably like what I did for the new Container
> abstraction in that department. The ComponentHandler is identified by
> by the new RoleManager--thereby tying Handler to Component Class. It
> defaults to a PerThreadComponentHandler which has one instance of the
> Component per requesting thread. I figured it was a nice balance from a
> pooled implementation and a threadsafe implementation.
I should look at your work here because it is very similar to what I am doing
over in ant-land. My initial work was based on the ECM that was much less
tightly coupled but given how much I dislike ComponentSelector I ended up
removing that and going with a new interface (TypeFactory). Just recently it
was decided that we should probably interspice an extra factory between
component and requested resource (like in Paulos system) that way the
resource no longer needs to follow Avalon framework lifecycle but still can
be used from within that.
Anyways if you get a chance checkout
proposal/myrmidon/src/java/org/apache/myrmidon/component/role
proposal/myrmidon/src/java/org/apache/myrmidon/component/type
from ant CVS and see what you think. They are about to be updated in a bit to
support the interspicing of factory between service and component (ie your
equivelent of a handler I guess). But other than that it would be interesting
to see where we could merge stuff.
> I have yet to move my new managed pool stuff to a new mpool package.
> That way I can get rid of the Poolable interface.
Hell yes!
I have an xpool package that I use for this that I could integrate into mpool
if it is compatible. However my xpool is mainly for managing passive objects
(ie. chunks of memory, packets, formatter objects) which don't have any
"lifecycle" as such. Would this fit in with what you are doing with mpool?
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service Interface
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
>
>> BTW, You and Peter will probably like what I did for the new Container
>> abstraction in that department. The ComponentHandler is identified by
>> by the new RoleManager--thereby tying Handler to Component Class. It
>> defaults
>> to a PerThreadComponentHandler which has one instance of the Component
>> per requesting thread. I figured it was a nice balance from a pooled
>> implementation and a threadsafe implementation.
>
>
> Sounds good. Makes me think I am making a mess of the impl of EOB ;-)
> and should be reusing more.
It's brand new, and not tested very well.... yet.
--
"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: [Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>On Wed, 6 Feb 2002 11:21, Paul Hammant wrote:
>
>>You can start that tree Berin but I cannot use it. EOB sits on Phoenix
>>and that already has the existing framework jar in the classpath. I
>>could not replace that beacue it would barf without a complete rework of
>>phonix. In short I'll stick to my own framwork interfaces and not use
>>those from a fledling framework 5.0
>>
>
>Im not entirely sure where the problem is. Are you talking about using the CM
>within Phoenix or within the EOB application. ie Do you want EOB objects
>exposed to blocks or something or are you just using the CM abstraction
>within EOB.
>
Within EOB and to expose Blocks, EOB beans (not Components) or remote
AltRMI services (not Components). I am in effect treating the CM as
more of an IoC replacement for JNDI. JNDI returns Object, if someone
suggested it returns JNDIObject instead, there would be a revolution.
>If it is the second then it may be best for the time being to create your own
>interface. When we evolve to Framework 5 you can choose to (or not to) adopt
>those interfaces.
>
That's what I'm doing. I'd almost certainly adopt the framework method
when finalised. What scares me most is not knowing whether this is one
month or one year (given the amount of other changes that might be
implemented at the same time.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Peter Donald <pe...@apache.org>.
On Wed, 6 Feb 2002 11:21, Paul Hammant wrote:
> You can start that tree Berin but I cannot use it. EOB sits on Phoenix
> and that already has the existing framework jar in the classpath. I
> could not replace that beacue it would barf without a complete rework of
> phonix. In short I'll stick to my own framwork interfaces and not use
> those from a fledling framework 5.0
Im not entirely sure where the problem is. Are you talking about using the CM
within Phoenix or within the EOB application. ie Do you want EOB objects
exposed to blocks or something or are you just using the CM abstraction
within EOB.
If it is the second then it may be best for the time being to create your own
interface. When we evolve to Framework 5 you can choose to (or not to) adopt
those interfaces.
--
Cheers,
Pete
-------------------------------------------------
We should take care not to make the intellect our
god; it has, of course, powerful muscles, but no
personality.
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
>> framework.component2.ComponentManager
>> framework.component2.Composable
>
> I think this is shoving us to too much change too soon. I propose the
> following
> solution:
>
> 1) Finish ContainerManager classes et. al. to prove how feasible it is
> to make
> Component and ThreadSafe marker interfaces unnecessary.
>
> 2) Have some time to learn from the implementation (what can we do
> better?).
>
> 3) After our lessons learned phase, start considering An Avalon 5.0
> tree to start
> cleaning out cruft and fixing things (like Configuration being an
> interface but
> Parameters being an implementation).
You can start that tree Berin but I cannot use it. EOB sits on Phoenix
and that already has the existing framework jar in the classpath. I
could not replace that beacue it would barf without a complete rework of
phonix. In short I'll stick to my own framwork interfaces and not use
those from a fledling framework 5.0
> If we feel confident that Avalon is ready for a reconstruct, we can
> discuss this
> at length. But before we consider an Avalon 5.0 release date, we need
> to have
> ContainerManager and friends moved out of scratchpad, the
> excalibur.component
> package deprecated, and the arrangement exist for a couple of releases.
Timing timing, EOB needs the return type of Object. It is developing
fast and building a small community.
> By encouraging people to an alternative like the ContainerManager
> approach, we
> enable a smoother migration to Avalon 5.0--whatever form it may take.
>
> Paul, I like your enthusiasm, but we don't want to jerk our users
> around, or
> give them the impression that is what we are doing.
>
> For all these reasons, I would have a strong -1 to putting those
> interfaces
> in Framework at this time.
>
> Furthermore, there are other things we may want to explore, such as a
> Query object
> on the ComponentManager. These changes will undoubtedly force more
> deprecations
> and unhappy people.
You leading me to belive this is a 6-9 month process.
I'd hope that the abolition of Component as a marker interface could be
seen as so easy to implement (and ripple through other codebases), that
it could be done as an addendum to the curent release. Large refactor
work scares me, as you'll be associatig a simple change with a huge change.
My motives are purely selfish, I have a case for composable without
insiting on Component now..
Sorry dude...
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Tue, 5 Feb 2002 19:14, Paul Hammant wrote:
>
>>3a) Framework 5.0 Composable given same method signatures as
>>Composable2, Likewise ComponentManager for CompMgr2.
>>3b) Composable2 has methods removed, extends Composable and is marked as
>>deprecated.
>>4) Framework 5.x Composable2 etc removed.
>>
>
> I have an extreme allergy of postfixing things with numbers. Way too many
> years working with MS tech to like that :)
I agree whole-heartedly!
> How about we add a new package or
> maybe just a new name. Possible candidates include
>
>
> framework.component2.ComponentManager
> framework.component2.Composable
>
> framework.service.ServiceManager
> framework.service.Servicable
>
> framework.service.ServiceDirectory
> framework.service.ServiceEnabled
> ...
:/
I think this is shoving us to too much change too soon. I propose the following
solution:
1) Finish ContainerManager classes et. al. to prove how feasible it is to make
Component and ThreadSafe marker interfaces unnecessary.
2) Have some time to learn from the implementation (what can we do better?).
3) After our lessons learned phase, start considering An Avalon 5.0 tree to start
cleaning out cruft and fixing things (like Configuration being an interface but
Parameters being an implementation).
If we feel confident that Avalon is ready for a reconstruct, we can discuss this
at length. But before we consider an Avalon 5.0 release date, we need to have
ContainerManager and friends moved out of scratchpad, the excalibur.component
package deprecated, and the arrangement exist for a couple of releases.
By encouraging people to an alternative like the ContainerManager approach, we
enable a smoother migration to Avalon 5.0--whatever form it may take.
Paul, I like your enthusiasm, but we don't want to jerk our users around, or
give them the impression that is what we are doing.
For all these reasons, I would have a strong -1 to putting those interfaces
in Framework at this time.
Furthermore, there are other things we may want to explore, such as a Query object
on the ComponentManager. These changes will undoubtedly force more deprecations
and unhappy people.
--
"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: [Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>>I have an extreme allergy of postfixing things with numbers. Way too many
>>years working with MS tech to like that :) How about we add a new package or
>>maybe just a new name. Possible candidates include
>>
>
>I like to second that!!! Numbers as postfix for interface versioning are really
>ugly!! I'd also prefer new package names...
>
OK then, but I think
framework.component2.ComponentManager
framework.component2.Composable
is a misnomer. Seeing as were hinting that component is becoming intellectual rather than actual.
framework.alpha5.ComponentManager
framework.alpha5.Composable
Not better?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Torsten Curdt <tc...@dff.st>.
On Tue, 5 Feb 2002, Peter Donald wrote:
> On Tue, 5 Feb 2002 19:14, Paul Hammant wrote:
> > Folks
> >
> > I would like to add these two new framework interfaces (see below). I
> > would use them in EOB, with the understanding that they will/might
> > dissapear one day.
> >
> > + 1 from me for adding to jakarta-avalon
> >
> > Incidentally, I see the future like this:
> >
> > 1) Interfaces get added
> > 2) Berin, Peter et al consider "Component" marker interface as
> > unecessary in the same way as "Service" was unecessary
>
> Peter alreay considered interfaces unecessary prior to going beta ;)
>
> > 3a) Framework 5.0 Composable given same method signatures as
> > Composable2, Likewise ComponentManager for CompMgr2.
> > 3b) Composable2 has methods removed, extends Composable and is marked as
> > deprecated.
> > 4) Framework 5.x Composable2 etc removed.
>
> I have an extreme allergy of postfixing things with numbers. Way too many
> years working with MS tech to like that :) How about we add a new package or
> maybe just a new name. Possible candidates include
I like to second that!!! Numbers as postfix for interface versioning are really
ugly!! I'd also prefer new package names...
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Peter Donald <pe...@apache.org>.
On Tue, 5 Feb 2002 19:14, Paul Hammant wrote:
> Folks
>
> I would like to add these two new framework interfaces (see below). I
> would use them in EOB, with the understanding that they will/might
> dissapear one day.
>
> + 1 from me for adding to jakarta-avalon
>
> Incidentally, I see the future like this:
>
> 1) Interfaces get added
> 2) Berin, Peter et al consider "Component" marker interface as
> unecessary in the same way as "Service" was unecessary
Peter alreay considered interfaces unecessary prior to going beta ;)
> 3a) Framework 5.0 Composable given same method signatures as
> Composable2, Likewise ComponentManager for CompMgr2.
> 3b) Composable2 has methods removed, extends Composable and is marked as
> deprecated.
> 4) Framework 5.x Composable2 etc removed.
I have an extreme allergy of postfixing things with numbers. Way too many
years working with MS tech to like that :) How about we add a new package or
maybe just a new name. Possible candidates include
framework.component2.ComponentManager
framework.component2.Composable
framework.service.ServiceManager
framework.service.Servicable
framework.service.ServiceDirectory
framework.service.ServiceEnabled
...
--
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Vote] new Framework interfaces [ was "Service Interface" ]
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks
I would like to add these two new framework interfaces (see below). I
would use them in EOB, with the understanding that they will/might
dissapear one day.
+ 1 from me for adding to jakarta-avalon
Incidentally, I see the future like this:
1) Interfaces get added
2) Berin, Peter et al consider "Component" marker interface as
unecessary in the same way as "Service" was unecessary
3a) Framework 5.0 Composable given same method signatures as
Composable2, Likewise ComponentManager for CompMgr2.
3b) Composable2 has methods removed, extends Composable and is marked as
deprecated.
4) Framework 5.x Composable2 etc removed.
Regards,
- Paul H
> Berin,
>
>>> As to the Component interface, it is currently used in the
>>> ComponentManager
>>> API, and is rather central to the way things work. We _can't_
>>> change that
>>> in Avalon 4.x. When we get to the point where we want to aim for
>>> 5.0, we
>>> will revisit the whole concept of marker interfaces.
>>
>>
>>
>> I know dude. With EOB I was going to use all the Framework
>> interfaces but decided I could not use Composable because it have
>> back a Component. EOB beans getting interfaces from anywhere, remote
>> or local, to force these to impl Component was impossible.
>>
>> I am happy to wait until 5.0, however changing a return value (on
>> lookup()) from Component to Object has far fewer implications than
>> the other way around....
>
>
> Is there any chance we could add.....
>
> interface Composable2 {
> void compose(ComponentManager2 compMgr) throws ComponentException;
> }
>
> interface ComponentManager2 {
> Object lookup(String s) throws ComponentException;
> }
>
> ... in advance of this 5.0 migration? I'd like to be an early user....
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service Interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
>> As to the Component interface, it is currently used in the
>> ComponentManager
>> API, and is rather central to the way things work. We _can't_ change
>> that
>> in Avalon 4.x. When we get to the point where we want to aim for
>> 5.0, we
>> will revisit the whole concept of marker interfaces.
>
>
> I know dude. With EOB I was going to use all the Framework interfaces
> but decided I could not use Composable because it have back a
> Component. EOB beans getting interfaces from anywhere, remote or
> local, to force these to impl Component was impossible.
>
> I am happy to wait until 5.0, however changing a return value (on
> lookup()) from Component to Object has far fewer implications than the
> other way around....
Is there any chance we could add.....
interface Composable2 {
void compose(ComponentManager2 compMgr) throws ComponentException;
}
interface ComponentManager2 {
Object lookup(String s) throws ComponentException;
}
... in advance of this 5.0 migration? I'd like to be an early user....
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service Interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
> Well, the Service is already deprecated. It is not used by the
> kernel, or
> referenced directly by any known API. Therefore it is superfluous (sp?).
> I was checking to see if my observation holds true.
Yup, it is the rogue service traversing phoenix dependant app out there
that is the spoiler. I think we know it does not exist, and
theinterface has been deprecated for many months. Time to kill it?
> As to the Component interface, it is currently used in the
> ComponentManager
> API, and is rather central to the way things work. We _can't_ change
> that
> in Avalon 4.x. When we get to the point where we want to aim for 5.0, we
> will revisit the whole concept of marker interfaces.
I know dude. With EOB I was going to use all the Framework interfaces
but decided I could not use Composable because it have back a Component.
EOB beans getting interfaces from anywhere, remote or local, to force
these to impl Component was impossible.
I am happy to wait until 5.0, however changing a return value (on
lookup()) from Component to Object has far fewer implications than the
other way around....
> BTW, You and Peter will probably like what I did for the new Container
> abstraction in that department. The ComponentHandler is identified by
> by the new RoleManager--thereby tying Handler to Component Class. It
> defaults
> to a PerThreadComponentHandler which has one instance of the Component
> per requesting thread. I figured it was a nice balance from a pooled
> implementation and a threadsafe implementation.
Sounds good. Makes me think I am making a mess of the impl of EOB ;-)
and should be reusing more.
> I have yet to move my new managed pool stuff to a new mpool package.
> That way I can get rid of the Poolable interface.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Service Interface
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
> Berin,
>
>> Are we discontinuing the use of the Service Marker interface completely?
>
>
> If that is a vote, then +1
>
> I have a few Blocks that do not implement native Phoenix/Cornerstone
> services.
> There are 12 or so uses of it in Cornerstone and about two in Phoenix
> itself.
>
> 'Service' is something I think of as implicit.
>
> By the way, I think that Component should go the same way. But that is
> very controvercial I guess.
Well, the Service is already deprecated. It is not used by the kernel, or
referenced directly by any known API. Therefore it is superfluous (sp?).
I was checking to see if my observation holds true.
As to the Component interface, it is currently used in the ComponentManager
API, and is rather central to the way things work. We _can't_ change that
in Avalon 4.x. When we get to the point where we want to aim for 5.0, we
will revisit the whole concept of marker interfaces.
BTW, You and Peter will probably like what I did for the new Container
abstraction in that department. The ComponentHandler is identified by
by the new RoleManager--thereby tying Handler to Component Class. It defaults
to a PerThreadComponentHandler which has one instance of the Component
per requesting thread. I figured it was a nice balance from a pooled
implementation and a threadsafe implementation.
I have yet to move my new managed pool stuff to a new mpool package.
That way I can get rid of the Poolable interface.
--
"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: Service Interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
> Are we discontinuing the use of the Service Marker interface completely?
If that is a vote, then +1
I have a few Blocks that do not implement native Phoenix/Cornerstone
services.
There are 12 or so uses of it in Cornerstone and about two in Phoenix
itself.
'Service' is something I think of as implicit.
By the way, I think that Component should go the same way. But that is
very controvercial I guess.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>