Yes, but as said, I don't think it's good to define JNA by default in Karaf.
WDYT ? Regards JB On 01/22/2018 04:36 PM, Seth Leger wrote: > Yep, I had the same problem with JNA. Glad you tracked it down. > > https://issues.apache.org/jira/browse/KARAF-5251 > > Seth Leger > The OpenNMS Group > > > On 1/22/18 10:13 AM, Ryan Moquin wrote: >> Thanks Seth, I feel stupid for completely forgetting to check if the >> problem is because of the karaf bundles getting refreshed since that >> turned out to be the reason. In this case though, it's not Mina, it's >> because of JLine and the JNA library (which would be a good candidate to >> preinstall.) It stinks to see all these get refreshed because of a >> dependency getting added that happens to be an option dependency of a >> system bundle. It seems like this happens quite a lot (I find the >> log4j2 bundle seems to end up getting refreshed a lot as well) and makes >> me feel there has to be some sort of intuitive way to prevent it, >> especially because it feels like it could in general hurt Karaf's >> adoption when used with an OOTB distribution (I can work around it with >> a custom distro.) Out of curiousity, maybe at least a small enhancement >> which would at least prevent this issue from confusing people (even >> those who are aware of it but are asleep at the wheel that day) could be >> to show a warning in the console that some system bundles will be >> refreshed which can cause some weird stuff. >> >> In case interested, this is where the problems are (since mongo embed >> needs the com.sun.jna bundle): >> >> org.jline/3.4.0 (Should be wired to: com.sun.jna/4.5.1 (through >> [org.jline/3.4.0] osgi.wiring.package; >> filter:="(osgi.wiring.package=com.sun.jna)"; resolution:=optional)) >> org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should be wired to: >> org.apache.commons.compress/1.10.0 (through >> [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; >> filter:="(osgi.wiring.package=org.apache.commons.compress.compressors)"; >> resolution:=optional)) >> >> Thanks again Seth, this was driving me nuts, I think my brain was >> telling me to ask here because I've seen this before (just forgot about >> it for some reason). I'll make a change and am sure it will resolve. >> Also, I moved to Karaf 4.1.4 since I started having these problems with >> 4.2.x and decided at that rate, might as well go to 4.1.4. Maybe I'll >> just switch back to working with 4.2.x. Choices. choices. >> >> Ryan >> >> On Mon, Jan 22, 2018 at 12:25 AM Seth Leger <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Ryan, >> >> You are probably running into an issue where some dependency of Mongo is >> triggering a refresh of the system bundles inside Karaf. Mongo probably >> isn't "hijacking" jline; it's just causing jline + karaf shell to >> refresh which kills your client shell. There are several ways to do this >> on Karaf 4.1, I documented one way to do it (with Apache MINA) in >> this bug: >> >> https://issues.apache.org/jira/browse/KARAF-5384 >> >> If you use: >> >> feature:install -t -v your-problematic-feature >> >> then you should be able to track down which bundle is triggering the >> refresh. Also, what version of Karaf are you using? >> >> Seth Leger >> The OpenNMS Group >> >> >> On 1/21/18 12:23 PM, Ryan Moquin wrote: >> > This might be better to ask of the Embed Mongo team, but I am not >> > entirely sure. I've been experimenting with an Embedded Mongo running >> > inside Karaf, which I've gotten to work successfully with one caveat >> > that is driving me crazy trying to troubleshoot (I think I understand >> > what's happening, but not exactly what makes it happen). If I have a >> > feature which installs a bundle that created and starts a Flapdoodle >> > Embed Mongo instance, then the Karaf console will "hang" since I think >> > the Embed Mongo code, kind of "hijacking" the Karaf JLine input stream >> > (it attaches some input streams for the Mongo process.) I did switch >> > the outputstreams to use SLF4J which helped a bit, but there is >> one last >> > small issue I can't figure out. The reason I'm wondering if >> someone on >> > this list might have some ideas is because if when I install that >> > feature, I force kill the Karaf process and start it back up, then the >> > Embed Mongo process ends up running in the background without >> > "hijacking" the Karaf jline console. >> > >> > I guess I'm wondering if there is a way to initially install my embed >> > mongo feature and prevent it from grabbing the Karaf JLine stream if I >> > understand how the feature startup is different than than when >> > installing a feature (around the Karaf console input). I hope >> what I'm >> > asking actually makes sense to someone. Basically, the feature >> command >> > doesn't return control to the Karaf console after installing that >> > feature due to what the Embedded mongo process does under the >> covers.... >> > I've been debugging the embed mongo code to see if I can figure >> out how >> > this conflict is happening.. it appears one of the threads that >> reads an >> > inputstream from mongod is the culprit, but this is only a problem >> when >> > installing the feature, not running karaf after the feature has been >> > installed..... >> > >> > Thanks for any advice! >> > >> > Ryan >> > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
