Hi all, I have some proposals for a set of useability enhancements to SimpleURIResolver that I think well worthwhile. It's a bit of a journey but if you're interested in URI resolving, please bear with me:
1) Catalog format #1 - resolving relative URLs: Background: At present, local references in the catalog must be either fully qualified file names/URLs or relative URLs. If relative, the value of the system resource org.apache.woden.resolver.simpleresolver.base (set programatically or as a jvm argument), is simply prepended to the reference to build a URL or filepath. Problems: a) very restrictive having just a single base location for all relative locations in the catalog b) we currently have an over-lax definition of what constitutes a URL for catalog local references. Filepaths can be given (in the form specific to the OS shell be used to run woden!). - Proposal: a) All local references (the RHS of a catalog entry; the resource to which we resolve) should adhere to strict URL formatting standards (the jar URL is allowed within this). URLs may be absolute (has a scheme) or relative (no scheme). b) Relative URLs will be "resolved" (overloaded word!) to absolute URLs by looking for them via a URLClassLoader. This class loader will be derived from the Class classloader and additional URL paths can be specified using system property org.apache.woden.resolver.simpleresolver.baseURLs (which replaces org.apache.woden.resolver.simpleresolver.base above). These additional paths can represent directories or specific jar files. Example catalog entries are: # relative http\://test.com/importinterface.wsdl=org/apache/woden/resolver/resources/interface.wsdl http\://www.w3.org/2000/08/XMLSchema.xsd=schema/XMLSchema.xsd # absolute http\://wibble.com/wobble.wsdl=file:///c:/myimagedir/org/apache/woden/resolver/resources/wobble.wsdl Example baseURLs property: Use : -Dorg.apache.woden.resolver.simpleresolver.baseURLs="file:///mydirectory/myschemas/;file:///mydirectory/schema1.jar;file:///mydirectory/schema1.jar" This states that files for relative URLs in the catalog will be searched for in the classpath (implicitly including woden.jar), the directory "myschemas", then the jar files schema1.jar and schema2.jar, in that order. (Leaving the property unset will cause the classloader classpath to be searched only) Benefits: a) provides a classpath-like mechanism for locating local URLs, for example allowing local copies of wsdl2 & xmlschema schemas to be embedded in woden.jar and loaded from there. b) removes the untidy reliance on OS-specific filepaths to describe relative locations of resources such as schema files. 2) Catalog format #2 - resolving partial URLs representing hierarchies: Background: Currently each URL to be resolved must be stated explicitly in the catalog file. Problem: This is high-maintenance when a large number of URLs are involved (eg. the W3C documents tests) Proposal: Provided a catalog syntax for root URLs to be resolved. For example, a catalog entry like: http\://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/documents/=file://c:/mydownloads/w3ctests/desc/test-suite/documents/ will resolve all URLs starting with http\://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/documents/ to the corresponding local location under file://c:/mydownloads/w3ctests/desc/test-suite/documents/ Note the final "/" indicates this form of URL to the resolver. Benefit: Low maintenance catalogs where an entire hierarchy of URLs are to be mirrored onto the local filesystem, containing many wsdl or schema files (such as the w3c tests). 3) System Catalog Background: Commonly used schema, such as the wsdl and xmlschema schema, should always be resolved locally, primarily for performance reasons. Problem: The user must explicitly declare these resolves in the catalog. These resolves should take place under the covers Proposal: Create a second catalog file, the System Catalog which resides in a known location (probably woden.jar, alongside the local wsdl2/ xml schema files) which contains those essential URL resolves. This would be loaded "invisibly" by the URIResolver ctor, regardless of whether the user specified their own (user) catalog. The user catalog can still override system catalog entries if desired, and the system catalog can even be altered or removed (though we would not advocate this!). Benefits: a) Standard schema are automatically resolved b) The exact resolves provided by the system catalog are hidden, but can be inspected if so needed. This preserves flexibility and visibility. I played with (1) over the weekend and have a sandbox implementation. (3) is a trivial change. (2) requires some work, say a day. As well as making the simple resolver more usable, items (1) and (2) together form a solution for WODEN-83. Therefore I wanted to post this to the list for discussion before potentially & inadvertently "stomping over" existing JIRAs My apologies for such an epic posting. All feedback extremely welcome, as ever. Kind Regards, Graham. _____________________________________________ Graham C Turrell CEng, MBCS Chartered IT Practitioner WebSphere ESB Foundation Technologies DE3F16 / MP 211 IBM Labs Hursley Park Winchester, Hampshire England. SO21 2JN Tel +44-(0)1962-815018 email: [EMAIL PROTECTED] "No army can withstand the force of an idea whose time has come.". -Victor Hugo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
