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 15:56:08 UTC
Do we have a particular classloader for containers?
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?
"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: new ClassLoader in container (was RE: Do we have a particular
classloader for containers?)
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>I added a classloader to obtain the list of types/services/blocks
>from the classloader manifest entries. I based the code on a
>*portion* of Stephen's TypeManager.
>
>For each "Name:" entry in the classloader, we check for the following
>conditions:
>
>Avalon-Block: true -> add to list of Block names
>Avalon: Type -> add to list of Type names
>Avalon: Service -> add to list of Service names
>
>Please note that I did not force any affinity to ContainerKit or
>Meta packages. All lists are just the String names (with the
>".class" endings stripped off). (actually it is implemented
>as a Set so there is only one instance of a name in the classloader).
>
>
Berin:
I've been looking over the ComponentClassLoader and one thought that
occured to me was that we could seperate out the jar scan fanctionality
into a URL handler. Consider the following code:
URL url = new URL("jar:file:/home/demo.jar!/", new PackageHandler() );
PackageURLConnection connection =
(PackageConnection)url.openConnection();
String[] types = connection.getTypeEntries();
String[] services = connection.getServiceEntries();
String[] blocks = connection.getBlockEntries();
This would enable seperate of "what is inside the jar" to the URL
connection object which is desirable when thinkning about management
tools that want this information without necessarily loading the jar
file into a classloader.
>The ClassLoader behaves exactly like the URLClassLoader with
>the exception of being able to pull the block/type/service names.
>
>
>
>BTW Stephen, you might want to look at breaking out some functionality
>in the TypeManager/ContainerManager into helper classes. The *abstract*
>TypeManager is 683 lines of code (comments included), and the concrete
>ContainerManager that extends TypeManager is 1,615 lines of code.
>That's
>a ton of code to sift through in one file. Perhaps this classloader
>will help in that endeavor...
>
>
Agreed.
I've been holding off refactoriing that part of the sytem until I have
completed deployment testing on a lange distributed service management
application. Once that's done I'll be keen to get into some restructuring.
Cheers, Steve.
>
>--
>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>
new ClassLoader in container (was RE: Do we have a particular classloader for containers?)
Posted by Berin Loritsch <bl...@apache.org>.
I added a classloader to obtain the list of types/services/blocks
from the classloader manifest entries. I based the code on a
*portion* of Stephen's TypeManager.
For each "Name:" entry in the classloader, we check for the following
conditions:
Avalon-Block: true -> add to list of Block names
Avalon: Type -> add to list of Type names
Avalon: Service -> add to list of Service names
Please note that I did not force any affinity to ContainerKit or
Meta packages. All lists are just the String names (with the
".class" endings stripped off). (actually it is implemented
as a Set so there is only one instance of a name in the classloader).
The ClassLoader behaves exactly like the URLClassLoader with
the exception of being able to pull the block/type/service names.
BTW Stephen, you might want to look at breaking out some functionality
in the TypeManager/ContainerManager into helper classes. The *abstract*
TypeManager is 683 lines of code (comments included), and the concrete
ContainerManager that extends TypeManager is 1,615 lines of code.
That's
a ton of code to sift through in one file. Perhaps this classloader
will help in that endeavor...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Do we have a particular classloader for containers?
Posted by Stephen McConnell <mc...@apache.org>.
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: <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>
Re: Do we have a particular classloader for containers?
Posted by Peter Donald <pe...@apache.org>.
On Wed, 11 Sep 2002 23:56, 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.
You should not be extending ClassLoader to do this. It would make far more
sense to have a utility method like
String[] components = MyUtil.getComponents( getClassLoader() );
By doing it through extension you make it impossible to subclass ClassLoader
which is needed if you want to do thing like advanced policy management.
--
Cheers,
Peter Donald
------------------------------------------------------
Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is
the task of journalists and historians to rectify
this error."
------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>