new ClassLoader in container (was RE: Do we have a particular classloader for containers?)

[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: new ClassLoader in container (was RE: Do we have a particular classloader for containers?)

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