Thanks for the info and your effort, /Bengt
2012/11/9 Jean-Baptiste Onofré <j...@nanthrax.net> > Hi Bengt, > > just back home ;) > > We found an issue around Aries Blueprint (around graceperiod and deadlock > especially). I gonna work on your issue this afternoon and see to fix it on > Aries. > > Regards > JB > > > On 11/08/2012 10:41 AM, Bengt Rodehav wrote: > >> 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 <be...@rodehav.com <mailto:be...@rodehav.com>> >> >> >> 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 <be...@rodehav.com <mailto:be...@rodehav.com >> >> >> >> >> 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 <be...@rodehav.com >> <mailto:be...@rodehav.com>> >> >> >> Thanks a lot JB, >> >> /Bengt >> >> >> 2012/11/5 Jean-Baptiste Onofré <j...@nanthrax.net >> <mailto:j...@nanthrax.net>> >> >> >> 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 <be...@rodehav.com >> <mailto:be...@rodehav.com> <mailto:be...@rodehav.com >> >> <mailto:be...@rodehav.com>>> >> >> >> 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 <be...@rodehav.com >> <mailto:be...@rodehav.com> <mailto:be...@rodehav.com >> >> <mailto:be...@rodehav.com>>> >> >> >> 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é >> jbono...@apache.org <mailto:jbono...@apache.org> >> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
