On Sep 6, 2006, at 11:44 AM, Yang ZHONG wrote:
I assumed "with relative URLs being resolved against the location
of the
containing scdl"
resolves against the full path/URL of the containing scdl. Never
mind if the
assumption was wrong.
I think that's the difference - relative URLs are resolved against
the URL (using new URL(current, scdlLocation)) so there is no path to
search.
The response sounds applying relative path directly to
classLoader.getResource,
I wonder if that's the true intention.
e.g. com/example/a.scdl includes "included.scdl"
normally people assume com/example/included.scdl because that's
normally
"relative" means.
Direct classLoader.getResource("included.scdl") does *not* meet normal
expectation.
For scdlResource, the value is resolved using the classpath using
ClassLoader.getResource() - the value supplied is absolute as that is
all that method takes.
Anyway, the reason I've been trying to help is,
it would be nice to keep scdl business intact,
other info such as search path, repository config and so on,
might need another host.
Could you clarify what you mean here?
I'd also add that both these mechanisms override the use of the
repository. If you wanted to use that you would not use either of
these but would instead supply repository metadata e.g.
<include name="included" group="com.example" version="1.0"/>
I see that as the norm - the scdlLocation and scdlResource variants
would only be used in atypical circumstances (like when we are
loading the system scdl and don't have the repo bootstrapped yet).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
