Berin Loritsch wrote:
Stephen McConnell wrote:
Berin Loritsch wrote:
Stephen McConnell wrote:
What I'm pointing out is that the Merlin usage of manifest information has nothing to do with the registration of type or service information. It has everything to do with structual dependency management done in a way that is 100% consistent with the java operational extensions specification.
Really? Now you peaked my curiosity, and I want to know more. Got a
URL that explains how things work, or can you give a brief overview?
The specification is here: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
The implementation is in merlin/extension and merlin/extension-spi.
http://avalon.apache.org/sandbox/merlin/api/org/apache/avalon/extension/package-summary.html
http://avalon.apache.org/sandbox/merlin/api/org/apache/avalon/extension/manager/package-summary.html
http://avalon.apache.org/sandbox/merlin/api/org/apache/avalon/extension/manager/impl/package-summary.html
Thanks for the reading material ;P
I'll probably have some more questions later.
Merlin (like Phoenix) colocates meta-info descriptors with the class they are describing - e.g. <classname>.<extension>. Phoenix accesses this inforation on demand based on static descriptors. Merlin scans jar files for type and service descriptors, loads then in a repository, and uses this repository to provide information about available component solutions to higher level services.
And how does this affect startup times? I think one of the chief concerns with
the "Attributes Proof of Concept" thread was the startup time if we went through
all the public classes and discovered the meta info at that time.
If you are using a explicit assembly model (e.g. Phoenix) you don't need to scan - instead you just grap the resource you need when you need it. If you are using automated assembly then your assembly system needs a directory of available types and services. To construct that directory you need to scan the classpath which means scanning jar files and recursively scanning directories in a classpath for type and service definitions. This has nothing to do with classloading. Instead, you read the jar file entry names and register type and service definitions. Typically the number of defintions is very small as compared to number of classes - often just a case of 3-4 type defitions (e.g. cornerstone examples are typically between 1 and 3 type defintions per jar file.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
