[JBoss-dev] system-jmx/src/tests-support source folder issue

[Scott M Stark]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>