> > From: Alex Karasulu [mailto:[EMAIL PROTECTED]
> >
> > > myContainer.addAspect(new DependencyValidation());
> >
> > Now this is very interesting. You're suggesting that
> > dependency checks are a feature of the container? I think I
> > like this. It's a most excellent way to take an intertwined
> > aspect of a container and separate it.
>
> This is how it would be done:
Do you know how others do this if they do at all?
>
> You have two things: ComponentHandlers and Aspects. Component
> handlers manage components, and Aspects are system-level plugins
> that have access to all componenthandlers in the system.
>
> 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?
>
> 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?
> 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?
> 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.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
