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]> 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
>
>
