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.
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.
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.
On 9/6/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
You lost me.
On Sep 6, 2006, at 10:50 AM, Yang ZHONG wrote:
> Maybe we can broaden "relative path" semantics therefore it may not
> necessarily be mandatory any longer to introduce "scdlResource".
>
> e.g. the ClassPath is dir1, dir2, jar1, jar2.
> Even if a resolved relative path is dir1/com/example/included.scdl,
> we can also search for dir2/com/example/included.scdl and
> jar2!/com/example/included.scdl.
> Similarly evev if a resolved relative path is jar2!/org/tuscant/
> system.scdl,
> we can search for jar1!/org/tuscant/system.scdl and
> dir2/org/tuscant/system.scdl
If the classpath is [dir1, dir2, jar1, jar2], ClassLoader.getResource
() would look in all of those anyway.
The difference between scdLocation and scdlResource is between
resolving on the classpath vs. resolving relative to the current scdl
(which may not be on the classpath at all). What are you proposing to
avoid that?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
