Berin Loritsch wrote:
Berin Loritsch wrote:
Stephen McConnell wrote:
The specification is here: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
Thanks for the reading material ;P
I'll probably have some more questions later.
Ok. Now that I have looked over the stuff (JavaDocs weren't that helpful,
sorry), I do have some questions. Most of this is just spitting things
back in my own words to make sure I've got it.
To make sure I understand it properly, Merlin expects to find some values to authoritatively identify a JAR:
Extension-Name: avalon-framework Specification-Vendor: Apache Software Foundation Specification-Version: 1.0 Implementation-Vender-Id: org.apache Implementation-Vendor: Apache Software Foundation Implmentation-Version: 1.0
This is as a result of respecting the Java versioning spec listed above.
Quick Question: if we separate API and Impl into separate JARS do the
specification and implementation information get split
up accordingly (sharing the same extension name)?
No. The extension names are the keys that are shared across different implementations. For example, two different implementations of the framwork would use the same framework impl key. I.e. the framework has to deal with the potential for multiple solutions for a given dependency.
This is one of the problems I have with the current build procedure. Without seperating impl and api into seperate projects we cannot use build tools provided in maven to correctly handle the generation of basic manifest information nor corrrect structural dependency information. The solution to that is to define the impl and api as seperate projects.
If the JAR has the "Extension-List" attribute (with a space separated list),
then we identify a set of specifications we need to link to. IOW, it is
how we identify JAR dependencies.
Extension-List: foo
foo-Extension-Name: far-fetched
foo-Specification-Version: 1.0
foo-Implementation-Version: 1.0
foo-Implementation-Vendor-Id: org.apache
foo-Implementation-URL: http://www.apache.org/dist/avalon/foo/jars/foo.jar
As we can see by the above set of attributes (notice the "foo" prefix matches
the entry in the extension list), we can find a remote JAR with a particular
URL. The version info is used to determine the minimum acceptable version.
The Implementation-Vendor-Id is used ONLY if we want to limit the acceptable
candidate to something specified by the vendor ID.
To get the details - take a look at the Extension.java source in the merlin/extension package and look for the getCompatibilityWith method. This applies the policy that the extension name must match, that the specification version must be >=, and that the implementation vendor id must match. I happen to agree with the first two policy decisions but disagree with the third.
There is a specific set of rules for matching and determining if an update
is necessary. I assume that these are all followed Ok.
The rules on matching are a little fuzzy. For example the actual policies applied tend to vary across implememtation. I suspect this is more of a specification issues as opposed to implementation issue.
Lastly, do we respect
the sandboxing requirements of downloading remote code?
The extension package does not download remote code. In fact it only deals with the establishment of extension descriptions. It is up to a higher level application to determin actions to resolve unresolved dependencies. At this time the Merlin framework uses the extension framework to (a) expand a classpath, and (b) validate the classpath expansion. Active downloading could be included but a prerequisite is the inclusion of (c) a security model inside merlin container defintions, and (d) a repository trust management solution.
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]
