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 On 9/6/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
The spec says that <include> takes the name of the composite to be included but does not say how it should be located. We currently support a scdlLocation attribute that takes a URL, with relative URLs being resolved against the location of the containing scdl. However, it would be nice to allow users to place SCDL somewhere on the composite's classpath. I think we should also support a scdlResource attribute that takes the name of a Java resource that will be located using the same classpath as we use for Java classes (i.e. the same classpath used to locate the class in a <implementation.java> or <interface.java>). One thing this would let us do is publish scdl fragments in the kernel for things like the set of loader components (the current loader.scdl) that can then be reused by the various hosts; this would get rid of the duplicates and the need to maintain them. This will help with the webapp host I am working on so I plan to add the scdlResouce attribute soon. The same would also apply to things like <implementation.composite> -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Yang ZHONG
