> MetaInfo
> --------
>
> Lets assume we can come up with a central container. First thing we need to
> do is to is externalize metadata for all the components. This is painful to
> maintain so we will need to use XDoclet to annotate our code.
I'm all for presenting XDoclet to maintain metainfo as an option as
opposed to the only way. The current setup where metainfo files are
generated from javadoc is nice; as you have the option of using some
other tool (say a rich wizard-based GUI ;) instead.
> With enough annotations you could almost validate the entire sitemap prior
> to deploying it which would probably save a lot of headaches over time.
is the current metainfo material you guys are writing startup-only? It
has been said cocoon's sitemap changes at runtime so it'd be best if the
metainfo were decoupled from the stage an application is in.
> So the first part of our strategy to moving towards a single container is
> creating a generic MetaInfo infrastructure.
yup.
> Component/Assembly Profile
> --------------------------
Assembly Profile I like, "Component Profile" I find a very confusing
term.
> Component Entrys
> ----------------
>
> When a container is managing a component it creates an Entry per component.
> The Entry manages all the runtime information associated with a component.
not the Assembly Profile?
> The heuristic is currently governed by a combination of things I believe.
> It has a policy attribute in MetaInfo of dependecyDescriptor that it can
> use, it also makes sure that no circular dependencies are created and in
> reality the evaluation process could include oodles more variables. So lets
> generalize it to the following interface
>
> public interface DependencyEvaluator
> {
> int evaluate( ComponentMetaData consumer,
> DependencyDescriptor dependency,
> ComponentMetaData candidate );
> }
generalize pattern == cool.
generalize interface/formalize ?= are we ready yet?
> Handlers
> --------
>
> Each component may have what we call a different "lifestyle". ie Components
> may be single-client, singl-threaded, pooled, "singleton" etc. For each of
> these different lifestyles we are going to need a slightly different
> architecture via which to aquire the component.
we also need to define these lifestyles as part of the framework
metainfo contracts. Otherwise reuse goes out the window again. I'm all
for specifying a few more than would be necessary in brilliant COP if it
means framework users won't have to extend.
> The component may still be passed through standard lifecycle process and
> described by standard Profile and standard MetaInfo but it will have a
> different handler. The handler will enforce the different lifestyle.
seems to me that the mapping we do is
Container --- use to manage Component ---> Handler
|---- create based on metadata -----^
(lifestyle is metadata). Mapping between handler class and component
would probably be best if based on ComponentMetaData instead of on just
"lifestyle".
> The handlers is one of the main places where the containers will differ.
> Some will offer pooling and advanced resource management. Others will proxy
> access to components, maybe offering interceptors etc.
what is the minimum? ie what should the-other-leos MicroContainer
support?
> The Component/Application Profile classes provide a basis for all the
> Profile information. However it is possible that some containers will
> extend these classes to provide specific information relevent only to the
> particular container. However for many containers (ie Phoenix and Fortress)
> the base Profile classes should be sufficient.
do we make it a specification of the standard Profile classes that they
are sufficient for Phoenix/Fortress (or do we specify phoenix/fortress
don't support more than the standard Profile). I'd like that.
> Shared Container Parts
> ----------------------
>
> There is significant overlap in the code for writing the container. So how
> do we go about sharing it all?
>
> * All containers can share the metainfo code (from containerkit)
> * All containers can share the lifecycle processing code (from containerkit)
> * Dependency traversal can be shared by all containers (from containerkit)
> * Merlin and Fortress should definetly share the "auto-assembly" utility
> classes.
> * Phoenix and Merlin can share the Handler/ComponentEntry part of container
seems to me the basic definition of Entry
public interface Entry
{
ComponentMetaData getMetaData();
RuntimeContext getRuntimeContext();
Handler getHandler();
}
or something similar could be common to many containers (ie
Handler/ComponentEntry stuff can partially be in containerkit)
> Theres the possibility that we may be able to share some of the other bits
> but thats something we can think about later.
'kay.
> Benefits of all this?
> ---------------------
>
> The biggest benefit of all this is that we will finally have the ability to
> write components and transparently deploy them into other containers with
> very little effort. It is likely that there will still be some container
> specific jazz in some components but we can get at least 90% cross
> container compatability.
>
> So that means Myrmidon will be able to use Cocoon services (yea!), Phoenix
> will be able to use Merlin services and all the other combinations.
and then what happens to these services and components? We can either
put them all in one place, or just make a reference to all of them in
one place. Need to do that though. No reuse if you don't know there is
something to reuse.
My feeling is it would be coolest if they'd all be in commons (or our
own commons, ie excalibur, if that remains problematic).
> It is not perfect, we have not got no grail but it is as close as we are
> going to get right now. We specify just enough that we can achieve 90%
> component portability between containers but we still leave room for
> different containers being customized for different things and specializing
> in different areas.
>
> Thoughts?
Generally, I like. Specifically, well, some points as noted above and
I'm sure there'll be more when I dive into actual code ;)
grz,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
