JB, I will have to release our product very shortly. Do you think the workaround I'm currently using is "safe" for production or should I wait for your analysis? As far as I've tested it seems to work perfectly but I'm a bit worried about the underlying cause to this.
/Bengt 2012/11/8 Bengt Rodehav <[email protected]> > I just tried doing the same thing using Karaf 2.2.9, that is: > > - Add an ipojo feature > - Add the jpa and ipojo feature to featuresBoot > > This works without any problems. Of course, Karaf 2.2.9 uses > org.apache.aries.util version 0.3.1 while Karaf 2.3.0 uses version 1.0.0. > One of my main reasons for upgrading Karaf is in fact to upgrade Aries to a > modern version. > > Don't know if this means that the problem lies within Aries or not. I > still think that there is something fishy going on in Karaf. > > /Bengt > > > 2012/11/8 Bengt Rodehav <[email protected]> > >> Hello JB, >> >> Just wanted to check whether you've managed to recreate this and possibly >> explain what is happening. I'm wondering if there might be a problem with >> the implementation of the feature functionality which is why I don't want >> this in production yet (but I have to upgrade our production servers very >> soon). >> >> My reasoning is as follows: If the org.apache.aries.util bundle is >> already installed (and possibly active - don't know what the timing looks >> like) then installing a feature containing the org.apache.aries.util bundle >> should be a noop - right? But apparently the feature functionality does >> something regarding this bundle anyway. What should it do? Why should it do >> anything? >> >> /Bengt >> >> >> 2012/11/7 Bengt Rodehav <[email protected]> >> >>> The workaround I'm currently using is to modify the >>> enterprise-2.3.0-features.xml so that the *jpa* feature and the >>> *jndi*feature no longer include the org.apache.aries.util bundle. Then >>> everything >>> seems to work (the org.apache.aries.util bundle is installed anyway thanks >>> to startup.properties). >>> >>> However, I still don't feel comfortable putting this into production >>> until I know what is happening. >>> >>> /Bengt >>> >>> >>> >>> >>> 2012/11/5 Bengt Rodehav <[email protected]> >>> >>>> Thanks a lot JB, >>>> >>>> /Bengt >>>> >>>> >>>> 2012/11/5 Jean-Baptiste Onofré <[email protected]> >>>> >>>>> Hi Bengt, >>>>> >>>>> thanks for the detailed explanation. >>>>> >>>>> I will try to create a use case (without iPojo) to reproduce the issue >>>>> (in combination with jpa feature). >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> >>>>> On 11/05/2012 04:59 PM, Bengt Rodehav wrote: >>>>> >>>>>> Some more findings... >>>>>> >>>>>> It seems like the Karaf Shell (org.apache.karaf.shell.**console) >>>>>> bundle >>>>>> uses packages from aries (e g org.apache.aries.blueprint) which in >>>>>> turn >>>>>> uses packages from org.apache.aries.util. Could it be that when >>>>>> the org.apache.aries.util bundle is installed as part of the jpa >>>>>> feature, it somehow causes a refresh which causes dependent bundles >>>>>> (such as the org.apache.karaf.shell.console bundle) to be rewired. >>>>>> This >>>>>> in turn would probably reinitialize the console (I'm probably using >>>>>> the >>>>>> wrong terminology here but you know what I mean...). >>>>>> >>>>>> If that is the case, then it seems highly undesirable to include >>>>>> the org.apache.aries.util bundle in the jpa feature. >>>>>> >>>>>> I don't have an explanation as to why this problem only occurs >>>>>> together >>>>>> with iPojo but I assume that it somehow triggers the refresh. >>>>>> >>>>>> /Bengt >>>>>> >>>>>> >>>>>> 2012/11/5 Bengt Rodehav <[email protected] <mailto:[email protected] >>>>>> >> >>>>>> >>>>>> >>>>>> BTW, I tried using iPojo 1.6.8 instead to see if this is a problem >>>>>> introduced in later iPojo versions. I do, however, get the same >>>>>> problems using iPojo 1.6.8 which implies that it's not a newly >>>>>> introduced iPojo problem. >>>>>> >>>>>> /Bengt >>>>>> >>>>>> >>>>>> 2012/11/5 Bengt Rodehav <[email protected] <mailto: >>>>>> [email protected]>> >>>>>> >>>>>> >>>>>> I'm trying to upgrade my custom Karaf distribution to Karaf >>>>>> 2.3.0 but have ran into some problems. It seems there is some >>>>>> kind of conflict between ipojo 1.8.2 and the jpa feature - >>>>>> specifically the org.apache.aries.util bundle in the jpa >>>>>> feature. >>>>>> >>>>>> I install ipojo as a feature (not listed in >>>>>> startup.properties). >>>>>> But when I do this I get the following exception: >>>>>> >>>>>> /2012-11-05 15:51:20,251 | INFO | l Console Thread | Console >>>>>> >>>>>> | araf.shell.console.jline.**Console >>>>>> 199 >>>>>> | 14 - org.apache.karaf.shell.console - 2.3.0 | Exception >>>>>> caught >>>>>> while executing command/ >>>>>> /java.lang.**UnsupportedOperationException: read() with >>>>>> timeout >>>>>> cannot be called as non-blocking operation is disabled/ >>>>>> /at >>>>>> jline.internal.**NonBlockingInputStream.read(** >>>>>> NonBlockingInputStream.java:**134)[14:org.apache.karaf.** >>>>>> shell.console:2.3.0]/ >>>>>> /at >>>>>> jline.internal.**NonBlockingInputStream.read(** >>>>>> NonBlockingInputStream.java:**246)[14:org.apache.karaf.** >>>>>> shell.console:2.3.0]/ >>>>>> /at >>>>>> jline.internal.**InputStreamReader.read(** >>>>>> InputStreamReader.java:259)[**14:org.apache.karaf.shell.** >>>>>> console:2.3.0]/ >>>>>> /at >>>>>> jline.internal.**InputStreamReader.read(** >>>>>> InputStreamReader.java:196)[**14:org.apache.karaf.shell.** >>>>>> console:2.3.0]/ >>>>>> /at >>>>>> jline.console.ConsoleReader.**readCharacter(ConsoleReader.** >>>>>> java:1974)[14:org.apache.**karaf.shell.console:2.3.0]/ >>>>>> /at >>>>>> jline.console.ConsoleReader.**readLine(ConsoleReader.java:** >>>>>> 2174)[14:org.apache.karaf.**shell.console:2.3.0]/ >>>>>> /at >>>>>> jline.console.ConsoleReader.**readLine(ConsoleReader.java:** >>>>>> 2098)[14:org.apache.karaf.**shell.console:2.3.0]/ >>>>>> /at >>>>>> org.apache.karaf.shell.**console.jline.Console.** >>>>>> readAndParseCommand(Console.**java:235)[14:org.apache.karaf.** >>>>>> shell.console:2.3.0]/ >>>>>> /at >>>>>> org.apache.karaf.shell.**console.jline.Console.run(** >>>>>> Console.java:171)[14:org.**apache.karaf.shell.console:2.**3.0]/ >>>>>> /at java.lang.Thread.run(Thread.**java:662)[:1.6.0_32]/ >>>>>> >>>>>> >>>>>> Then it seems like Karaf (or Felix) restarts somehow since I >>>>>> get >>>>>> another "Karaf" logo in the console. The issue can be >>>>>> reproduced >>>>>> quite easily: >>>>>> >>>>>> 1. Download a fresh Karaf 2.3.0 >>>>>> >>>>>> 2. Create a new feature containing the ipojo bundle. The >>>>>> easiest >>>>>> way is probably to add the following lines to the >>>>>> enterprise-2.3.0-features.xml in the "system" folder: >>>>>> >>>>>> <feature name="ipojo"> >>>>>> >>>>>> <bundle>mvn:org.apache.felix/**org.apache.felix.ipojo/1.8.2</ >>>>>> **bundle> >>>>>> </feature> >>>>>> >>>>>> 3. Edit the etc/org.apache.karaf.features.**cfg as follows: >>>>>> >>>>>> featuresBoot=config,ssh,**management,kar,jpa,ipojo >>>>>> >>>>>> Some other obeservations: >>>>>> >>>>>> - If I switch the jpa and the ipojo features I get other >>>>>> exceptions. >>>>>> >>>>>> - The org.apache.aries.util bundle is part of the jpa feature >>>>>> (start level 30) but it is also present in startup.properties >>>>>> (start level 20). >>>>>> >>>>>> - If I remove the org.apache.aries.util bundle from the jpa >>>>>> feature then things seem to work. >>>>>> >>>>>> - If I install ipojo by using startup.properties instead of >>>>>> using a feature then things seem to work. >>>>>> >>>>>> The last two observations might imply that >>>>>> org.apache.aries.util >>>>>> and ipojo must be resolved at the same time (start levels do >>>>>> not >>>>>> make any difference). >>>>>> >>>>>> I'm not sure if this post belongs here or in Felix mailing >>>>>> list. >>>>>> However, since it seems to involve the enterprise features >>>>>> that >>>>>> is part of Karaf I try here first. It's very confusing. >>>>>> Although >>>>>> I have found a couple of work-arounds I don't feel comfortable >>>>>> using them since I don't know what is happening. >>>>>> >>>>>> Does anyone have a clue? >>>>>> >>>>>> /Bengt >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Jean-Baptiste Onofré >>>>> [email protected] >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>>>> >>>> >>>> >>> >> >
