My concrete proposal as one of the alternatives to scdlResource (pro and con
varies of course),
is to enhance from
new URL(current, scdlLocation) // thank Jeremy for clarifying
to trying other resources with the same relative path in ClassPath after the
new URL fails.
For other programming languages hosted by OS other than Java, native paths
can be used,
such as execution path for Windows and library path for UNIX.
e.g. the ClassPath is dir1, dir2, jar1, jar2.
and the new URL is dir1/com/example/included.scdl,
we can also search for dir2/com/example/included.scdl and
jar2!/com/example/included.scdl.
Similarly if the new URL is jar2!/org/tuscant/system.scdl,
we can search for jar1!/org/tuscant/system.scdl and
dir2/org/tuscant/system.scdl too.
My philosophy is to separate Business Logic from configuration such as
search path and artifact repository,
it would be nice if a scdl contains only contracts without any configuration
which may vary on different user hosts.
On 9/6/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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]
--
Yang ZHONG
