Failed to start: SocketListener
What can I do about the following error message: "org.mortbay.util.ThreadedServer start WARNING: Failed to start: SocketListener0@0.0.0.0:80"?

Answer: This is most probably because another process is using the same port as the jetty bundle. You can set the port with a VM argument ( -Dorg.osgi.service.http.port=8080).


OntologyCreator missing javac compiler
When executing the ant-file in the OntologyCreator I get the following error message: "BUILD FAILED C:\Workspace\Open-AAL\OntologyCreator\ant\createOntology.xml:31: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath."?

Answer: Ant cannot find the javac compiler file. If this happens in Eclipse you should check whether the installed JRE (eclipse->preferences->java->installed JRE) does contain the file. If not, you can install a JDK version instead.


Incorrect javaClassOntology API is created
I get a strange and unexpected javaClassOntology API when creating one with OntologyCreator. For example, properties that I marked functional are not functional in the javaClassOntology API or Classes contain get methods for the wrong properties. What can I do about this?

Answer: Internally, we use the jenaAPI to read the OWL xml file. If you have used a modelling tool, the tool will automatically create an OWL xml file that captures the semantics of your OWL ontology. Unfortunately, there are many ways to parse OWL into xml, some of which may cause problems when parsing them with jenaAPI. Check your OWL file against the openAALOntology.owl file that is shipped and compare whether defintion of properties and functional properties match to each other. The openAAL team is using Protege 3.4.4 for modelling ontologies which is usually working fine.


Problems with context class loading when usig java.beans, J2EE container, Applet container ...
I get an Error message like this "ClassLoader cannot be null" deep inside java.beans packages when usinig them in openAAL application code. What can I do to resolve this problem?

Answer: This is well-known OSGi incompatibility with some java packages in relation to context class loading. You can find additional information here: http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements. What mostly works is to start the third party code in seperate thread and add the context class loader to that thread:
//in parent thread
final ClassLoader classLoader = getClass().getClassLoader();
...
//in child thread before third-party code is started
Thread.currentThread().setContextClassLoader(classLoader);