You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/09/11 22:45:05 UTC
Marking components/Services in the manifest entries
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).
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.
BTW, where are we with making the Service an explicit type?
I want Fortress to resolve all the Services *before* it
resolves the Components.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Marking components/Services in the manifest entries
Posted by Peter Donald <pe...@apache.org>.
On Thu, 12 Sep 2002 06:45, Berin Loritsch wrote:
> Quick question, how do we want to mark the entries for
> whether a class is an Avalon component or service?
Not using a manifest. Currently I am using two descriptors;
* META-INF/avalon/services.xml
* META-INF/avalon/components.xml
Each are justa simple list of things like
<services>
<service impl="org.apache.avalon.MyService"/>
</services>
<components>
<component impl="org.apache.avalon.MyComponent"/>
<component impl="soap:resource://org/apache/avalon/MyComponent-soap.xml"/>
</components>
> BTW, where are we with making the Service an explicit type?
> I want Fortress to resolve all the Services *before* it
> resolves the Components.
It is a good idea. I haven't figured out anything that that I am happy with
yet. Essentially all I currently have is a "ServiceInfo" that containers a
"ServiceDescriptor". I have played with adding Method/Operation/Function
Descriptors but nothing useful came out of that yet.
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
excalibur/meta service addition
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>BTW, where are we with making the Service an explicit type?
>I want Fortress to resolve all the Services *before* it
>resolves the Components.
>
Have just updated excalibur/meta to include a seperate service
meta-info object, associated builders, and DTD.
The builder follows the same pattern as the Type builder:
ServiceBuilder builder = new ServiceBuilder();
builder.enableLogging( logger );
Service service = builder.build( classname, classloader );
The resulting service object contains a classname, version and
attributes. The XML used to declare the service is as follows:
<service>
<version>1.2</version>
<attributes/>
</service>
Have also updated Merlin to to support loading and validation of
service descriptions based on Avalon: Service manifest declarations.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Marking components/Services in the manifest entries
Posted by Stephen McConnell <mc...@apache.org>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>