Ah that's interesting (I was not able to reproduce the issue with just
features:install) ;)
We introduced some changes in featuresBoot for Karaf 2.3.x, it may be
related to that.
I'm checking something.
Regards
JB
On 11/09/2012 04:46 PM, Bengt Rodehav wrote:
JB,
I'm not 100% sure I understand what you mean but....
I only get this problem if I install the features by listing the
features in featuresBoot. If I use the following setting:
featuresBoot=config,ssh,management,kar
...and then execute these commands after startup:
features:install jpa
features:install ipojo
features:install webconsole
...then everything works fine.
/Bengt
2012/11/9 Jean-Baptiste Onofré <[email protected] <mailto:[email protected]>>
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]> <mailto:[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]>>
<mailto:[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]>>
<mailto:[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]>>
<mailto:[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]>>
<mailto:[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]>>>
<mailto:[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]>>>
<mailto:[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]>>
<mailto:[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]>
<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
