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/18 01:18:27 UTC
[A5] Current State of affairs
Currently what we have decided on so far--i.e. the agreements are:
1) Better documentation in the package.html for the correct way to
use and extend Context.
2) Most agree that we should consider using Commons Logging instead of
maintaining our own. Any dissenters I missed?
3) Configuration and Parameters are essentially the same concern, and
most likely should be merged into one *able interface. I.e. either
write a Parameters.fromConfiguration() in the configurable method
or pass them both. I prefer the first option.
4) Activity: Maintain the same setup as A4. I.e. separate Initializable
and Disposable. Oh yeah, and Nicola doesn't like that or context. ;P
5) CM should at least look like this:
interface ComponentLocater /* or ServiceLocator */
{
Object lookup(String role) throws ComponentException;
boolean hasComponent(String role);
}
class ComponentException extends Exception
{
// ... skip constructors and impls.
String getRole();
Throwable getCause();
}
All dissent is on anything extra.
"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: [A5] Current State of affairs
Posted by Eung-ju Park <co...@hotmail.com>.
-1 for 2)
I think avalon logging framework is more elegant than commons logging.
Switch logging framework affect whole avalon.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "'Avalon Developers List'" <av...@jakarta.apache.org>
Sent: Tuesday, June 18, 2002 8:18 AM
Subject: [A5] Current State of affairs
Currently what we have decided on so far--i.e. the agreements are:
1) Better documentation in the package.html for the correct way to
use and extend Context.
2) Most agree that we should consider using Commons Logging instead of
maintaining our own. Any dissenters I missed?
3) Configuration and Parameters are essentially the same concern, and
most likely should be merged into one *able interface. I.e. either
write a Parameters.fromConfiguration() in the configurable method
or pass them both. I prefer the first option.
4) Activity: Maintain the same setup as A4. I.e. separate Initializable
and Disposable. Oh yeah, and Nicola doesn't like that or context. ;P
5) CM should at least look like this:
interface ComponentLocater /* or ServiceLocator */
{
Object lookup(String role) throws ComponentException;
boolean hasComponent(String role);
}
class ComponentException extends Exception
{
// ... skip constructors and impls.
String getRole();
Throwable getCause();
}
All dissent is on anything extra.
"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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Current State of affairs
Posted by Peter Royal <pr...@apache.org>.
On Monday 17 June 2002 08:28 pm, Stephen McConnell wrote:
> parsing of an XML doucment. A parameter from a properties file is far
> more efficient. I would prefer that these two stayed seperate (i.e. no
> change).
Would the ability to generate a Configuration from a properties file satiate
this need?
> >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.
+1
> >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.
+1
> 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.
And a very important activity too!
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Current State of affairs
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>> 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). 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.
>
>
> So it's Avalon 5, right? ;-)
Almost. Some disavantages:
1. ComponentManager and Component stay as per current defintion
in framework.component but depricated in favour of
ServiceManager/Serviceable.
2. No seperation of interfaces and implementation at the packaging
level (A5 proposal is doing this) - however, this is achievable
but its more complicated to seperate when generating jars (but
still possible).
3. Depricated methods stay depricated.
That's all I can think of.
Can anyone else come up with any other disavantages?
>
>
> > ECM has a migration path via
>
>> the service package. Nothing breaks.
>
>
> I like this.
> In fact it was the base of my stupidly proposed proposal-rant.
>
> Call it 4.5, call it 5, this is what we want: 4 cleaned and on steriods.
>
> Shall we call it 5 anyway?
>
> Whacky proposal: call it 4.5 or 5.4, to enphasize the fact that it's
> compatible with 4.
>
:-)
4.X
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] Current State of affairs
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
> 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).
> 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.
So it's Avalon 5, right? ;-)
> ECM has a migration path via
> the service package. Nothing breaks.
I like this.
In fact it was the base of my stupidly proposed proposal-rant.
Call it 4.5, call it 5, this is what we want: 4 cleaned and on steriods.
Shall we call it 5 anyway?
Whacky proposal: call it 4.5 or 5.4, to enphasize the fact that it's
compatible with 4.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [A5] Current State of affairs
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
> >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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [A5] Current State of affairs
Posted by Stephen McConnell <mc...@osm.net>.
Berin Loritsch wrote:
>Currently what we have decided on so far--i.e. the agreements are:
>
>1) Better documentation in the package.html for the correct way to
> use and extend Context.
>
Can be addressed independetly of A5 as part of A4 ongoing development.
>
>
>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. :-)
>
>
>3) Configuration and Parameters are essentially the same concern, and
> most likely should be merged into one *able interface. I.e. either
> write a Parameters.fromConfiguration() in the configurable method
> or pass them both. I prefer the first option.
>
There are some guys over on the OpenORB project who are using
paramerarizable specifically to avoidd the more expensive loading and
parsing of an XML doucment. A parameter from a properties file is far
more efficient. I would prefer that these two stayed seperate (i.e. no
change).
>
>
>4) Activity: Maintain the same setup as A4. I.e. separate Initializable
> and Disposable. Oh yeah, and Nicola doesn't like that or context. ;P
>
>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.
>
>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).
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.
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>