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