Why do't the resolver threads shutdown in apache Felix - osgi

I'm trying to embed Felix in Embedded Tomcat. Everything works fine. However when shutting down the Felix framework (have deployed SCR, cm, event admin, and metatype services) it will give me a framework shutdown event. But the threads is still alive in the ResolveImpl executor.
So I've got a bunch of "FelixResolver-" threads still dangling. I cannot force the shutdown of the threads since they belong to the executor.
Shutdown sequence:
framework.stop();
final FrameworkEvent fe = framework.waitForStop(wait);
and I get
fe.getType() == FrameworkEvent.STOPPED.
Felix Framework is 'org.apache.felix.framework-5.6.1.jar'
I'm using the following felix bundles:
org.apache.felix.configadmin-1.8.14.jar
org.apache.felix.eventadmin-1.4.8.jar
org.apache.felix.log-1.0.1.jar
org.apache.felix.metatype-1.1.2.jar
org.apache.felix.scr.compat-1.0.4.jar
org.apache.felix.scr-2.0.8.jar
I manually install and start the bundles. I'm not stopping the bundles, instead I stop the framework bundle using the above.
Install order (start order is the same after installing):
org.apache.felix.configadmin [version 1.8.14]
org.apache.felix.eventadmin [version 1.4.8]
org.apache.felix.log [version 1.0.1]
org.apache.felix.metatype [version 1.1.2]
org.apache.felix.scr [version 2.0.8]
org.apache.felix.scr.compat [version 1.0.4]
What am I doing wrong?
Cheers,
Mario
EDIT 1:
I've upgraded to felix framework 5.6.2 but the issue still remains.

Related

OSGI resolution error - missing system.bundle

I'm suddenly getting the following weird resolution error:
[ERROR] Resolution failed. Capabilities satisfying the following requirements could not be found:
[<<INITIAL>>]
? osgi.identity: (osgi.identity=javafx-osgi)
? [javafx-osgi version=8.0.2]
? osgi.wiring.host: (osgi.wiring.host=system.bundle)
It appears that the system bundle (Apache Felix framework) is no longer being found... Oddly, this error just popped up today. I havent worked on this project for a week. But the last commit ran without a problem. If I revert to an earlier revision of the program, the problem remains...
We are using Java 1.8.0 161-b12; BND Tools 4.0.0 and Apache Felix Framework 1.8.
Our app.bndrun looks like this:
index: target/index.xml
-standalone: ${index}
-runrequires: osgi.identity;filter:='(osgi.identity=org.ops4j.pax.logging.pax-logging-service)', \
osgi.identity;filter:='(osgi.identity=javafx-osgi)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.command)',\
osgi.identity;filter:='(osgi.identity=com.foo.bar.testservice)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.main-screen)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.verify-screen)', \
osgi.identity;filter:='(osgi.identity=com.foo.bar.testclient)'
-runfw: org.apache.felix.framework;version='5.6.8'
-runee: JavaSE-1.8
-runbundles: \
com.foo.bar.testservice;version='[0.0.1,0.0.2)',\
org.apache.felix.scr;version='[2.1.0,2.1.1)',\
org.osgi.service.log;version='[1.4.0,1.4.1)',\
org.osgi.util.function;version='[1.1.0,1.1.1)',\
org.osgi.util.promise;version='[1.1.0,1.1.1)',\
org.osgi.util.pushstream;version='[1.0.0,1.0.1)',\
com.foo.bar.testclient;version='[0.0.1,0.0.2)',\
org.ops4j.pax.logging.pax-logging-api;version='[1.10.1,1.10.2)',\
org.ops4j.pax.logging.pax-logging-service;version='[1.10.1,1.10.2)',\
javafx-osgi;version='[8.0.2,8.0.3)',\
com.foo.bar.launcher;version='[0.0.1,0.0.2)',\
com.foo.bar.main-screen;version='[0.0.1,0.0.2)',\
com.foo.bar.ui-main;version='[0.0.1,0.0.2)',\
com.foo.bar.verify-screen;version='[0.0.1,0.0.2)',\
org.apache.felix.configadmin;version='[1.9.2,1.9.3)',\
com.foo.bar.launcher;version='[0.0.1,0.0.2)',\
com.foo.bar.command;version='[0.0.1,0.0.2)'
-runproperties: felix.cm.dir="${user.home}\\Documents\\Prog731\\config"
This is a small demo program with very few dependencies. As far as I can determine, neither our code nor any the external dependencies have changed. But the problem is reproducible on different development machines...
What could cause a resolution error such as this?
UPDATE:
We are using the latest development snapshots of the bndtools 4.x from the https://bndtools.ci.cloudbees.com repository. Might this be it?
UPDATE #2:
As Requested, the MANIFEST of javafx-osgi-8.0.2.jar:
Manifest-Version: 1.0
Export-Package: com.sun.javafx, com.sun.glass.ui, com.sun.javafx.anima
tion, com.sun.javafx.applet, com.sun.javafx.application, com.sun.java
fx.beans, com.sun.javafx.beans.event, com.sun.javafx.binding, com.sun
.javafx.charts, com.sun.javafx.collections, com.sun.javafx.css, com.s
un.javafx.css.converters, com.sun.javafx.css.parser, com.sun.javafx.c
ursor, com.sun.javafx.effect, com.sun.javafx.embed, com.sun.javafx.ev
ent, com.sun.javafx.font, com.sun.javafx.font.coretext, com.sun.javaf
x.font.directwrite, com.sun.javafx.font.freetype, com.sun.javafx.font
.t2k, com.sun.javafx.fxml, com.sun.javafx.fxml.builder, com.sun.javaf
x.fxml.expression, com.sun.javafx.geom, com.sun.javafx.geom.transform
, com.sun.javafx.geometry, com.sun.javafx.iio, com.sun.javafx.iio.bmp
, com.sun.javafx.iio.common, com.sun.javafx.iio.gif, com.sun.javafx.i
io.ios, com.sun.javafx.iio.jpeg, com.sun.javafx.iio.png, com.sun.java
fx.image, com.sun.javafx.image.impl, com.sun.javafx.jmx, com.sun.java
fx.logging, com.sun.javafx.media, com.sun.javafx.menu, com.sun.javafx
.perf, com.sun.javafx.print, com.sun.javafx.property, com.sun.javafx.
property.adapter, com.sun.javafx.robot, com.sun.javafx.robot.impl, co
m.sun.javafx.runtime, com.sun.javafx.runtime.async, com.sun.javafx.ru
ntime.eula, com.sun.javafx.scene, com.sun.javafx.scene.control, com.s
un.javafx.scene.control.behavior, com.sun.javafx.scene.control.skin,
com.sun.javafx.scene.control.skin.caspian, com.sun.javafx.scene.contr
ol.skin.caspian.images, com.sun.javafx.scene.control.skin.modena, com
.sun.javafx.scene.control.skin.resources, com.sun.javafx.scene.input,
com.sun.javafx.scene.layout, com.sun.javafx.scene.layout.region, com
.sun.javafx.scene.paint, com.sun.javafx.scene.shape, com.sun.javafx.s
cene.text, com.sun.javafx.scene.transform, com.sun.javafx.scene.trave
rsal, com.sun.javafx.scene.web, com.sun.javafx.scene.web.behavior, co
m.sun.javafx.scene.web.skin, com.sun.javafx.sg, com.sun.javafx.sg.pri
sm, com.sun.javafx.sg.prism.web, com.sun.javafx.stage, com.sun.javafx
.text, com.sun.javafx.tk, com.sun.javafx.tk.quantum, com.sun.javafx.u
til, com.sun.javafx.webkit, com.sun.javafx.webkit.drt, com.sun.javafx
.webkit.prism, com.sun.javafx.webkit.prism.resources, com.sun.javafx.
webkit.prism.theme, com.sun.javafx.webkit.theme, javafx, javafx.anima
tion, javafx.application, javafx.beans, javafx.beans.binding, javafx.
beans.property, javafx.beans.property.adapter, javafx.beans.value, ja
vafx.collections, javafx.collections.transformation, javafx.concurren
t, javafx.css, javafx.embed, javafx.embed.swing, javafx.event, javafx
.fxml, javafx.geometry, javafx.print, javafx.scene, javafx.scene.canv
as, javafx.scene.chart, javafx.scene.control, javafx.scene.control.ce
ll, javafx.scene.effect, javafx.scene.image, javafx.scene.input, java
fx.scene.layout, javafx.scene.media, javafx.scene.paint, javafx.scene
.shape, javafx.scene.text, javafx.scene.transform, javafx.scene.web,
javafx.stage, javafx.util, javafx.util.converter, com.sun.deploy.uito
olkit.impl.fx
Fragment-Host: system.bundle; extension:=framework
Bundle-ManifestVersion: 2
Bundle-Name: JavaFX 8 OSGi extension bundle
Bundle-License: The Apache License, Version 2.0
Bundle-SymbolicName: javafx-osgi
Bundle-Version: 8.0.2
UPDATE #3:
I think the javafx-osgi issue is not the real problem. I threw out all FX related stuff and ended up with an error saying "No OSGi framework has been added to the run path"?!
This seems to be a bug in the felix resolver:
Insights from the Bndtools bugtracker: https://github.com/bndtools/bndtools/issues/1877
Felix bugtracker: older issue with felix 5.4.0 and bndtools 3.4.0 ResolverImpl infinite loop
The above felix ticket has been open for over a year and there doesn't seem a solid understanding (yet) what the root cause is.
For those who hit the same roadblock: We ended up switchting to eclipse equinox.

Starting a payara 5 has encountered

I have build a very simple project of hello world in
Payara 5 (5.181)
JSF 2.3
JDK 1.8
CDI 2.0
Maven
and encountered a problem
Unable to start server due following issues: Launch process failed with exit code 1
in console it throws an error of :
Error: Could not find or load main class server\payara5\glassfish.lib.grizzly-npn-bootstrap.jar
[PIC] Payara 5 Error
It seems that the Payara Tools for Eclipse suffer by several bugs that may cause this. In my case, the following workarounds helped:
The Payara installation path should not contain spaces (e.g. Program Files\Payara)
It seems that only Java 8 is supported at the time
Open the domain.xml configuration file for the domain you are trying to start (typically payara_install_path/glassfish/domains/domain1/config/domain1.xml) and search for "Xbootclasspath". You should find a couple of lines like
<jvm-options>[1.8.0|1.8.0u120]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.6.jar</jvm-options>
<jvm-options>[1.8.0u121|1.8.0u160]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.7.jar</jvm-options>
<jvm-options>[1.8.0u161|1.8.0u190]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.jar</jvm-options>
<jvm-options>[1.8.0u191|1.8.0u500]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
Depending of your installed Java version (try running java --version) and choose the appropriate line (most likely the last one). Remove the remaining lines and remove the [...] part at the beginning of the chosen line so you will get something like
<jvm-options>-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
After this, the tools seem to start normally.
The Problem is with Java version. The grizzly-npn-bootstrap-1.8.1.jar Jar is placed in bootclasspath, thats why it requires proper java version to start payara server. So remove unnecessary bootstrap jar from domain.xml.
In Windows:
1) Go To ---C:\Users\xxxx\payara5\glassfish\domains\domain1\config\domain.xml
2) According to my java verson(java version "1.8.0_191") I deleted the following lines from domain.xml. So delete according to your java version.
<jvm-options>[1.8.0|1.8.0u120]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.6.jar</jvm-options>
<jvm-options>[1.8.0u121|1.8.0u160]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.7.jar</jvm-options>
<jvm-options>[1.8.0u161|1.8.0u190]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.jar</jvm-options>
3) Remove this [1.8.0u191|1.8.0u500] part from jvm-options & Edit the line in your domain.xml(w.r.t java -version) as shown below
<jvm-options>-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
4) restart your server.
As Radkovo said, "The Payara installation path should not contain spaces (e.g. Program Files\Payara)", so I moved the Payara to the Documents folder.
Problem solved!

Cannot start a service instance in Virtuoso-opensource

I'm trying to create and start the service instance. But it doesn't start.
Here is the command I ran:
virtuoso-t +service start +instance MyService
Here my output:
The Virtuoso_MyService service is being started
But the localhost:8890 cannot be loaded.
Details:
Opened CMD as administrator.
Ran the same commands 3 days back and the services were running fine till I restarted the system.
Commands followed.
C:\Users\username\Desktop\foldername\MyWork\virtuoso-opensource\bin>virtuoso-t +service create +instance MyService +configfile ..\database\virtuoso.ini
[Using virtuoso.ini in C:\Users\username\Desktop\foldername\MyWork\virtuoso-opensource\database]
The Virtuoso_MyService service has been registered
and is associated with the executable
C:\Users\username\Desktop\foldername\MyWork\virtuoso-opensource\bin\virtuoso-t.exe
C:\Users\username\Desktop\foldername\MyWork\virtuoso-opensource\bin>virtuoso-t +service start +instance MyService
The Virtuoso_MyService service is being started
C:\Users\username\Desktop\foldername\MyWork\virtuoso-opensource\bin>virtuoso-t +service list +instance MyService
MyService Stopped
As suggested by #TallTed, I have added the log:
Wed Mar 01 2017
16:27:37 { Loading plugin 1: Type `plain', file `wikiv' in `../hosting'
16:27:37 WikiV version 0.6 from OpenLink Software
16:27:37 Support functions for WikiV collaboration tool
16:27:37 SUCCESS plugin 1: loaded from ..\hosting\wikiv.dll }
16:27:37 { Loading plugin 2: Type `plain', file `mediawiki' in `../hosting'
16:27:37 MediaWiki version 0.1 from OpenLink Software
16:27:37 Support functions for MediaWiki collaboration tool
16:27:37 SUCCESS plugin 2: loaded from ..\hosting\mediawiki.dll }
16:27:37 { Loading plugin 3: Type `plain', file `creolewiki' in `../hosting'
16:27:37 CreoleWiki version 0.1 from OpenLink Software
16:27:37 Support functions for CreoleWiki collaboration tool
16:27:37 SUCCESS plugin 3: loaded from ..\hosting\creolewiki.dll }
16:27:37 { Loading plugin 4: Type `plain', file `im' in `../hosting'
16:27:37 IM version 0.6 from OpenLink Software
16:27:37 Support functions for Image Magick 6.6.7
16:27:37 SUCCESS plugin 4: loaded from ..\hosting\im.dll }
16:27:37 { Loading plugin 5: Type `plain', file `wbxml2' in `../hosting'
16:27:37 WBXML2 version 0.9 from OpenLink Software
16:27:37 Support functions for WBXML2 0.10.7 Library
16:27:37 SUCCESS plugin 5: loaded from ..\hosting\wbxml2.dll }
16:27:37 Unable to create file virtuoso.lck (File exists).
16:27:37 This probably means you either do not have permission to start
16:27:37 this server, or that virtuoso-t is already running.
16:27:37 If you are absolutely sure that this is not the case, please try
16:27:37 to remove the file virtuoso.lck and start again.
The answer is in the Virtuoso log file --
16:27:37 Unable to create file virtuoso.lck (File exists).
16:27:37 This probably means you either do not have permission to start
16:27:37 this server, or that virtuoso-t is already running.
16:27:37 If you are absolutely sure that this is not the case, please try
16:27:37 to remove the file virtuoso.lck and start again.
Removing the virtuoso.lck as advised there should resolve the issue.
In a normal shutdown, Virtuoso will clean up this file. If power is cycled, or the Virtuoso process is otherwise uncleanly terminated, this file may linger, as in this case, and so need to be manually removed.
The Virtuoso website has a vast amount of information, including the official Virtuoso manual and the evolving docs, covering Open Source in more detail.
ObDisclaimer: OpenLink Software produces Virtuoso, and employs me.
I was having the same issues on windows 10. I fixed by going to my
C:\Program Files\OpenLink Software\Virtuoso OpenSource 7.2\database
and manually delete virtuoso.lck file
The restart my server and everything now started working fine!

Missing some spoon steps (plugins) at runtime (KarafLifecycleListener Error)

I am using open-source Pentaho distribution from github.com (version 6.1-SNAPSHOT).
In Spoon there are some step missing (e.g. There is no Mongodb input/output step listed) and I cant add dataservice to step (There are no errors, this option just isn't on the list).
I have reinstalled everything (removed .kettle and .pentaho directories as well as whole source and distribution) but it didn't help.
This is what I get at spoon startup:
16:05:50,304 INFO [KarafInstance]
* Karaf Instance Number: 1 at ~/pentaho-kettle/d
ist/./system/karaf//data1
Karaf Port:8801
OSGI Service Port:9050 *
Dec 23, 2015 4:05:51 PM org.apache.karaf.main.Main$KarafLockCallback
lockAquired
INFO: Lock acquired. Setting startlevel to 100
2015/12/23 16:05:53 - cfgbuilder - Warning: The configuration
parameter [org] is not supported by the default configuration builder
for scheme: sftp
Dec 23, 2015 4:05:58 PM
org.pentaho.caching.impl.PentahoCacheManagerFactory$RegistrationHandler$1
onSuccess INFO: New Caching Service registered
16:06:04,009 ERROR [KarafLifecycleListener] The Kettle Karaf Lifycycle
Listener failed to execute properly. Releasing lifecycle hold, but
some services may be unavailable.
I suspect that
ERROR [KarafLifecycleListener] The Kettle Karaf Lifycycle Listener
failed to execute properly. Releasing lifecycle hold, but some
services may be unavailable.
has something to do with it as missing plugins reside somewhere under karaf/ directory.
It was working just fine week ago.
I am using Ubuntu 15.04.
I will be grateful for any hints.
Greetings.
you are using a non stable release. this is the place where you can download the latest stable release http://sourceforge.net/projects/pentaho/
Agreed with jipipayo, For Pentaho CE version, download it from http://community.pentaho.com/ official instead of github. It is highly possible that the codes in github might be in unstable condition.
Also in case you have a missing plugin, try using the Pentaho Marketplace and download the required plugins.
Hope this helps :)

Eclipse plug-ins disappeared after update

Have been updated Eclipse PDT using Window->Check for Updates feature.
After restart all trird-party plug-ins seems like switched off.
Starting with -clean command line key doesn't helps.
Eclipse Installation Detals contains information about all my plug-ins correctly.
Error log:
eclipse.buildId=M20090917-0800
java.version=1.6.0_05
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=ru_RU
Framework arguments: -product org.eclipse.epp.package.php.product
Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.php.product
!ENTRY org.eclipse.team.core 4 0 2009-11-24 12:52:00.804
!MESSAGE Could not instantiate provider org.eclipse.team.svn.core.svnnature for project Search.
!STACK 1
org.eclipse.team.core.TeamException: Could not instantiate provider org.eclipse.team.svn.core.svnnature for project Search.
at org.eclipse.team.core.RepositoryProvider.mapNewProvider(RepositoryProvider.java:165)
at org.eclipse.team.core.RepositoryProvider.mapExistingProvider(RepositoryProvider.java:235)
at org.eclipse.team.core.RepositoryProvider.getProvider(RepositoryProvider.java:507)
at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.isMappedToCVS(CVSLightweightDecorator.java:192)
at org.eclipse.team.internal.ccvs.ui.CVSLightweightDecorator.decorate(CVSLightweightDecorator.java:147)
at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:263)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365)
at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371)
at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
!SUBENTRY 1 org.eclipse.team.core 4 0 2009-11-24 12:52:00.804
!MESSAGE Could not instantiate provider org.eclipse.team.svn.core.svnnature for project Search.
Mar Cel was right:
Here i have write it in my german language wiki.
You need to chown the eclipse-programm-folder to full access permissions for the workspace-owner.
Start eclipse. Stop it, Rechange the owner back to root, and restart eclipse again.. After that, all works well for me (Eclipse 3.7.2)
Wiki
http://wiki.xstable.de/doku.php/entwicklungsumgebung:eclipse:faq?&#keine_plugins_mehr_in_eclipse_nach_update
Solution is use Equinox p2 Installer!
There is no other offline ways to install/reinstall plugins or features.
This seems to be an issue with writing permission of the Eclipse executing user. My guess is that the user can write metadata to workspace, therefore Eclipse shows you that the plugins were installed successfully but are obviously not available in the GUI, as none of the features were really installed in Eclipse itself.
Just alter the Eclipse program folders to give full permissions to the user actually executing Eclipse. Eclipse will then recognize that the metadata is wrong, repair them, and let you install the plugins once again. After that, all features will be available.

Resources