Getting *something* going (was: Son of ComponentManager)

[Leo Sutic <le...@inspireinfrastructure.com>]

All,

even before the final vote on Stephen's proposal has been
called I can say that I will veto (-1) it, provided that it
does not change significantly. This is not a vote, and I
won't provide an explanation for it at this time - I will,
should a vote be called.

However, I realize that there is a very real need to get
rid of the Component interface soonest, and I do not want
to block that. Plus, it is something that we do
have consensus on.

As a solution until the remaining wrinkles have been
worked out of the ServiceManager proposal (something
which may take a while), how about this plan:

Purpose:

 - Get rid of the Component interface *now*.

 - Buy more time to hammer out a better proposal.

 - Solve the Component / Object issue in Avalon 4.2
   (a small problem).

 - Solve the general Component/Service/Object management
   problem in Avalon 5.0 (a much bigger problem).

Steps:

1) The following interfaces are put in framework.service:

   public interface ServiceManager {
     public Object lookup (String role) throws ServiceException;
     public void release (Object service);
     public boolean hasService (String role);
   }

   public interface Serviceable {
     public void service (ServiceManager manager) throws ServiceException;
   }

   The contracts are the same as for ComponentManager and Composable,
   respectively, and the interfaces are basically those, but with
   Component -> Object.

2) Factor out the container code from ECM and call the class EM. Rename
   the lookup() method to lookupImpl or something and have it return an
Object.

   Rename release(Component) -> releaseImpl (Object).

   ECM extends EM and implements Component lookup () via lookupImpl,
                      implements void release (Component) via releaseImpl.

   ESM extends EM and implements Object    lookup () via lookupImpl.
                      implements void release (Object) via releaseImpl.

   Right - now we have ECM (unchanged) and an ESM.

   Implement support for Servicable in EM.

The two steps above should solve the problem with the Component interface
and maintain backwards compatibility. The only thing that will not work
is putting a Servicable component in a manager that does not support
the Servicable interface, but this is not a blocker. Also, looking up
a non-Component component via a ComponentManager interface will
probably lead to a ClassCastException.

3) The proposal remains a proposal.

4) The proposal is renamed Component* instead of Service*, as it is a
   replacement for ComponentManager et al.

5) The proposal is re-targeted for Avalon 5. This frees us from the
   backwards compatibility requirement. (I understand that this was
   an Avalon 5 proposal that was dragged into Avalon 4 because its
   manager dealt with Object instead of Component and there was
   a need for that.)

The purpose of the last three points is to delay the proposal while
still keeping it alive. The proposal has gone through many changes
back and forth under the last days, even, and we still have not
resolved all issues, for example, with poolable components. I think
it will need at least a couple of weeks of hammering and analysis
before we can commit to it.

This plan leaves us with:

 - A Component-less ServiceManager interface, with the same
   contract as the ComponentManager interface.

 - A working implementation of a ServiceManager with all
   bells and whistles of the ECM.

 - Time to solve the bigger problem, without having to
   rush something out to solve the smaller Component/Object
   problem.

Right - fire away...

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Getting *something* going (was: Son of ComponentManager)

[Paul Hammant <Pa...@yahoo.com>]

Stephen, Leo,

>So as not to leave any doubt, this is basically
>the complete "Component" package with (a) the replacement of Component with
>Object, (b) updates to the javadoc as required (c) package name of
>org.apache.avalon.framework.service, (d) and the supporting Phoenix
>lifecycle helper additions.
>
+1

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Getting *something* going (was: Son of ComponentManager)

[Stephen McConnell <mc...@apache.org>]

Welcome home Object!
The org.apache.framework.service.* is in place.
Steve.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Getting *something* going (was: Son of ComponentManager)

[Leo Sutic <le...@inspireinfrastructure.com>]

Stephen,

will you do the committ, as you already have the finished files?

I count +4 and -0, and the vote has been going for nearly 12 hours.

/LS

> From: Stephen McConnell [mailto:mcconnell@apache.org]
> 
> +1
> Plus updated javadoc on-line.
> http://home.osm.net/doc/avalon/index.html


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Getting *something* going (was: Son of ComponentManager)

[Stephen McConnell <mc...@apache.org>]

+1
Plus updated javadoc on-line.
http://home.osm.net/doc/avalon/index.html
Steve.


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Tuesday, 19 February, 2002 23:53
> To: Avalon Developers List
> Subject: Re: Getting *something* going (was: Son of ComponentManager)
>
>
> On Wed, 20 Feb 2002 09:53, Stephen McConnell wrote:
> > Leo Sutic wrote:
> > > 1) The following interfaces are put in framework.service:
> > >
> > >    public interface ServiceManager {
> > >      public Object lookup (String role) throws ServiceException;
> > >      public void release (Object service);
> > >      public boolean hasService (String role);
> > >    }
> > >
> > >    public interface Serviceable {
> > >      public void service (ServiceManager manager) throws
> > > ServiceException; }
> > >
> > >    The contracts are the same as for ComponentManager and Composable,
> > >    respectively, and the interfaces are basically those, but with
> > >    Component -> Object.
> >
> ...
> > Any objections to a vote on this?
>
> +1 for vote, +1 to interfaces
>
> --
> Cheers,
>
> Pete
>
> ----------------------------------------------------------------
> Fools ignore complexity.  Pragmatists suffer it.
> Some can avoid it.  Geniuses remove it.
> -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
> ----------------------------------------------------------------
>
> --
> 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: Getting *something* going (was: Son of ComponentManager)

[Peter Donald <pe...@apache.org>]

On Wed, 20 Feb 2002 09:53, Stephen McConnell wrote:
> Leo Sutic wrote:
> > 1) The following interfaces are put in framework.service:
> >
> >    public interface ServiceManager {
> >      public Object lookup (String role) throws ServiceException;
> >      public void release (Object service);
> >      public boolean hasService (String role);
> >    }
> >
> >    public interface Serviceable {
> >      public void service (ServiceManager manager) throws
> > ServiceException; }
> >
> >    The contracts are the same as for ComponentManager and Composable,
> >    respectively, and the interfaces are basically those, but with
> >    Component -> Object.
>
...
> Any objections to a vote on this?

+1 for vote, +1 to interfaces

-- 
Cheers,

Pete

----------------------------------------------------------------
Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Getting *something* going (was: Son of ComponentManager)

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:
> 1) The following interfaces are put in framework.service:
>
>    public interface ServiceManager {
>      public Object lookup (String role) throws ServiceException;
>      public void release (Object service);
>      public boolean hasService (String role);
>    }
>
>    public interface Serviceable {
>      public void service (ServiceManager manager) throws ServiceException;
>    }
>
>    The contracts are the same as for ComponentManager and Composable,
>    respectively, and the interfaces are basically those, but with
>    Component -> Object.

Back on the 10 Feb, I made a similar though more detailed proposal
which for all intensive purposes is what Leo is describing above.
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg05885.html
The 10 Feb proposal (and the related src/proposal/service CVS 1.1 version
of the same date also includes a DefaultServiceManager and the updates
to the Phoenix lifecycle helper implementation to include direct support
for Serviceable and related interfaces.  I agree with Leo that it would
be really helpful to have this included within the framework now, enabling
a more complete assessment of the service management questions as part of
the Avalon 5.0 actions.  So as not to leave any doubt, this is basically
the complete "Component" package with (a) the replacement of Component with
Object, (b) updates to the javadoc as required (c) package name of
org.apache.avalon.framework.service, (d) and the supporting Phoenix
lifecycle helper additions.

Any objections to a vote on this?

Cheers, Steve.






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>