Berin Loritsch wrote:
>Quick question, how do we want to mark the entries for
>whether a class is an Avalon component or service?
>
>Right now, there are three ways:
>
>Name: org.apache.foo.MyComponentImpl.class
>Avalon-Block: true
>
>Name: org.apache.foo.MyComponentImpl.class
>Avalon: Type
>
>Name: org.apache.foo.MyComponent.class
>Avalon: Service
>
>
>Now, the new ComponentClassLoader in the container package
>handles all three of these--and it does not *require* you
>to have the ".class" ending (which I think is nice).
>
Sounds good.
>
>
>Another advantage to the "Avalon" attribute name is that we
>can only have one value for it. There is no way to mark
>something both a "Type" and a "Service". I see this as a
>definite boon.
>
I like this.
>
>
>BTW, where are we with making the Service an explicit type?
>I want Fortress to resolve all the Services *before* it
>resolves the Components.
>
The approach I would like to take here is to be able to declare a
service using an equivalent strategy to type declaration. The manifest
entry Avalon: Service suits me perfectly - I can use this to load a
service defintion <classname>.xservice. The service definition would
simply contain the attributes defintion for the service.
Example .xservice content
<service>
<attributes>
<attribute key="avalon:service.version" value="1.1"/>
<attribute key="avalon:service.description">
This is an example service defintion.
</attribute>
<attribute key="avalon:service.title" value="Sample Service"/>
<attribute key="avalon:service.name" value="sample"/>
</attributes>
</service>
In the type defintion would remain unchanged
<services>
<service>
<attributes>
<!--
additional attributes that are related to the service
implementation and deployment
-->
</attributes>
<reference type="org.apache.excalibur.playground.SimpleService"
version="2.3"/>
</service>
</services>
However, attributes declared within the type defintion would be
interprited as qualifiyers of the service implemetation.
Depedency declarations would remain unchanged. Again, the attributes
defined under the dependency represent constraints relative to a
implementation within the scope of the service defintion it refeences.
<dependencies>
<dependency>
<role>basic</role>
<reference type="org.apache.excalibur.playground.BasicService"/>
<attributes>
<!--
additional attributes that are related to the service
provision constraints
-->
</attributes>
</dependency>
</dependencies>
As you can see - the changes on the existing meta-info content is
minimal (mainly documetation of attributes and the fact that a reference
references a service declaration). New content would include the bulder
for the service meta-info object (which would basically leverage the
existing code), and a service meta-info object verifier..
Cheers, Steve.
>
>
>"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]>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
