avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Do we have a particular classloader for containers?
Date Wed, 11 Sep 2002 14:47:33 GMT


Berin Loritsch wrote:

>I would like to have an AvalonClassLoader that we can use to get all the
>types from the classlaoder.  Since we have special class meta info
>stored
>in the Manifest.mf file for which classes are components (and RSN which
>interfaces are services), It would really help container developers if
>they could grab an array or list of classes in the classloader that are
>Services/Components.
>
>For instance:
>
>AvalonClassloader m_loader = new AvalonClassLoader( jarFileName );
>
>String[] services = m_loader.getServices();
>
>for (int I = 0; I < services.length; I++)
>{
>    InputStream is = m_loader.getResourceAsStream( services[I] );
>    // perform service validations
>}
>
>String[] components = m_loader.getComponents();
>
>for (int I = 0; I < components.length; I++)
>{
>    InputStream is = m_loader.getResourceAsStream( components[I] );
>    // perform component validations
>}
>
>Has anyone done something like this?
>

Hi Berlin:

The Merlin container provides a type manager to each container.  A type 
manager is an extended classlodaer that basically lets you locate types, 
profiles, and resources based on dependencies.  The Merlin type manager 
is implemented under the following two classes:

    org.apache.excalibur.merlin.assembly.TypeManager

      * created with a classpath and extension library
        meta-data criteria
      * maintains a validated type registry based on the
        manifest declarations
      * uses the excalibur/meta package

    org.apache.excalibur.merlin.assembly.ContainerManager
    (extends TypeManager)

      * maintains a registry of Profiles (the instantiation
        criteria and the reference to its associated type)
      * maintains a registry of Resource instances (something
        equivalent to an object reference that can be passed
        around without instantiating the component)
      * handles service selection mechanics
      * supports pluggable resource factories which basically
        enables different remote distribution transport
        mechanisms

Collectively, these two classes encapsule the assembly process used 
inside Merlin.  Currently the assembly mechanism a restriicted to 
statically declared services (i,e. services derived from the 
implementation of a work interface by a class).  I am currently working 
on dynamic service assembly assitions - i.e. the ability of a component 
to act as a service factory - service are declared in the same way, but 
I'm using attributes on the service defintion to declare that the 
service is factory based.  I'm also working on service descriptor 
propergation across containers hosted under different JVMs, enabling the 
creation of dependency solutions that can cross machine boundaries.  

All of this has a reasonable impact on the type and profile management 
content - as such this area of the API is a moving target.

Changes/evolution on the short-term agenda include:

  * collapsing TypeManager and ContainerManager into a single class
  * islation of control/system functions from type management functions
  * general API simplification
  * re-cut the stage/extension management by folding these into
    services and depedencies, but adding service and depedency
    qualifiers that descripe the functional role (i.e. classic
    service, extension service, etc.)
  * incorporation of dynamic services at the profile level
  * addition of depedency resolution using dynamic and static service
    declarations
  * code examples and a lot more documentation
  * general thinking about dynamic dependency declaration

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:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message