> From: Alex Karasulu [mailto:[EMAIL PROTECTED]
>
> > This is how it would be done:
>
> Do you know how others do this if they do at all?
No.
> > Define a package org.apache.avalon.meta.dependency:
> >
> > public interface DependencyProvider {
> > ServiceDefinition[] provides ();
> > ServiceDefinition[] requires ();
> > }
> >
> > public class ServiceDefinition { ... }
>
> So the provider gives you a bunch of ServiceDefinitions.
> What are these service definitions? I think they are the
> meta info associated with a service right?
Yes.
> > public interface DependencyValidation {
> > public static final int VALID = 0;
> > public static final int INVALID = 1;
> > public static final int INDETERMINATE = 2;
> > public int validate ();
> > }
> >
> > public class DependencyValidationImpl implements
> > DependencyValidation {
> > /* default impl */
> > }
>
> Cool I follow this part just fine. Sounds sane and
> reasonable but let's not implement this over night. The
> implementation part is easy. What other ways are out there
> we need to do the research. Then let's get into the bowels
> of Merlin in a separate experimental branch of development
> and try to see if we can start to add the feature. In my
> opinion there is no need for a vote since this is a proof of
> concept branch of Merlin where we're demonstrating a feature.
> We can get Steve to help us out so we can introduce these changes.
>
> Then we can step back and take a look at the picture, decide
> to enhance it or come to a conclusion and have a vote to
> merge it into the main dev trunk.
>
> How's that for a plan?
Looks fine. I need to read up on Merlin in order to get the plan
worked out, though. We may have to start with a new architecture
and then implement Merlin-as-it-is-now on top of that, because
I think this is something that can't be bolted on.
We have to look over all features in Merlin, and then see how
these could be implemented as "aspects" (or whatever we'll
end up calling them), and figure out what the Aspect interface will
look like and so on...
> > OK, now, any ComponentHandler that wishes to be part of the
> dependency
> > validation must implement DependencyProvider. If you don't
> implement
> > it, fine - you're not part of the validation.
>
> Is the ComponentHandler ~= Appliance?
Yes.
> > The DependencyValidationImpl listens to events in the
> container - when
> > is a component handler added, when is one removed? It checks when a
> > handler has been added and updates the state - is it valid,
> invalid,
> > or indeterminate due to component handlers that don't participate?
> >
> > Then add one method to the container:
> >
> > Object Container.getAspect (Class aspectClass);
> >
> > So you add the aspect, add a lot of component handlers, and
> then you
> > get the aspect from the container, and call its validate() method.
> >
> > If you don't care for validation, then just don't add the aspect.
> >
> > If you're a ComponentHandler author, you can choose to
> participate in
> > validation or not by implementing/not implementing
> DependecyProvider.
> >
> > In fact, you don't have to care about the
> > org.apache.avalon.meta.dependency package at all.
> >
> > What do you think? (Not the implementation, but the concept.)
>
> Yes I like it a lot and think it's viable. My thoughts are
> inline. I want Steve and the others to help think it through too.
Note: The implementation I wrote was just a brain dump with a lot
of "fill in the blank here".
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
