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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
