On Wed, 2002-08-28 at 08:55, Stephen McConnell wrote:
>
> Less is more.
>
> In the list below I don't see why we need component, partition and
> application seperation - these notions are container specific.
I disagree. Where some containers may not provide this separation (and
hence only support the "component" space), those that do provide a
separation should provide the same one.
> I would prefer to the subset :
>
> avalon:home.dir
> avalon.work.dir
> avalon::common.classloader <-- but question on this
> avalon::name
>
> I've included the avalon:name entry because without it you will not be
> able to resolve all of the Phoenix portability issues.
Before accepting this as a common part of the framework, I think a
definition of what avalon:name contains (type, contract) is neccessary,
as well as a rationale different than ("phoenix portability issue") is
needed (ie like Berin did for the other attrs). Can we start with the
proposed three and add this one later?
> For the home and
> work values - no problem - for the "common.classloader" - what does this
> mean - is it different from a regular classloader supplied to the
> component ?
to me "common" implies "shared"... indicating that the component must
accept the fact that it may share its classloader with other components.
The scoping issue pete mentions wrt to the directory setup does not
apply (classloaders themselves already cascade). Hence, a different
namespace from "component|partition|application" must be used and common
is a natural choice.
my thoughts only, of course =)
However, due to reasons mentioned previously, I still think the
namespace base should be "avalon". I'm not going to -1 based on that
though...
cheers,
Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
