Berin Loritsch wrote:
+1 I also like the idea of a single container which can be configured to function inDevelopment Plan 1: We continue to support our existing projects while we start fresh on a new effort. The new effort will be a scalable container that follows a "profile". Basically the container will only use the features that are part of that profile and ignore everything else.
different environments. All of the code/products that I have out there make use
of the ECM and associated servlet package. I would hope for compatibility or at
least a fairly easy migration path.
I think that it is important that we at least try to continue using the Framework
code as is. That will make most components/services migrate cleanly.
I do wonder at how realistic it is to come up with the perfect container. No matter
what we create, there is always going to be a new idea that surfaces. Just think
about how many containers we have now.
Like is done with the separation between framework and excalibur, we really
need to focus on what is needed to implement components/services and what
is needed to implement the containers. Being able to make any component run
in any container would be nice. But containers are always going to have differing
features and the component model needs to support that.
Would it be possible to have a the concept of required versus optional lifecycle
interfaces in components? For example. LogEnabled is required. Instrumentable
is optional. If a component implementing LogEnabled is dropped into a container
which does not support logging, that component should not be allowed to be loaded.
If it is loaded, runtime exceptions will be thrown. If on the other hand the container
did not implement Instrumentable, the component would still function.
Component developers should not be required to deal with this themselves. We
should have a framework level class which would be used by all container
implementations to simply validate whether or not a component can be used by the
container. Before instantiating any components, the container would register its
feature set with the helper class. The class would then compare the registered
feature list with the features required by the component. (Would need to work
lifecycle extensions in here as well)
When I first started working with Avalon. There was basically just the ECM. All of
the excalibur code was separated in the all and scratchpad sub projects. This
made things very clear as to what was released and what was scratchpad code.
We all talked about "promoting" packages to the all project when they had been
reviewed by the community.
I would really like to see us return to such a model. Currently, there is no easy
way to tell what is scratchpad and what is released. When someone spends a
lot of time working on a project, they want to see it promoted as soon as possible.
Myself included. But I think it is good for the community to keep things separated
until the ideas have proven themselves.
Cheers,
Leif
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
