So far, we have had a lot of conversations which have spun our wheels
on how we can refine Avalon even more. So far, everyone is largely
happy with what we have. This is a good thing. Therefore, we should
place any last notes we have in the A5 proposal directory just to
table the discussion.
The next course of action is how do we improve what we have. We
already have a number of deprecations, so I want to keep that to a
minimum. Before we deprecate the release methods, we should put in
the javadocs that designing a component so that it is *required* to
be released is considered bad practice. The important thing is that
we need to document how it can be done satisfactorily.
Secondly, we need to revise our naming policy so that the use of the
*Selector is no longer needed. I.e. make it the norm that we state
our dependencies as ROLE + "/constraint". NOTE: I know Stephen
disagrees with using the interface name at all, but many people find
it a useful way of reducing the time it takes for a new developer to
maintain existing components. Until the meta-model is fixed with the
javadoc extensions it should be the preferred way of doing things.
There is less confusion over exactly which connection-manager interface
the component wants to use--until the meta-model is done.
Our focus should be now on refining the meta-model, and refining the
container/component contracts. The developer needs to see *in the
implementation* the interface that the component depends on, and the
creational policy for the component.
Lastly, I would like to bring two more points to the table:
* We should consider an additional lifecycle for a persistence layer.
It is the container's responsibility to save the information, but
for many types of components it would be useful to save configuration
changes made during runtime or saving datasets. I will come up with
a proposal in a separate thread.
* reference implementation for a session object. This is how stateful
session beans (EJB spec) and servlets manage state in an otherwise
stateless environment. It is also how they can manage to be used by
multiple threads or contexts of execution simultaneously. We should
put together a reference implentation of this in excalibur and then
vote whether it should be incorporated as part of Framework (at least
the defining interfaces).
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
