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:[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]>
