On Mon, Nov 7, 2016 at 3:59 AM, 'Christoph Läubrich' via OPS4J <[email protected]> wrote: > 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.
Christoph, the fundamental goal here requires a tiny, very controlled, amount of system bundle/bootclasspath communication. I don't think it's the source of my problems. > > 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. OK. I had hoped that by trimming down the list of packages on the system bundle, I could cut off this, but I take your point. > > 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. -- -- ------------------ 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.
