You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Per-Erik Svensson <pe...@gmail.com> on 2012/10/15 15:03:56 UTC
Gogo command and Fileinstall
Hi,
I get the following exception when trying to start gogo-command
automatically through fileinstall:
In main loop, we have serious trouble: java.lang.RuntimeException:
java.lang.InterruptedException
java.lang.RuntimeException: java.lang.InterruptedException
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
... 3 more
In main loop, we have serious trouble: java.lang.RuntimeException:
java.lang.InterruptedException
java.lang.RuntimeException: java.lang.InterruptedException
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
... 3 more
"What did you do to make this happen?"
Originally through an embedded version of felix 4.0.2. To make sure that it
was not my code, through dist of felix 4.0.3.
All I have done is to unpack the Felix Framework Distribution, removed gogo
commands from the bundle directory (to make it not auto-install/start from
felix itself) and added gogo commands to a fileinstall-controlled
directory. Of course, I put fileinstall in the bundle directory of felix
(to make it auto-install).
Note that this only happens when gogo command is installed from
fileinstall. If felix installs and starts it from the bundle dir, it works
like a charm. It also only happens with gogo command, other bundles can be
installed properly through fileinstall. I'm thus not sure if this is a bug
in fileinstall, gogo command or simply an error 40 issue (the guy sitting
40 cm from the screen).
All versions used are the ones currently available from the felix download
site.
Felix Framework Distribution 4.0.3
Fileinstall 3.2.4
Gogo Command 0.12.0
Other bundles installed (coming from distribution)
Bundle Repository 1.6.6
Gogo Runtime 0.10.0
Gogo Shell 0.10.0
Is this maybe some weird dependency thing making the framework try to
refresh itself? If so, is it possible to resolve in any way?
Best regards,
Per-Erik Svensson
Re: Gogo command and Fileinstall
Posted by Per-Erik Svensson <pe...@gmail.com>.
I created https://issues.apache.org/jira/browse/FELIX-3712.
I hope it is expressive and brief enough to describe the problem.
Thanks a bunch for the help Derek!
Regards,
Per-Erik Svensson
On Tue, Oct 16, 2012 at 12:48 PM, Derek Baum <de...@baums.org.uk> wrote:
> It looks like this is a bug in fileinstall introduced by FELIX-3414.
>
> The refresh() method in DirectoryWatcher was changed from calling
> packageAdmin.refreshPackages() directly to using the FileInstall.refresh()
> helper method.
>
> The difference is that packageAdmin.refreshPackages can
> throw InterruptedException (which the loop in DirectoryWatcher catches),
> but FileInstall.refresh() wraps the InterruptedException in a
> RuntimeException, so it is not caught in the main loop.
>
> Please will you raise a JIRA for this?
>
> --
> Derek
>
>
> On 15 October 2012 18:17, Per-Erik Svensson <pererik.svensson@gmail.com
> >wrote:
>
> > This seems somehow connected to bug 3021 (
> > https://issues.apache.org/jira/browse/FELIX-3021).
> >
> > This is why I think so:
> >
> > Fileinstall has the following in its manifest's
> > Import-Package:
> > org.osgi.service.log;resolution:=optional;version="[1.3,2)".
> > When starting gogo command after fileinstall, fileinstall will be
> restarded
> > (I think) because gogo command exports:
> >
> > org.osgi.service.log;uses:="org.osgi.framework";version="1.3".
> >
> > If I'm understanding this correctly, this is not *really *a bug in gogo
> > command (although "solving" 3021 would resolve this issue as well), but
> > rather it is fileinstall that is not properly set up for being stopped
> > while installing a bundle? In short, fileinstall is trying to install a
> > bundle (gogo command) and as a consequence is stopped because it is being
> > rewired to the log package. When stopped at this point, it bails out with
> > an error and when started again, it has "lost all memory of trying to
> > install and start a bundle" - for obvious reasons.
> >
> > So, I think this ultimately might be a bug in fileinstall. It needs to be
> > able to somehow handle being shutdown as a result of installing a bundle.
> > Or maybe this isn't possible?
> >
> > Running felix in debug log mode gives the following (verbose, so sorry
> for
> > the wall of text) result:
> >
> > DEBUG: WIRE: [1.0] osgi.wiring.package;
> > (osgi.wiring.package=javax.xml.stream) -> [0]
> > DEBUG: WIRE: [1.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [1.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.4.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [3.0] osgi.wiring.package;
> > (osgi.wiring.package=org.osgi.framework) -> [0]
> > DEBUG: WIRE: [3.0] osgi.wiring.package;
> > (osgi.wiring.package=org.osgi.util.tracker) -> [0]
> > DEBUG: WIRE: [4.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(version>=0.10.0))
> > -> [3.0]
> > DEBUG: WIRE: [4.0] osgi.wiring.package;
> > (osgi.wiring.package=org.osgi.framework) -> [0]
> > DEBUG: WIRE: [4.0] osgi.wiring.package;
> > (osgi.wiring.package=org.osgi.service.startlevel) -> [0]
> > DEBUG: WIRE: [4.0] osgi.wiring.package;
> > (osgi.wiring.package=org.osgi.util.tracker) -> [0]
> > ____________________________
> > Welcome to Apache Felix Gogo
> >
> > g! In main loop, we have serious trouble: java.lang.RuntimeException:
> > java.lang.InterruptedException
> > java.lang.RuntimeException: java.lang.InterruptedException
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > Caused by: java.lang.InterruptedException
> > at java.lang.Object.wait(Native Method)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > ... 3 more
> > DEBUG: WIRE: [1.0] osgi.wiring.package;
> > (osgi.wiring.package=javax.xml.stream) -> [0]
> > DEBUG: WIRE: [1.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [1.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0)))
> > -> [5.0]
> > DEBUG: WIRE: [1.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [5.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(version>=0.10.0)(!(version>=1.0.0)))
> > -> [3.0]
> > DEBUG: WIRE: [5.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.5.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [5.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.framework.wiring)(version>=1.0.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [5.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [5.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [5.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.3.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> > -> [0]
> >
> > *DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0)))
> > -> [5.0]*
> > *
> > *
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> > -> [0]
> > DEBUG: WIRE: [2.0] osgi.wiring.package;
> >
> >
> (&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.4.0)(!(version>=2.0.0)))
> > -> [0]
> > bundles
> > 0|Active | 0|org.apache.felix.framework (4.0.3)
> > 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> > 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> > 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> > 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> > 5|Resolved | 1|org.apache.felix.gogo.command (0.12.0)
> >
> > If someone is trying to reproduce this, just know that it might take
> awhile
> > before the second batch of debug messages is printed. Be patient! :)
> > Anyway, this clearly states that felix is wiring up bundle 2
> (fileinstall)
> > with bundle 5 (gogo command) and the package in this case is highlighted
> > above (org.osgi.service.log).
> >
> > Can I do something about this? Filing a JIRA?
> >
> > Also, thanks Derek! Both for confirming that this was not only happing on
> > my end and for great hints about messing about with bundles even when
> gogo
> > command is not installed! :)
> >
> > Regards,
> > Per-Erik Svensson
> >
> >
> > On Mon, Oct 15, 2012 at 3:42 PM, Derek Baum <de...@baums.org.uk> wrote:
> >
> > > Hmm... just tested this with fileinstall-3.1.4 (the version I already
> had
> > > around) and it works fine.
> > >
> > > However, with fileinstall-3.2.4, I get the problem you describe:
> > >
> > > Welcome to Apache Felix Gogo
> > >
> > > g! lb
> > > gogo: CommandNotFoundException: Command not found: lb <--- expected,
> > as
> > > we haven't installed gogo.command
> > >
> > > # invoke BundleContext.getBundles() directly - gogo converters
> > pretty-print
> > > the result :-)
> > >
> > > g! bundles
> > > 0|Active | 0|org.apache.felix.framework (4.0.3)
> > > 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> > > 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> > > 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> > > 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> > >
> > >
> > > # copy gogo.command to fileinstall load directory
> > >
> > > g! In main loop, we have serious trouble: java.lang.RuntimeException:
> > > java.lang.InterruptedException
> > > java.lang.RuntimeException: java.lang.InterruptedException
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > > Caused by: java.lang.InterruptedException
> > > at java.lang.Object.wait(Native Method)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > > ... 3 more
> > >
> > > g! lb
> > > gogo: CommandNotFoundException: Command not found: lb
> > >
> > > g! bundles
> > > 0|Active | 0|org.apache.felix.framework (4.0.3)
> > > 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> > > 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> > > 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> > > 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> > > 5|Resolved | 1|org.apache.felix.gogo.command (0.12.0)
> > >
> > >
> > > # so gogo.command failed to activate
> > > # let's try starting it directly:
> > >
> > > g! (bundle 5) start
> > > g! lb
> > > START LEVEL 1
> > > ID|State |Level|Name
> > > 0|Active | 0|System Bundle (4.0.3)
> > > 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
> > > 2|Active | 1|Apache Felix File Install (3.2.4)
> > > 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
> > > 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
> > > 5|Active | 1|Apache Felix Gogo Command (0.12.0)
> > > g! gosh: stopping framework
> > >
> > > --
> > > Derek
> > >
> > > On 15 October 2012 14:03, Per-Erik Svensson <
> pererik.svensson@gmail.com
> > > >wrote:
> > >
> > > > Hi,
> > > >
> > > > I get the following exception when trying to start gogo-command
> > > > automatically through fileinstall:
> > > >
> > > > In main loop, we have serious trouble: java.lang.RuntimeException:
> > > > java.lang.InterruptedException
> > > > java.lang.RuntimeException: java.lang.InterruptedException
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > > > Caused by: java.lang.InterruptedException
> > > > at java.lang.Object.wait(Native Method)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > > > ... 3 more
> > > > In main loop, we have serious trouble: java.lang.RuntimeException:
> > > > java.lang.InterruptedException
> > > > java.lang.RuntimeException: java.lang.InterruptedException
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > > > Caused by: java.lang.InterruptedException
> > > > at java.lang.Object.wait(Native Method)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > > > ... 3 more
> > > >
> > > > "What did you do to make this happen?"
> > > >
> > > > Originally through an embedded version of felix 4.0.2. To make sure
> > that
> > > it
> > > > was not my code, through dist of felix 4.0.3.
> > > >
> > > > All I have done is to unpack the Felix Framework Distribution,
> removed
> > > gogo
> > > > commands from the bundle directory (to make it not auto-install/start
> > > from
> > > > felix itself) and added gogo commands to a fileinstall-controlled
> > > > directory. Of course, I put fileinstall in the bundle directory of
> > felix
> > > > (to make it auto-install).
> > > >
> > > > Note that this only happens when gogo command is installed from
> > > > fileinstall. If felix installs and starts it from the bundle dir, it
> > > works
> > > > like a charm. It also only happens with gogo command, other bundles
> can
> > > be
> > > > installed properly through fileinstall. I'm thus not sure if this is
> a
> > > bug
> > > > in fileinstall, gogo command or simply an error 40 issue (the guy
> > sitting
> > > > 40 cm from the screen).
> > > >
> > > > All versions used are the ones currently available from the felix
> > > download
> > > > site.
> > > >
> > > > Felix Framework Distribution 4.0.3
> > > > Fileinstall 3.2.4
> > > > Gogo Command 0.12.0
> > > >
> > > > Other bundles installed (coming from distribution)
> > > > Bundle Repository 1.6.6
> > > > Gogo Runtime 0.10.0
> > > > Gogo Shell 0.10.0
> > > >
> > > > Is this maybe some weird dependency thing making the framework try to
> > > > refresh itself? If so, is it possible to resolve in any way?
> > > >
> > > > Best regards,
> > > > Per-Erik Svensson
> > > >
> > >
> >
>
Re: Gogo command and Fileinstall
Posted by Derek Baum <de...@baums.org.uk>.
It looks like this is a bug in fileinstall introduced by FELIX-3414.
The refresh() method in DirectoryWatcher was changed from calling
packageAdmin.refreshPackages() directly to using the FileInstall.refresh()
helper method.
The difference is that packageAdmin.refreshPackages can
throw InterruptedException (which the loop in DirectoryWatcher catches),
but FileInstall.refresh() wraps the InterruptedException in a
RuntimeException, so it is not caught in the main loop.
Please will you raise a JIRA for this?
--
Derek
On 15 October 2012 18:17, Per-Erik Svensson <pe...@gmail.com>wrote:
> This seems somehow connected to bug 3021 (
> https://issues.apache.org/jira/browse/FELIX-3021).
>
> This is why I think so:
>
> Fileinstall has the following in its manifest's
> Import-Package:
> org.osgi.service.log;resolution:=optional;version="[1.3,2)".
> When starting gogo command after fileinstall, fileinstall will be restarded
> (I think) because gogo command exports:
>
> org.osgi.service.log;uses:="org.osgi.framework";version="1.3".
>
> If I'm understanding this correctly, this is not *really *a bug in gogo
> command (although "solving" 3021 would resolve this issue as well), but
> rather it is fileinstall that is not properly set up for being stopped
> while installing a bundle? In short, fileinstall is trying to install a
> bundle (gogo command) and as a consequence is stopped because it is being
> rewired to the log package. When stopped at this point, it bails out with
> an error and when started again, it has "lost all memory of trying to
> install and start a bundle" - for obvious reasons.
>
> So, I think this ultimately might be a bug in fileinstall. It needs to be
> able to somehow handle being shutdown as a result of installing a bundle.
> Or maybe this isn't possible?
>
> Running felix in debug log mode gives the following (verbose, so sorry for
> the wall of text) result:
>
> DEBUG: WIRE: [1.0] osgi.wiring.package;
> (osgi.wiring.package=javax.xml.stream) -> [0]
> DEBUG: WIRE: [1.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [1.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.4.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [3.0] osgi.wiring.package;
> (osgi.wiring.package=org.osgi.framework) -> [0]
> DEBUG: WIRE: [3.0] osgi.wiring.package;
> (osgi.wiring.package=org.osgi.util.tracker) -> [0]
> DEBUG: WIRE: [4.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(version>=0.10.0))
> -> [3.0]
> DEBUG: WIRE: [4.0] osgi.wiring.package;
> (osgi.wiring.package=org.osgi.framework) -> [0]
> DEBUG: WIRE: [4.0] osgi.wiring.package;
> (osgi.wiring.package=org.osgi.service.startlevel) -> [0]
> DEBUG: WIRE: [4.0] osgi.wiring.package;
> (osgi.wiring.package=org.osgi.util.tracker) -> [0]
> ____________________________
> Welcome to Apache Felix Gogo
>
> g! In main loop, we have serious trouble: java.lang.RuntimeException:
> java.lang.InterruptedException
> java.lang.RuntimeException: java.lang.InterruptedException
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> Caused by: java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> ... 3 more
> DEBUG: WIRE: [1.0] osgi.wiring.package;
> (osgi.wiring.package=javax.xml.stream) -> [0]
> DEBUG: WIRE: [1.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [1.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0)))
> -> [5.0]
> DEBUG: WIRE: [1.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [5.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(version>=0.10.0)(!(version>=1.0.0)))
> -> [3.0]
> DEBUG: WIRE: [5.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.5.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [5.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.framework.wiring)(version>=1.0.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [5.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [5.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [5.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.3.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
> -> [0]
>
> *DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0)))
> -> [5.0]*
> *
> *
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
> -> [0]
> DEBUG: WIRE: [2.0] osgi.wiring.package;
>
> (&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.4.0)(!(version>=2.0.0)))
> -> [0]
> bundles
> 0|Active | 0|org.apache.felix.framework (4.0.3)
> 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> 5|Resolved | 1|org.apache.felix.gogo.command (0.12.0)
>
> If someone is trying to reproduce this, just know that it might take awhile
> before the second batch of debug messages is printed. Be patient! :)
> Anyway, this clearly states that felix is wiring up bundle 2 (fileinstall)
> with bundle 5 (gogo command) and the package in this case is highlighted
> above (org.osgi.service.log).
>
> Can I do something about this? Filing a JIRA?
>
> Also, thanks Derek! Both for confirming that this was not only happing on
> my end and for great hints about messing about with bundles even when gogo
> command is not installed! :)
>
> Regards,
> Per-Erik Svensson
>
>
> On Mon, Oct 15, 2012 at 3:42 PM, Derek Baum <de...@baums.org.uk> wrote:
>
> > Hmm... just tested this with fileinstall-3.1.4 (the version I already had
> > around) and it works fine.
> >
> > However, with fileinstall-3.2.4, I get the problem you describe:
> >
> > Welcome to Apache Felix Gogo
> >
> > g! lb
> > gogo: CommandNotFoundException: Command not found: lb <--- expected,
> as
> > we haven't installed gogo.command
> >
> > # invoke BundleContext.getBundles() directly - gogo converters
> pretty-print
> > the result :-)
> >
> > g! bundles
> > 0|Active | 0|org.apache.felix.framework (4.0.3)
> > 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> > 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> > 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> > 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> >
> >
> > # copy gogo.command to fileinstall load directory
> >
> > g! In main loop, we have serious trouble: java.lang.RuntimeException:
> > java.lang.InterruptedException
> > java.lang.RuntimeException: java.lang.InterruptedException
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > Caused by: java.lang.InterruptedException
> > at java.lang.Object.wait(Native Method)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > ... 3 more
> >
> > g! lb
> > gogo: CommandNotFoundException: Command not found: lb
> >
> > g! bundles
> > 0|Active | 0|org.apache.felix.framework (4.0.3)
> > 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> > 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> > 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> > 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> > 5|Resolved | 1|org.apache.felix.gogo.command (0.12.0)
> >
> >
> > # so gogo.command failed to activate
> > # let's try starting it directly:
> >
> > g! (bundle 5) start
> > g! lb
> > START LEVEL 1
> > ID|State |Level|Name
> > 0|Active | 0|System Bundle (4.0.3)
> > 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
> > 2|Active | 1|Apache Felix File Install (3.2.4)
> > 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
> > 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
> > 5|Active | 1|Apache Felix Gogo Command (0.12.0)
> > g! gosh: stopping framework
> >
> > --
> > Derek
> >
> > On 15 October 2012 14:03, Per-Erik Svensson <pererik.svensson@gmail.com
> > >wrote:
> >
> > > Hi,
> > >
> > > I get the following exception when trying to start gogo-command
> > > automatically through fileinstall:
> > >
> > > In main loop, we have serious trouble: java.lang.RuntimeException:
> > > java.lang.InterruptedException
> > > java.lang.RuntimeException: java.lang.InterruptedException
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > > Caused by: java.lang.InterruptedException
> > > at java.lang.Object.wait(Native Method)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > > ... 3 more
> > > In main loop, we have serious trouble: java.lang.RuntimeException:
> > > java.lang.InterruptedException
> > > java.lang.RuntimeException: java.lang.InterruptedException
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > > Caused by: java.lang.InterruptedException
> > > at java.lang.Object.wait(Native Method)
> > > at
> > >
> > >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > > ... 3 more
> > >
> > > "What did you do to make this happen?"
> > >
> > > Originally through an embedded version of felix 4.0.2. To make sure
> that
> > it
> > > was not my code, through dist of felix 4.0.3.
> > >
> > > All I have done is to unpack the Felix Framework Distribution, removed
> > gogo
> > > commands from the bundle directory (to make it not auto-install/start
> > from
> > > felix itself) and added gogo commands to a fileinstall-controlled
> > > directory. Of course, I put fileinstall in the bundle directory of
> felix
> > > (to make it auto-install).
> > >
> > > Note that this only happens when gogo command is installed from
> > > fileinstall. If felix installs and starts it from the bundle dir, it
> > works
> > > like a charm. It also only happens with gogo command, other bundles can
> > be
> > > installed properly through fileinstall. I'm thus not sure if this is a
> > bug
> > > in fileinstall, gogo command or simply an error 40 issue (the guy
> sitting
> > > 40 cm from the screen).
> > >
> > > All versions used are the ones currently available from the felix
> > download
> > > site.
> > >
> > > Felix Framework Distribution 4.0.3
> > > Fileinstall 3.2.4
> > > Gogo Command 0.12.0
> > >
> > > Other bundles installed (coming from distribution)
> > > Bundle Repository 1.6.6
> > > Gogo Runtime 0.10.0
> > > Gogo Shell 0.10.0
> > >
> > > Is this maybe some weird dependency thing making the framework try to
> > > refresh itself? If so, is it possible to resolve in any way?
> > >
> > > Best regards,
> > > Per-Erik Svensson
> > >
> >
>
Re: Gogo command and Fileinstall
Posted by Per-Erik Svensson <pe...@gmail.com>.
This seems somehow connected to bug 3021 (
https://issues.apache.org/jira/browse/FELIX-3021).
This is why I think so:
Fileinstall has the following in its manifest's
Import-Package: org.osgi.service.log;resolution:=optional;version="[1.3,2)".
When starting gogo command after fileinstall, fileinstall will be restarded
(I think) because gogo command exports:
org.osgi.service.log;uses:="org.osgi.framework";version="1.3".
If I'm understanding this correctly, this is not *really *a bug in gogo
command (although "solving" 3021 would resolve this issue as well), but
rather it is fileinstall that is not properly set up for being stopped
while installing a bundle? In short, fileinstall is trying to install a
bundle (gogo command) and as a consequence is stopped because it is being
rewired to the log package. When stopped at this point, it bails out with
an error and when started again, it has "lost all memory of trying to
install and start a bundle" - for obvious reasons.
So, I think this ultimately might be a bug in fileinstall. It needs to be
able to somehow handle being shutdown as a result of installing a bundle.
Or maybe this isn't possible?
Running felix in debug log mode gives the following (verbose, so sorry for
the wall of text) result:
DEBUG: WIRE: [1.0] osgi.wiring.package;
(osgi.wiring.package=javax.xml.stream) -> [0]
DEBUG: WIRE: [1.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [1.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.4.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [3.0] osgi.wiring.package;
(osgi.wiring.package=org.osgi.framework) -> [0]
DEBUG: WIRE: [3.0] osgi.wiring.package;
(osgi.wiring.package=org.osgi.util.tracker) -> [0]
DEBUG: WIRE: [4.0] osgi.wiring.package;
(&(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(version>=0.10.0))
-> [3.0]
DEBUG: WIRE: [4.0] osgi.wiring.package;
(osgi.wiring.package=org.osgi.framework) -> [0]
DEBUG: WIRE: [4.0] osgi.wiring.package;
(osgi.wiring.package=org.osgi.service.startlevel) -> [0]
DEBUG: WIRE: [4.0] osgi.wiring.package;
(osgi.wiring.package=org.osgi.util.tracker) -> [0]
____________________________
Welcome to Apache Felix Gogo
g! In main loop, we have serious trouble: java.lang.RuntimeException:
java.lang.InterruptedException
java.lang.RuntimeException: java.lang.InterruptedException
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
... 3 more
DEBUG: WIRE: [1.0] osgi.wiring.package;
(osgi.wiring.package=javax.xml.stream) -> [0]
DEBUG: WIRE: [1.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [1.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0)))
-> [5.0]
DEBUG: WIRE: [1.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [5.0] osgi.wiring.package;
(&(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(version>=0.10.0)(!(version>=1.0.0)))
-> [3.0]
DEBUG: WIRE: [5.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.5.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [5.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework.wiring)(version>=1.0.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [5.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [5.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [5.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.3.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=2.0.0)))
-> [0]
*DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.log)(version>=1.3.0)(!(version>=2.0.0)))
-> [5.0]*
*
*
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.packageadmin)(version>=1.2.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.startlevel)(version>=1.1.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.url)(version>=1.0.0)(!(version>=2.0.0)))
-> [0]
DEBUG: WIRE: [2.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.util.tracker)(version>=1.4.0)(!(version>=2.0.0)))
-> [0]
bundles
0|Active | 0|org.apache.felix.framework (4.0.3)
1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
2|Active | 1|org.apache.felix.fileinstall (3.2.4)
3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
5|Resolved | 1|org.apache.felix.gogo.command (0.12.0)
If someone is trying to reproduce this, just know that it might take awhile
before the second batch of debug messages is printed. Be patient! :)
Anyway, this clearly states that felix is wiring up bundle 2 (fileinstall)
with bundle 5 (gogo command) and the package in this case is highlighted
above (org.osgi.service.log).
Can I do something about this? Filing a JIRA?
Also, thanks Derek! Both for confirming that this was not only happing on
my end and for great hints about messing about with bundles even when gogo
command is not installed! :)
Regards,
Per-Erik Svensson
On Mon, Oct 15, 2012 at 3:42 PM, Derek Baum <de...@baums.org.uk> wrote:
> Hmm... just tested this with fileinstall-3.1.4 (the version I already had
> around) and it works fine.
>
> However, with fileinstall-3.2.4, I get the problem you describe:
>
> Welcome to Apache Felix Gogo
>
> g! lb
> gogo: CommandNotFoundException: Command not found: lb <--- expected, as
> we haven't installed gogo.command
>
> # invoke BundleContext.getBundles() directly - gogo converters pretty-print
> the result :-)
>
> g! bundles
> 0|Active | 0|org.apache.felix.framework (4.0.3)
> 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
>
>
> # copy gogo.command to fileinstall load directory
>
> g! In main loop, we have serious trouble: java.lang.RuntimeException:
> java.lang.InterruptedException
> java.lang.RuntimeException: java.lang.InterruptedException
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> Caused by: java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> ... 3 more
>
> g! lb
> gogo: CommandNotFoundException: Command not found: lb
>
> g! bundles
> 0|Active | 0|org.apache.felix.framework (4.0.3)
> 1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
> 2|Active | 1|org.apache.felix.fileinstall (3.2.4)
> 3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
> 4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
> 5|Resolved | 1|org.apache.felix.gogo.command (0.12.0)
>
>
> # so gogo.command failed to activate
> # let's try starting it directly:
>
> g! (bundle 5) start
> g! lb
> START LEVEL 1
> ID|State |Level|Name
> 0|Active | 0|System Bundle (4.0.3)
> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
> 2|Active | 1|Apache Felix File Install (3.2.4)
> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
> 5|Active | 1|Apache Felix Gogo Command (0.12.0)
> g! gosh: stopping framework
>
> --
> Derek
>
> On 15 October 2012 14:03, Per-Erik Svensson <pererik.svensson@gmail.com
> >wrote:
>
> > Hi,
> >
> > I get the following exception when trying to start gogo-command
> > automatically through fileinstall:
> >
> > In main loop, we have serious trouble: java.lang.RuntimeException:
> > java.lang.InterruptedException
> > java.lang.RuntimeException: java.lang.InterruptedException
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > Caused by: java.lang.InterruptedException
> > at java.lang.Object.wait(Native Method)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > ... 3 more
> > In main loop, we have serious trouble: java.lang.RuntimeException:
> > java.lang.InterruptedException
> > java.lang.RuntimeException: java.lang.InterruptedException
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> > Caused by: java.lang.InterruptedException
> > at java.lang.Object.wait(Native Method)
> > at
> >
> >
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> > ... 3 more
> >
> > "What did you do to make this happen?"
> >
> > Originally through an embedded version of felix 4.0.2. To make sure that
> it
> > was not my code, through dist of felix 4.0.3.
> >
> > All I have done is to unpack the Felix Framework Distribution, removed
> gogo
> > commands from the bundle directory (to make it not auto-install/start
> from
> > felix itself) and added gogo commands to a fileinstall-controlled
> > directory. Of course, I put fileinstall in the bundle directory of felix
> > (to make it auto-install).
> >
> > Note that this only happens when gogo command is installed from
> > fileinstall. If felix installs and starts it from the bundle dir, it
> works
> > like a charm. It also only happens with gogo command, other bundles can
> be
> > installed properly through fileinstall. I'm thus not sure if this is a
> bug
> > in fileinstall, gogo command or simply an error 40 issue (the guy sitting
> > 40 cm from the screen).
> >
> > All versions used are the ones currently available from the felix
> download
> > site.
> >
> > Felix Framework Distribution 4.0.3
> > Fileinstall 3.2.4
> > Gogo Command 0.12.0
> >
> > Other bundles installed (coming from distribution)
> > Bundle Repository 1.6.6
> > Gogo Runtime 0.10.0
> > Gogo Shell 0.10.0
> >
> > Is this maybe some weird dependency thing making the framework try to
> > refresh itself? If so, is it possible to resolve in any way?
> >
> > Best regards,
> > Per-Erik Svensson
> >
>
Re: Gogo command and Fileinstall
Posted by Derek Baum <de...@baums.org.uk>.
Hmm... just tested this with fileinstall-3.1.4 (the version I already had
around) and it works fine.
However, with fileinstall-3.2.4, I get the problem you describe:
Welcome to Apache Felix Gogo
g! lb
gogo: CommandNotFoundException: Command not found: lb <--- expected, as
we haven't installed gogo.command
# invoke BundleContext.getBundles() directly - gogo converters pretty-print
the result :-)
g! bundles
0|Active | 0|org.apache.felix.framework (4.0.3)
1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
2|Active | 1|org.apache.felix.fileinstall (3.2.4)
3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
# copy gogo.command to fileinstall load directory
g! In main loop, we have serious trouble: java.lang.RuntimeException:
java.lang.InterruptedException
java.lang.RuntimeException: java.lang.InterruptedException
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at
org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
... 3 more
g! lb
gogo: CommandNotFoundException: Command not found: lb
g! bundles
0|Active | 0|org.apache.felix.framework (4.0.3)
1|Active | 1|org.apache.felix.bundlerepository (1.6.6)
2|Active | 1|org.apache.felix.fileinstall (3.2.4)
3|Active | 1|org.apache.felix.gogo.runtime (0.10.0)
4|Active | 1|org.apache.felix.gogo.shell (0.10.0)
5|Resolved | 1|org.apache.felix.gogo.command (0.12.0)
# so gogo.command failed to activate
# let's try starting it directly:
g! (bundle 5) start
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (4.0.3)
1|Active | 1|Apache Felix Bundle Repository (1.6.6)
2|Active | 1|Apache Felix File Install (3.2.4)
3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
4|Active | 1|Apache Felix Gogo Shell (0.10.0)
5|Active | 1|Apache Felix Gogo Command (0.12.0)
g! gosh: stopping framework
--
Derek
On 15 October 2012 14:03, Per-Erik Svensson <pe...@gmail.com>wrote:
> Hi,
>
> I get the following exception when trying to start gogo-command
> automatically through fileinstall:
>
> In main loop, we have serious trouble: java.lang.RuntimeException:
> java.lang.InterruptedException
> java.lang.RuntimeException: java.lang.InterruptedException
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> Caused by: java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> ... 3 more
> In main loop, we have serious trouble: java.lang.RuntimeException:
> java.lang.InterruptedException
> java.lang.RuntimeException: java.lang.InterruptedException
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:332)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.refresh(DirectoryWatcher.java:677)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:494)
> at
>
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)
> Caused by: java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at
>
> org.apache.felix.fileinstall.internal.FileInstall.refresh(FileInstall.java:330)
> ... 3 more
>
> "What did you do to make this happen?"
>
> Originally through an embedded version of felix 4.0.2. To make sure that it
> was not my code, through dist of felix 4.0.3.
>
> All I have done is to unpack the Felix Framework Distribution, removed gogo
> commands from the bundle directory (to make it not auto-install/start from
> felix itself) and added gogo commands to a fileinstall-controlled
> directory. Of course, I put fileinstall in the bundle directory of felix
> (to make it auto-install).
>
> Note that this only happens when gogo command is installed from
> fileinstall. If felix installs and starts it from the bundle dir, it works
> like a charm. It also only happens with gogo command, other bundles can be
> installed properly through fileinstall. I'm thus not sure if this is a bug
> in fileinstall, gogo command or simply an error 40 issue (the guy sitting
> 40 cm from the screen).
>
> All versions used are the ones currently available from the felix download
> site.
>
> Felix Framework Distribution 4.0.3
> Fileinstall 3.2.4
> Gogo Command 0.12.0
>
> Other bundles installed (coming from distribution)
> Bundle Repository 1.6.6
> Gogo Runtime 0.10.0
> Gogo Shell 0.10.0
>
> Is this maybe some weird dependency thing making the framework try to
> refresh itself? If so, is it possible to resolve in any way?
>
> Best regards,
> Per-Erik Svensson
>