Yes, but the current testing is of the legacy UCL/URL class loaders
which do not have this notion. The VFS needs to have a mapping notion to
allow content to be pulled together in a logical deployment unit (jar,
...), and the ClassLoadingDomain needs to support the osgi type of
import/export notion. I was not viewing either of these as requirements
for the initial VDF implementation.
Adrian Brock wrote:
Like I said in another e-mail to you, we need to be able
to use the VFS to build "deployments on the fly" from
the project structure without having to go through
the jar procedure.
This should create a "scoped" classloader that
hides the underlying classes/resources in the ide or output folder.
i.e. You should be able to build a "classloading domain"
based on the test's classloader which filters out certain
parts (configurable).
These parts are then re-introduced via new classloaders
that is scoped on top of the filtered classloader.
For the new deployers in particular, we should be able
to pretend the filtered parts actually represent
a jared deployment (even if those parts are
scattered around the real filesystem).
On Tue, 2006-08-29 at 13:07 -0700, Scott M Stark wrote:
> I added a src/tests-support source folder to the system-jmx project in
> MC_VDF_WORK branch that excludes all *.java files. I did this because
> its a source of classes for jars that are loaded by class loader tests,
> and these classes cannot be on the ide classpath. You have to generate
> the associated jars by running the system-jmx/ build-test.xml script.
>
> I don't know how to make the building of such test artifacts any more
> seamlessly integrated at this point.
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
>