Peter Donald wrote:
> At 03:10 AM 6/28/2002 +0200, you wrote:
>
>> The containerkit package provides a lot of the defintion of the
>> component contract based on defintions contains within an XML file
>> (the .xinfo). I'm currently working on a container that is a
>> component and the services it provides is based on assembly
>> instructions. In this case, the service information is not inside a
>> .xinfo file - it held inside an object model in the form of a
>> ComponentInfo instance.
>
>
> So the component is dynamically generated with a corespondingly
> dynamically generated info?
The component (as a container) will up services based on classpath and
an assembly document leveraging .xinfo information. The assembly
directives will declare which child components should be expostable as
opposed to private. So far this is classic container land stuff (expect
for the notion of exporting a service). We take this container, package
as a component with a .xinfo file. What is needed is the ability to
declare in the .xinfo file something like a ComponentInfo accessor from
which the exportable services and importable dependecies can be exposed.
For example, the default mechansism could be the ComponentInfoBuilder -
if ComponentInfoBuilder implementated a interface for aquisition of the
ComponentInfo instance. The pattern used for ComponentInfoBuilder could
then applied to alternative builders - enabling the sort of composition
I'm thinking of.
>
>
>> Keeping in mind that that the compoent in question can provide
>> service information based on static declarations in an assembly file
>> - I need to figure out how this information can be made available to
>> another container without supplying a .xinfo file.
>
>
> I am not sure it is possible unless we start defining Factorys for
> Avalon components. For a factory you pass in a implementation key
> (usually classname) and aquire an instance of type. The factory would
> also expose the MetaInfo associated with type.
No - I'm still at meta-land, no component instantiation. The action of
ComponentInfo (dependecies, services, etc.) creation is the point I want
to intercept as part of a "standard" containerkit meta
loading/validation process. This is needed to be able to plug the
component into something like SimpleServiceKernel and everything will
just work fine because the .xinfo for my component will declare the
ComponentInfo handler - using this information the kernel can delegate
the ComponentInfo creation to the handler. The kernel just gets back
the ComponentInfo and continues on as normal.
E.g.
interface InfoProvider
{
ComponentInfo getComponentInfo( Class class );
}
And in the .xinfo:
<component-info factory="MyInfoProvider"/>
Cheers, Steve.
--
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]>
