Hi Benson, that's not an easy thing to answer. I never tried this, so I'm not sure I'm best to answer it. But two things come to my mind: 1) if you're starting your framework from inside of another "server" are you using a web-container? If so, take a look at how the felix-http-bridge or the Pax-Web HTTP Bridge (WIP), maybe that can help already, or might be suitable for your use case. 2) Check how Karaf main starts the osgi framework, or take a look at how Pax-Exam is capable of separating the concern, there might be some hints
regards, Achim 2016-11-04 13:23 GMT+01:00 Benson Margulies <[email protected]>: > On Fri, Nov 4, 2016 at 8:09 AM, 'Achim Nierbeck' via OPS4J > <[email protected]> wrote: > > Ok, > > > > so looks like you infected your boot-classloader which is used by felix > with > > classes already present. > > `Achim, could you please help me understand the failure mode a little > better? > 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. > > I want to understand what can go wrong when I hand a customer a > library that, when invoked, > launches an embedded copy of Felix. > > I thought that only those packages on > org.osgi.framework.system.packages (plus the extras) > travelled from outside felix to inside felix. (Obviously, Felix > itself might malfunction, but this failure > does not look like Felix itself at work.) > > Is there some other pollution pathway? > > To try to fix this, I customized my org.osgi.framework.system.packages > by trimming out > all of the web service packages that I thought might allow leakage of > something from CXF/Jetty. > > (I can't, myself, imagine a way that a class leaking through would > cause pax-web to > fail to set the TCCL around this particular case in jetty.) > > Thanks as always for any illumination, > benson > > > > Anyway I'd always make sure that both are seperated, therefore I'd use a > > ProcessBuilder to start the felix + addons. Maybe use a bnd-tools > > self-contained jar for that? > > > > Regarding the outer classpath, make sure you have felix started in a way > > it's not exporting everything as bootloader to the other bundles. > > > > regards, Achim > > > > 2016-11-04 13:02 GMT+01:00 Benson Margulies <[email protected]>: > >> > >> On Fri, Nov 4, 2016 at 7:47 AM, 'Achim Nierbeck' via OPS4J > >> <[email protected]> wrote: > >> > Hi, > >> > > >> > as I'm still puzzled by what your are trying to achieve. > >> > Are you trying to have a Servlet-Bridge? > >> > In that case we still have a wip-branch[1] for that. It could need > some > >> > love, > >> > but maybe that part will already help you? > >> > > >> > >> I have a service inside the OSGi container, which, when asked nicely, > >> makes HTTP connections to another REST-ful service elsewhere. > >> > >> I want to test this service. So, I need to start up an ephemeral > service. > >> > >> Thus the following idea, in a plain old Junit test: > >> > >> 1: launch the test service using the CXF API; no OSGi involved. > >> 2: launch the OSGi container > >> 3: poke the service of the OSGi container that talks to the test service > >> 4: observe success > >> 5: go home > >> > >> However, as soon as a stick the CXF jars into the classpath of the > >> test (next to Felix itself), I get the problem I've reported here, in > >> which Jetty tries to find an mbean using the wrong class loader. > >> > >> If I launch the test service in another JVM somewhere, everything is > >> fine, which is what I'm actually doing now. I just wish I could figure > >> out _why_ changing the 'outer' classpath has this effect. > >> > >> -- > >> -- > >> ------------------ > >> 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. > > > > > > > > > > -- > > > > Apache Member > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer > & > > Project Lead > > blog <http://notizblog.nierbeck.de/> > > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > > > Software Architect / Project Manager / Scrum Master > > > > -- > > -- > > ------------------ > > 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. > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master -- -- ------------------ 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.
