Problems and Fixes

It does not work ... follow the Commandments

With any problem, before you do anything further, first adhere to the Commandments Of Debugging::

1. run the software with the runtime parameters: -consoleLog -noexit. This will let you see crucial exceptions in the console
2. Examine the log file. The log file is in the workspace data directory, which is configured in your run configuration in the field Workspace data/Location. On my machine the log file is here (given my workspace is c:\workspace): C:\runtime-PSEWCompleteProduct.product\.metadata\.log
3. Examine if the plugins validate. Press the Validate Plugins button on the Plug-ins tab in the run configuration

It is the wise man who follows the Commandments, and joy and productiveness will follow., Kevin Mitnick

Not compiling workspace (nothing compiles)

If your workspace do not compile after updating, you should try to

• reload target platform
• and clean your workspace
• sometimes restarting eclipse helps
• track down the problem: what did change when you updated? If there are weird symptoms, there is always a problem that waits to be fixed.
• If all this does not help, start with a new workspace

Every problem can be solved, for example LeoSauermann never had to start a new workspace in two years. If these practices do not help, it's more sophisticated problem - track it down, write the symptoms and the solution here.

The Nepomuk product doesn't start at all

If there is no output after pressing the "Launch the product" button, and it terminates immediately you might have to delete the Run / Debug configuration of the Nepomuk product and then "Launch the product" again. Alternatively, you could check the "Clear configuration are before launching" option here: Run -> Run... -> Statr Nepomuk -> Configuration:

If the problem stays:

• delete the run target and recreate it again (will also delete all your data inside the nepomuk server started this way)
  • Run... -> see for the Eclipse Application header on the left, select org.semanticdesktop.nepomuk.server.product. Delete it.
  • create it again using the product:
  • double-click on the org.semanticdesktop.nepomuk.server.product file in the project of the same name
  • click on "Launch the product"
• check if all dependencies are there
  • start the thing, see for log messages
  • on the console, type ss to display status of services
  • on Run ... -> org.semanticdesktop.nepomuk.server.product -> Plugins -> Validate Plugin Set
• Check if your dependencies compile
  • usually, plugins from the Eclipse Target Platform work. Plugins inside the workspace may not. Check this.

My plugin doesn't start

Check if all required plugins are in the launch configuration. To do this, press "debug ... select your project ... plugins ... validate plugins"

My service breaks and I get no log messages

If your service throws mysterious NullPointerException or has other problems, you may want to enable logging for OSGI.

One way to get more log messages is:

• Try to switch on the full tracing of all plug-ins:
  • YourDebugConfig > "Tracing > Enable tracing for the selected plug-ins"

I can't export/compile my plugin

If you use the Export Wizard of Eclipse to export the OSGI plugin, it could happen that the plugin does not compile. You notice that through the logs.zip file in the EclipseTargetPlatform. For example, the org.osgi.services.http package was not found. But - its there.

Fix: download the source of the required package, then it works.

I get the "Access restriction: The type xxxxx is not accessible due to restriction on required project.." compilation error

• If you just created a new service interface, then you probably forgot to add it in the "Exported Packages" of the .services project.
• If you encounter rt.jar Restrictions (on com.sun... classes for example) - these seem to be built-in Restrictions of Eclipse 3.3/OSGi and indicate you are doing something deprecated in OSGi. Try to do it "the right way".

A plugin packaged as .jar file does not work

You package a plugin either as folder or as a .jar file. You plugin does mysterously not work when packaged as jar, packaged as folder it works perfectly from the Eclipse Target Platform.

The difference between packaging plugins as jar and folder is that when packages as JAR, the plugin must not contain any libraries as JAR files but instead all libraries must be unzipped and the class/resource files must be subfolders of the plugin.

The classpath directive does magically not work in these cases.

Gunnar Says: The real reason here is that eclipse only supports a single level of jarring, and a single level only, i.e. if you have a plugin in a folder then all classes must be in a jar, and if you have a plugin as a jar they must NOT be in a jar. This is only true for eclipse at compile time, at runtime OSGI is quite happy to deal with jars with jars. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=111238

Solution: Package a plugin as a jar if and only if it doesn't embed other jars. Package it as a folder if it contains only jars and nothing else. Having both class files and jars in one plugin will lead to problems.

Alternatively, instead of putting library jar into a plugin, convert it into a plugin of its own, extracting all classes from the jar (or from several jars that make a library). Eclipse can do it using wizard at File > New > Project > Plug-in development > Plug-in from existing JAR archive. There are also other tools like Bnd http://www.aqute.biz/Code/Bnd. Besides, an OSGi bundle packaged as a jar without any embedded jars can still be used as a normal jar archive to use without Eclipse/OSGi.

Another thing to watch out for is the build tab of the manifest editor. Eclipse should keep this correct by itself, but sometimes it gets corrupted. You need to check at least META-INF and bin for binary and META-INF, bin and src for source. In addition the libraries on top must be set for all classpath entries. Here is a screenshot of the correct setup for the middleware.clientlibrary:

The import ... cannot be resolved

In Eclipse, you open a project that used to work forever and suddenly...

• the import javax.servlet cannot be resolved
• etc..

This is usually caused because any plugin cannot find some dependency. Ways have solved this problem before:

• You get a more precise error message when starting the product (which generates a run target) and pressing "validate plugin set" in the eclipse/run menu. Based on these error messages, work your way through the broken plugins.
• Go to window -> prefererences -> plugin development -> target platform. Press "reload" (in the right column)
• Clean all projects
• Do above repeatedly: reload/clean
• When the missing dependency is from an org.semanticdesktop.* package, this problem can be "hacked" by checking out the imported source package from SVN. For example, when org.semanticdesktop.nepomuk.util.ServletUtil? cannot be resolved, download org.semanticdesktop.nepomuk.server.app into your workspace. This is a not-so-good fix, because still some other plugin causes troubles and you should try to find the initial problem.

Most often, after all Manifest.MF files are corrected, the "cannot be resolved" messages of totally independent packages are solved. If not, common mistakes:

• you import org.apache.commons.logging using a bundle dependency, switch to package dependency, if nothing works, set the version numer. This import can be in any MANIFEST.MF inside the whole project.

The repository is not cleaned when the Runtarget is delete

To ensure that the "workspace" can really be cleanded up, ensure, that the services are all closed. Otherweise the cleanup can not proceed and the repository will be used on the next product launch.

Optional Dependencies did not work, does re-exporting?

On some machines, even with exactly the same code and distribution, optional dependencies would not be found. Optional dependencies are a way to add dependencies in Manifest.MF files using the "resolution=optionsl". So we would not recommend to use optional dependencies anymore.

This causes trouble (not jsp, the optional part):

 javax.servlet.jsp.el;version="2.0.0";resolution:=optional,

In contrast, we think that re-exporting dependencies seems to work. Re-exporting seems to be quite handy, until proven otherwise we would recommend to use it:

 org.semweb4j.rdf2go.api;visibility:=reexport,

BundleException?: The activator ...Activator ... is invalid

If you get an exception like this:

 org.osgi.framework.BundleException: The activator org.semanticdesktop.nepomuk.comp.folkpeer.Activator for bundle org.semanticdesktop.nepomuk.comp.folkpeer is invalid
 ...
 Caused by: java.lang.ClassNotFoundException: org.semanticdesktop.nepomuk.comp.folkpeer.Activator

the following unfortunately did not help me to solve the problem:

Right-Click on org.semanticdesktop.nepomuk.server.product -> Run As -> Open Run Dialog ...

Delete the org.semanticdesktop.nepomuk.server.product Run-Configuration (right-click on org.semanticdesktop.nepomuk.server.product in the left column and then "delete")

You cannot find javax.jws

We support Java 1.5. To include javax.jws (part of java 1.6) we added it as a bundle.

We set execution environment for org.semanticdesktop.services to J2SE-1.5. All plugins should have set this.

After this change the services bundle did no longer compile. If you only have java 6 installed and setting the java environment to 1.5 will use the 1.6 libraries (rt.jar, etc.) but with access restrictions on new packages.

The errors are:

Access restriction: The type WebService is not accessible due to
restriction on required library
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/rt.jar	

So, even thought the javax.jws bundle is included through the bundle dependencies, it barfs at the forbidden package from rt.jar first.

Gunnar found that the solution lies in the order of the lines in the .classpath file, i.e. make sure the bundle dependencies are include first:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
        <classpathentry kind="src" path="src"/>
        <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
        <classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
        <classpathentry kind="output" path="bin"/>
</classpath>

Ricardo had the same error, but very strange, only for one of the several services he checked out. What we did to solve this problem was to remove the Execution Environment setting (it was J2SE-1.5 while we he has only jre1.6.0_03) specified in the Manifest of the component where this compilation error appeared (the javax.jws was not found) and then clicked on "Update the classpath and the compiler compliance settings". This made the compilation error dissapear. Before we tried to solve it by editing by hand the .classpath file and setting it in the order Gunnar proposed, this did not solve the problem.

The plugin is not installed

• The plugin is valid
• its in ETP
• it is listed in your "Target Platform"
• you selected it in the run-target and pressed "Validate plugins"
• But you can't find it when typing ss on your OSGi console

Its simply not in the list of installed plugins

That was (in one case) bound to the problem of operating-system dependend native libraries. For example, such lines:

Bundle-NativeCode: ./lib/windows/jsmile.dll; osname=Windows 2000; osname=Windows XP; osname=Windows Vista; processor=x86 ,
 lib/amd64/libjsmile.so; osname=linux; processor=x86-64,
 lib/x86/libjsmile.so; osname=linux; processor=x86,
 lib/amd64/libjsmile.so; osname = linux ; processor = amd64

If you remove them, and build the plugin again, it may be installed, but you lose the libraries.

Solution: You should not embed dependencies in NEPOMUK plugins. You should rather wrap the dependencies.

• EclipseDevelopment#Bundlingexternaldependencies

The plugin is not started in the nightly build

You added your plugin, it works good in eclipse, but in the nightly build the plugin is not started automatically on startup, and then other things crash. Especially weird is when you start with -console -noExit and are able to see your plugin with ss command and can start it using start org.openrdf.rdf2go.

This message is printed in the log-files in /workspace/ or in /config/

!ENTRY org.eclipse.osgi 4 0 2008-05-02 18:06:22.382 !MESSAGE Bundle org.openrdf.rdf2go@10:start not found.

Solution: It seems that the program interpreting the config.ini somehow depends on the jar-file/folder of the osgi plugin being called exactly like the symbolic-name with the exact same version number.

The correct naming is: org.openrdf.rdf2go_4.6.2.jar

The Java Virtual Machine Crashes

A good one. As said in ticket:

You get something like this:

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d83de95, pid=2200, tid=1304
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x7de95]
#
# An error report file with more information is saved as hs_err_pid2200.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

As you see, the report does not say where the error report is exactly stored. It is actually stored in the installation folder of Eclipse, where your eclipse.exe resides or in totally unrelated crazy places. Error Reports are found in these folders and can be attached to ticket:414

• c:\programme\eclipse
• C:\Programme\eclipse_3.3_europa\eclipse
• c:/Programme/Gemeinsame Dateien/System/MSMAPI/1031/hs_err_pid2200.log (who would have thought)

If the machine crashes, you must analyse the stacktraces inside the error report to find out more. The stacktraces give you hints why the machine crashed, for example if you find problems in win32, you may have screwed windows by using JNI or other connectors (jacob/aperture's microsoft outlook crawler, COM/OLE, etc).

PSEW won't start - No Application ID has been found

There is a case when PSEW starts but doesn't show the GUI and instead shuts down immediately. A crucial message in the stack trace/console log is

java.lang.RuntimeException: No application id has been found.
at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:229)
at org.eclipse.equinox.internal.app.EclipseAppContainer.start(EclipseAppContainer.java:92)
at org.eclipse.equinox.internal.app.Activator.addingService(Activator.java:129)
...

When it crashes, it offers you to "view the error log in an editor". Do that. Read the stacktraces. Look for this:

• cannot install library in bundle B from "xy.so" from lib/xy.so.
  • Your manifest is broken and you reference a missing library. Fix the manifest
  • Your manifest is broken and you forgot to add this library to the src or binary build. Fix the manifest.

In simple cases, you just forgot to stick to the Commandments - validate plugins!

Error installing bundle

When you start NEPOMUK from the installed version and have been fiddling around with config.ini or have updated bundles by copying a new jar into the plugins folder, it can happen that you see this in your error log file:

!MESSAGE Error installing bundle: reference:file:plugins/org.semanticdesktop.nepomuk.comp.taskservice_0.5.1.jar/
!STACK 0
org.osgi.framework.BundleException: Bundle "org.semanticdesktop.nepomuk.comp.taskservice" version "0.5.1" has already been installed from: update@plugins/org.semanticdesktop.nepomuk.comp.taskservice_0.5.1.jar

Solution:

eclipse -clean

see: Eclipse runtime options documentation.

Unsupported Class Version Error

...Compiled with future Java 8 Beta 9...: Sometimes the bunch of developers compiles with a random future release of Java. You get this:

Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file
	at java.lang.ClassLoader.defineClass1(Native Method)

Solution: find the class with the wrong java version number using the Bytecode version inspector utility, then re-export (recompile) the guilty plugin. Set the Version number in the manifest file. Set the java version to 5 in your global workspace settings.

Cannot find java.lang.Object in classpath

A classic. of course, the description itself shuns sanity. Tactics:

• close/open project, refresh (F5), clean (worked once)