On Sat, 7 Sep 2002 22:34, Igor Fedorenko wrote:
> Peter Donald wrote:
> > On Sat, 7 Sep 2002 20:03, Paul Hammant wrote:
>
> [skipped]
>
> > It will trim down when we move to new component model. I don't think
> > there is any need to change anything until then.
>
> Where can I find description of this "new component model"? And where
> can I find information about future directions of avalon/phoenix
> development in general?
There is no central place for this sort of information. It is sort of
scattered through all our mailing lists. We sort of have a list of things to
do in Bugzilla. You can see this list by clicking on TODO list on Phoenix
website.
That list of things is not complete. Over the next few days I may try to fill
it up with some of the other things we need plan to do over time.
The new component model is one of those things that we plan to do. Phoenixs
model (essentially the BlockInfo files and classes) is great for what Phoenix
does but it is not extensible enough to handle all component needs. For
example when we decided we needed to expose management services we had to go
in and change the BlockInfo file format. I suspect similar things will occur
when we start supporting factorys, interceptors and so forth.
Rather than constantly extending our model, we can instead choose to use a
generic and more comprehensive mechanism and thats where the new Component
model comes in.
Essentially for every resource that a component needs we have a mechanism for
allowing the component to declare that it requires that resource. Currently
Phoenix limits this declaration of resource requirements with respect to
service dependencies. The new model will allow us to declare requirements on
context entrys, loggers etc.
To make it more extensible we plan to allow all resource requirement
declarations to be "extended" by a set of attributes. These attributes are
key-value pairs that allow you to extend the model in arbitrary ways. Each
key is in a namespace and can extend things for a particular domain.
For example, in your case you want to add security when calling services. In
this case you would define a set of security keys such as
sec:permission (name a permission needed by caller to call method)
sec:role (name a role the caller requires to call method)
sec:run-as (the subject that the method is called as)
etc.
Then you would associate them with a service declaration like
<service name="org.apache.MyService">
<attributes>
<attribute name="doc:display-name" value="My Groovy Service"/>
<attribute name="sec:role" value="admin"/>
<attribute name="sec:run-as" value="Fred"/>
</attributes>
</service>
Each container could choose to implement these requirements differently. In
the case of Phoenix we would write an interceptor that knew about the "sec:"
namespace and could handle it appropriately.
You can find the start of this work in CVS in "jakarta-avalon-excalibur/info".
However it is still going to change a little. In the current info package
there is only ComponentInfo objects (equivelent to Phoenix BlockInfo).
However in the future we plan to add ServiceInfo object (that describes
metadata about a service, independent of any particular implementation).
A lot of our thinking is inspired by some of the work done by MS with their
attribute based development. If you are interested in that you can look at
avalon-dev mail archive for a thread "[AvaloNET] Where two worlds collide...
not" which points a few links.
Anyways I will add some more details to the TODO list over next few days and
hopefully that will give you a bit of an idea about where we are going.
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
