Thanks JB, I was just looking to see how to add that in the startup.properties without making one more file to worry about becoming out of sync with Karaf upgrades :)
On Mon, Jan 22, 2018 at 10:19 AM Jean-Baptiste Onofré <[email protected]> wrote: > By the way, you can always add such bundle in etc/startup.properties (or > corresponding boot features) to avoid the refresh. > > I did that for Cassandra (used in Decanter) for instance. > > Regards > JB > > On 01/22/2018 04:13 PM, 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 >
