On Fri, 2002-07-05 at 09:29, Peter Donald wrote:
> At 09:17 AM 7/5/2002 +0200, you wrote:
> > > Never going to use an interface again for this. If you remember back about
> > > 1 1/2 years ago we separated out interface and implementations for the
> > meta
> > > classes. It sucked hugely.
> >
> >Can't say that I do...could you provide a keyword or archive link?
>
> Nope. Have a look through phoenixs CVS history it should be there.
> Previously I tried to write a generic container infrastructure but failed
> miserably due to overspecification of everything. The results of this are
> scattered through history of jakarta-avalon and
> jakarta-avalon-excalibur/all CVSes under the "container" package.
rings a bell. What was it again, camelot 'n friends?
At that point, I think we removed it because the only 'real' container
we had was phoenix (ECM wasn't really viewed as such) so it made no
sense to separate any of it out.
Now, we have quite a few containers (and everyone now has an idea of
what it is and does) and some more experience. I'd say the situation
thus has improved to a point where more people get what we're doing, and
on the other hand we're off worse because there is no portability.
Hence trying once again, no?
> > >{
> > > > DependencyMetaData[] getDependencyData();
> > > > Logger getLogger();
> > >
> > > -1
> > > This should go into component entry not metadata as it is tied to a
> > > particular instance, not a profile.
> >
> >in my definitions of metadata and metainfo, metadata is indeed tied to a
> >particular instance, or at least to a group of functionally equivalent
> >instances (ie a pool). It is more or less the same as a component entry.
> >
> >The metainfo is the profile.
>
> Your definitions differ from mine then. Metainfo is meta information about
> type. (MOF Level 0 MetaData). It has 0 information about profile prototype
> or anything similar.
MOF?
> MetaData is the component profile.
>
> Entry is the runtime information about component. ie Actual Logger,
> Context, instance (or pool), dependency instance references etc.
>
> My model does not say anything about component profile prototype. I was not
> going to address it as I wanted to see the outcome of work that Peter is
> doing on phoenix and Stephen is doing on Merlin.
>
> The model also does not offer a COnfiguration or Parameters Schema yet
> (again I am waiting to see experimentation on Phoenix).
ah. These definitions aren't very clear from looking at the current
containerkit :/
I take it I should look at kernel.ComponentEntry....that's pretty devoid
of any explanation or contract atm...I take it the idea is to expand on
it once we know a bit more?
anyways, I sort-of get the direction headed and I'll start with throwing
in a bit of (javadoc) documentation in the general direction of
containerkit.
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
