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/12 23:13:51 UTC
Merging concepts of marking components for the container
Right now we have two ways of determining all the components and
services,
other than the ECM brute force way. Either using the Manifest, or using
a couple of XML files. Honestly, either way is perfectly fine with me,
as long as we are consistent and provide the proper tools.
I have a couple of questions nonetheless. #1 Can we standardize? #2
How do we determine a new set of components? Let me break out the two
questions in more detail below:
#1 Can we standardize?
If we use the Manifest file, then I would like to have entries like
this:
Avalon-Type: Service|Component|Extension|ExtensionHandler
That way we know if we are dealing with an interface (Service), an
implementation (Component), and extension marker class (Extension),
or an extension handler (aka Creator or Accessor) class
(ExtensionHandler).
If we use an XML file, can we limit ourselves to only one? XML is very
flexible, and I would not mind having something like this:
<avalon-types>
<service interface="org.apache.infomover.input.Input"/>
<component class="org.apache.infomover.input.DelimitedStreamInput"/>
<component class="org.apache.infomover.input.CSVStreamInput"/>
<service interface="org.apache.infomover.output.Output"/>
<component class="org.apache.infomover.output.DelimitedStreamOutput"/>
<component class="org.apache.infomover.output.CSVStreamOutput"/>
<extension
interface="org.apache.excalibur.instrument.Instrumentable"/>
<extension-handler
class="org.apache.excalibur.conatiner.InstrumentCreator"/>
</avalon-types>
That would be enough for us to gather everything we need just like the
Manifest entries.
#2 How do we determine a new set of components?
The root container can scan everything in
System.getProperty("java.class.path");
to determine if there are any components/etc. in any of the jars in the
classpath. However, it is unclear about any child containers. If a
container
manages its own classloader, everything is happy. If it uses the
classloader
that it was given, then we are SOL. How do we know what is new? How do
we
find the new services, etc. that were loaded after the system is up and
running?
Think of the Cocoon case where we aren't necessarily loading new
components
(although it is possible), but we are managing new role mappings. All
the
classes have been loaded by the Servlet engine, so it is a question of
either
preknowing the classes, or pulling them from a configuration file. If
we
had something along the lines of a Jar specification for Avalon
components,
we need to be able to get at any specific entry, or easily merge them
all....
Hopefully I am making some sense here.
"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: Merging concepts of marking components for the container
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>>
>> #1 Can we standardize?
>>
>>
>> If we use the Manifest file, then I would like to have entries like
>> this:
>>
>> Avalon-Type: Service|Component|Extension|ExtensionHandler
>>
>
> I really don't think we need catagories beyond Service and Type
> (Component). The other catagories you mentioned fall into these two
> categories.
Right, but they do require special handling, so I would prefer to get
those set up prior to the components, et. al. That would allow me to
do it quickly.
>> That way we know if we are dealing with an interface (Service), an
>> implementation (Component), and extension marker class (Extension),
>> or an extension handler (aka Creator or Accessor) class
>> (ExtensionHandler).
>
> This can be determined a build time. All we need to know is the pointer
> to the description. The numbers of pointers corresoponds to the number
> of descripotor types. I.e. a descriptor for a Type (Component), a
> descriptor for a Service. Once the managing object has thiis it is then
> over to a builder implemenrtation to handle questions such as "is this
> an extension handler component" or "is this an extension maker interface
> service", etc.
:/ Ok.
>> If we use an XML file, can we limit ourselves to only one? XML is very
>> flexible, and I would not mind having something like this:
<snip/>
>> That would be enough for us to gather everything we need just like the
>> Manifest entries.
>
> I would prefer to see one source (e.g. Manifest or single XML resource).
Hense the point of the message. We already have two: Manifest and XML.
>> #2 How do we determine a new set of components?
>>
>>
>> The root container can scan everything in
>> System.getProperty("java.class.path");
>> to determine if there are any components/etc. in any of the jars in the
>> classpath. However, it is unclear about any child containers. If a
>> container
>> manages its own classloader, everything is happy. If it uses the
>> classloader
>> that it was given, then we are SOL. How do we know what is new? How do
>> we
>> find the new services, etc. that were loaded after the system is up and
>> running?
>>
>>
>
> I think this is a seperate issue. The Manifest or XML index is simply
> the declaration of the statically bundles services and component types.
> Its not the definative record of available services and components. The
> definitive information only comes together after validation and assembly.
Ok.
>> Think of the Cocoon case where we aren't necessarily loading new
>> components
>> (although it is possible), but we are managing new role mappings. All
>> the
>> classes have been loaded by the Servlet engine, so it is a question of
>> either
>> preknowing the classes, or pulling them from a configuration file. If
>> we
>> had something along the lines of a Jar specification for Avalon
>> components,
>> we need to be able to get at any specific entry, or easily merge them
>> all....
>>
>> Hopefully I am making some sense here.
>
> I not really getting the issue. If you have something dynamic then
> presumably you have a class monitoring a dynamic source and pushing this
> into a classloader. This is changing the registry of real types and
> services which may be of interest to a container - but generally
> speaking this is picked on on demand - e.g. when requersting a new
> component (instance of a type) the assembly of that component will take
> advantage of any new content.
Ok.
--
"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: Merging concepts of marking components for the container
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>Right now we have two ways of determining all the components and
>services,
>other than the ECM brute force way. Either using the Manifest, or using
>a couple of XML files. Honestly, either way is perfectly fine with me,
>as long as we are consistent and provide the proper tools.
>
>I have a couple of questions nonetheless. #1 Can we standardize? #2
>How do we determine a new set of components? Let me break out the two
>questions in more detail below:
>
>
>#1 Can we standardize?
>
>
>If we use the Manifest file, then I would like to have entries like
>this:
>
>Avalon-Type: Service|Component|Extension|ExtensionHandler
>
I really don't think we need catagories beyond Service and Type
(Component). The other catagories you mentioned fall into these two
categories.
>
>That way we know if we are dealing with an interface (Service), an
>implementation (Component), and extension marker class (Extension),
>or an extension handler (aka Creator or Accessor) class
>(ExtensionHandler).
>
>
This can be determined a build time. All we need to know is the pointer
to the description. The numbers of pointers corresoponds to the number
of descripotor types. I.e. a descriptor for a Type (Component), a
descriptor for a Service. Once the managing object has thiis it is then
over to a builder implemenrtation to handle questions such as "is this
an extension handler component" or "is this an extension maker interface
service", etc.
>If we use an XML file, can we limit ourselves to only one? XML is very
>flexible, and I would not mind having something like this:
>
><avalon-types>
> <service interface="org.apache.infomover.input.Input"/>
> <component class="org.apache.infomover.input.DelimitedStreamInput"/>
> <component class="org.apache.infomover.input.CSVStreamInput"/>
>
> <service interface="org.apache.infomover.output.Output"/>
> <component class="org.apache.infomover.output.DelimitedStreamOutput"/>
> <component class="org.apache.infomover.output.CSVStreamOutput"/>
>
> <extension
>interface="org.apache.excalibur.instrument.Instrumentable"/>
> <extension-handler
>class="org.apache.excalibur.conatiner.InstrumentCreator"/>
></avalon-types>
>
>That would be enough for us to gather everything we need just like the
>Manifest entries.
>
>
I would prefer to see one source (e.g. Manifest or single XML resource).
>
>#2 How do we determine a new set of components?
>
>
>The root container can scan everything in
>System.getProperty("java.class.path");
>to determine if there are any components/etc. in any of the jars in the
>classpath. However, it is unclear about any child containers. If a
>container
>manages its own classloader, everything is happy. If it uses the
>classloader
>that it was given, then we are SOL. How do we know what is new? How do
>we
>find the new services, etc. that were loaded after the system is up and
>running?
>
>
I think this is a seperate issue. The Manifest or XML index is simply
the declaration of the statically bundles services and component types.
Its not the definative record of available services and components.
The definitive information only comes together after validation and
assembly.
>Think of the Cocoon case where we aren't necessarily loading new
>components
>(although it is possible), but we are managing new role mappings. All
>the
>classes have been loaded by the Servlet engine, so it is a question of
>either
>preknowing the classes, or pulling them from a configuration file. If
>we
>had something along the lines of a Jar specification for Avalon
>components,
>we need to be able to get at any specific entry, or easily merge them
>all....
>
>Hopefully I am making some sense here.
>
I not really getting the issue. If you have something dynamic then
presumably you have a class monitoring a dynamic source and pushing this
into a classloader. This is changing the registry of real types and
services which may be of interest to a container - but generally
speaking this is picked on on demand - e.g. when requersting a new
component (instance of a type) the assembly of that component will take
advantage of any new content.
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: Merging concepts of marking components for the container
Posted by Peter Donald <pe...@apache.org>.
On Fri, 13 Sep 2002 07:13, Berin Loritsch wrote:
> If we use the Manifest file, then I would like to have entries like
> this:
>
> Avalon-Type: Service|Component|Extension|ExtensionHandler
Why restrict it to these types? Does not ExtensionHandler imply Component?
Could you not determine Extension/ExtensionHandler via inspection of the info
files?
> If we use an XML file, can we limit ourselves to only one?
I have been flip-flopping between one xml file with just two elements
(component and service) and two xml files with extensible set of types. If
you have a policy of one classloader per jar, it makes it easier if you
separate the xml files. (Or you will need two passes - one to pick up
services and one to pick up components).
I ended up separating them similar to way Myrmidon does (which I think was
inherited from Cocoon). Something like
roles.xml:
<roles>
<role shortName="component">
<role shortName="service">
<role shortName="extension" impl="o.a.a.Extension">
</roles>
types.xml:
<types>
<component impl="o.a.MyComponent"/>
<component impl="o.a.MyComponent2"/>
<service impl="o.a.MyService"/>
<extension impl="o.a.MyExtension"/>
</types>
I have also experimented with just a types.xml that had <type/> elements that
allowed you to define "category". Not sure on the best approach.
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>