Lawrence,
Provided B.wsdl doesnt appear anywhere on LHS of any catalog entry, B.wsdl
will be taken as relative to the (possibly resolved) location of the
importing document, just as it does at present.
In other words with (1) , as now, no explicit resolving is done by the
resolver on B.wsdl . The Woden import mechanism handles this bit.
I can easily demonstrate this with examples and will try some additional
tests on my sandbox to be 100% sure.
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
Lawrence Mandel
<[EMAIL PROTECTED]
om> To
[email protected]
27/11/2006 16:15 cc
Subject
Please respond to Re: Suggested enhancements for
[EMAIL PROTECTED] SimpleResolver
he.org
Graham,
WRT 1, does this affect the way in which a relative WSDL import statement
location is resolved? Will the location still be resolved relative to the
WSDL document that contains the import. For example, if A.wsdl contains an
import statement with a location B.wsdl, will it be able to resolve the
relative location?
Lawrence
Graham Turrell
<[EMAIL PROTECTED]>
To
[EMAIL PROTECTED]
11/27/2006 10:07 AM g
cc
Please respond to Subject
[email protected] Suggested enhancements
for SimpleResolver
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
