3:07 p.m.
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.
4:20 p.m.
New subject: [JBoss-dev] system-jmx/src/tests-support source folder issue
An artifact of this is that the .svn folders show up in the Navigator
view. I tried to see if a junit test could exclude certain classpath
entries, but the output of source folders cannot be excluded it seems.
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.
7:48 a.m.
New subject: [JBoss-dev] system-jmx/src/tests-support source folder issue
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
2:48 p.m.
New subject: [JBoss-dev] system-jmx/src/tests-support source folder issue
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
>
8:39 a.m.
New subject: [JBoss-dev] system-jmx/src/tests-support source folder issue
Even with the UCL the filtering classloader should be the same?
You would need a url handler that can provide the pretend deployment
from a list of packages e.g.
test:jar1?packages=org.jboss.test.jar1
On Thu, 2006-08-31 at 12:48 -0700, Scott M Stark wrote:
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
>>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
11:52 a.m.
New subject: [JBoss-dev] system-jmx/src/tests-support source folder issue
Possibly, and I'll look into it once I hook the UCL based
DomainClassLoader into the ClassLoadingDeployer. My concern with trying
to do this with the current UCL, which is subclassing URLClassLoader, is
not having control over caching of the URL handler pieces and having
leaks. Not a problem for testcases.
Adrian Brock wrote:
Even with the UCL the filtering classloader should be the same?
You would need a url handler that can provide the pretend deployment
from a list of packages e.g.
test:jar1?packages=org.jboss.test.jar1
On Thu, 2006-08-31 at 12:48 -0700, Scott M Stark wrote:
> 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.
>
>
6691
days inactive
6694
days old
jboss-development@lists.jboss.org
5 comments
3 participants
participants (3)
-
Adrian Brock -
Scott M Stark -
Scott M Stark