> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> >2) Most agree that we should consider using Commons Logging
> instead of
> > maintaining our own. Any dissenters I missed?
> >
>
> Can I hold onto an option to dissent?
> I love log kit configurability and structure from a
> management point of
> view. Provindg changes don't eliminate any of that
> functionality I'll
> be happy. Otherwise you will be pushing me to dissent. :-)
Commons Logging is just another logging abstraction--developed at
the same time as Avalon logging abstraction. Ours was released
roughly a month before theirs.
> >5) CM should at least look like this:
> >
> >interface ComponentLocater /* or ServiceLocator */
> >{
> > Object lookup(String role) throws ComponentException;
> > boolean hasComponent(String role);
> >}
> >
>
> Which is basically equivalent to A4 ServiceManager assuming
> release() is
> depricated. As far as A4 is concerned I thinkk we should
> introduce this
> into the service package (renamed to ServiceLocator for package
> consistency), update ServiceManager to extend from ServiceLocator for
> backward compatability, and declare ServiceManager as a depricated
> interface. That provides a complete migration path now - now need to
> wait for A5.
:)
> >class ComponentException extends Exception
> >{
> > // ... skip constructors and impls.
> >
> > String getRole();
> > Throwable getCause();
> >}
> >
>
> +1
> Could be added to the current A4 defintion of ComponentException and
> ServiceException without brreaking anything.
Yep.
> >All dissent is on anything extra.
> >
>
> I think the main thing missing in the above is the work on getting a
> formal meta model in place as part of the framework. This
> can be viewed
> as an A4 activitiy because there are not obsticles and no
> changes needed
> to put it in place.
>
> One final note - given the above - I'm really questioning the
> necessity
> for an A5 any time soon (blame that on Pete Royal for putting the
> thought into my head, and yourself for presenting the above summary
> which seems to negate a requirement for package name changes).
The package name changes are mostly for easing the typing requirements.
> If instead if I look at the hot topics - Avalon 4.2
>
> - doc updates
> - putting a locator in the framework.service package
> - update the ComponentException/ServiceException to hold a
> role reference
> - focused activities on framework metadata
> - focussed activites on common logging and how that relates
> to logkit
> - focussed activites on common container services
> (assembly, security
> policy, etc.)
> - other commons related stuff to ensure communication of framework
> resources
> such as configuration
> - component demos
> - more demo
>
> Then I get everything I wanted from 5.0.
> ECM has a migration path via the service package.
> Nothing breaks.
ECM gets deprecated and Fortress lives on. ECM is still a beast
worth killing. It mixes Container/LookupMechanism concerns. It
is not really extensible.
Fortress needs some attention, but we want to make it as extensible
as we can--without damaging maintainability.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
