Re: Suggested enhancements for SimpleResolver

Arthur Ryman Mon, 27 Nov 2006 11:14:02 -0800

Graham,

We need to be clear on the behavior of the resolver.

IMHO, the resolver should only resolve absolute URIs. It should only be
passed absolute URIs. The application should convert all relative URIs to
absolute URIs before retreiving them. The semantics of relative URIs
depends on the application. For example, a relative URI might be resolved
wrt the URI of the containing document, or there might be an xml:base
attribute that defines the base URI.

The resolver should only resolve URIs that are explicitly listed in the
catalog, i.e. just because a resource happens to be in the same directory
as another entry in the catalog, that doesn't mean the resolver should
return it.

Does this agree with your understanding?

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]

Graham Turrell <[EMAIL PROTECTED]>
11/27/2006 01:07 PM
Please respond to
[email protected]

To
[email protected]
cc

Subject
Re: Suggested enhancements for SimpleResolver

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.