Just a question Bengt,
do you confirm that you reproduce the issue by installing the ipojo and
jpa feature (and not necessary by putting to featuresBoot) ?
First I'm going to test to set aries.util with dependency=true as it's
already provided by the framework feature (and so in the
startup.properties as well).
In any case, it doesn't make sense to define aries.util in jpa, jndi or
application-without-isolation features, as it's already provided by the
startup.properties.
However, the features definition (and startup.properties) is the same
between Karaf 2.2.x and Karaf 2.3.x. So, I gonna dig to understand the
change (in Karaf and Aries).
Regards
JB
On 11/09/2012 03:52 PM, Bengt Rodehav wrote:
Thanks for the info and your effort,
/Bengt
2012/11/9 Jean-Baptiste Onofré <[email protected] <mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[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]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[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]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
Thanks a lot JB,
/Bengt
2012/11/5 Jean-Baptiste Onofré <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[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]>
<mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
<mailto:[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]>
<mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
<mailto:[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] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected] <mailto:[email protected]>
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
