Am 04.11.2016 13:23, schrieb Benson Margulies:
It's an important goal of this project to _not_ require an extra JVM,
so your suggestion
of using a process builder, while it would allow me to make this test
work, would not
be something I can use in production.
The you should not start something from within the (boot)class-path but
embedd everything in OSGi-Bundles and carefully craft import/exports
instead of rely on automatic guessing from BND and such tools. This is
the only way to have true classloader-isolation.
Pax Web (with embedded jetty) as well as Pax Exam rely on some parts on
Dynamic-Imports and thus can easily lead to have classes loaded from the
boot-class-path as well als some libs are not behave very frndly by
using Class.forName or static Methods to obtain Connections and such.
Context-Classloading is some kind of work-around to adress these
problem, but not a real solution.
So I would recommend (if you really do not want to start up an extra vm
for testing, what would be in the sense of test-isolation preferable)
that you pack your "launch the test service using the CXF API; no OSGi
involved." inside a bundle (embedding all dependecies) make sure the
bundle does not export or import any packages and use an Activator to
fire up the test-service. You can then use this bundle in your pax-exam
test without polluting your test-classpath with other libs (CXF itself
requires a lot as of the last time I have embedded this in a container).
You also should use the remote-test-container to make sure nothing
trickles in from other parts.
--
--
------------------
OPS4J - http://www.ops4j.org - [email protected]
---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
