[deepamehta-users] deepamehta-2.0b8-rc4 Erfolgs und Fehlerreport

[Jörg Richter]

Liebe DeepaMehta-Nutzer,

hier möchte ich endlich auf den sehr hilfreichen Erfolgs- und  
Fehlerreport von Torsten eingehen.

Torsten spricht hier durchweg relevante Punkte an, über die ein  
DeepaMehta-Neuling stolpern wird, insbesondere, wenn es um die  
Webanwendungen geht. Der neue Installer von Enrico ist für das  
"eigentliche" DeepaMehta schon wunderbar, benötigt im Bereich der  
Webanwendungen aber noch einige Verbesserungen, die ich im Folgenden  
anspreche. Hier hoffe ich, daß Enrico Gelegenheit findet, weiter am  
Installer zu arbeiten. Zu einigen der genannten Probleme weiß ich noch  
nicht, was die beste Lösung ist. Hier hoffe ich auf gemeinsame  
Diskussion, wobei alle Entwickler gefragt sind.

Ich kann mir auch gut vorstellen, bald einen DeepaMehta-Stammtisch zu  
veranstalten, zu dem alle DeepaMehta-Anwender eingeladen werden. Das  
direkte Gespräch ist doch manchmal effektiver, wenn es um soviele  
Punkte aufeinmal geht. Zu diesem Stammtisch sollten dann mindestens  
kommen: Torsten, Malte, Thilo, Martin, Enrico. Außerdem brauchen wir  
einen Moderator, damit die Gespräche nicht aus dem Ruder laufen, d.h.  
damit konkrete Beschlüsse gefasst und Aktionen verabredet werden. Ich  
würde mich freuen, wenn es jemand in die Hand nimmt, solch einen  
Stammtisch zu organisieren.

Zuletzt möchte ich Torsten ermutigen, Fehlerreports auch in unseren  
Bug-Tracker auf Berlios einzupflegen. Es wäre zu schade, wenn sein  
wertvolles Feedback im Mailinglisten-Archiv untergeht.


On 26.07.2008, at 11:26, Torsten Ziegler wrote:

> Hallo Liebes Deepamehta Team
>
> nach meinem ersten Hilferuf an Jörg
> der prompt beantwortet wurde (Danke Jörg und Malte)
> wollte ich euch gerne meine Erfahrungen weitergeben,
> in der Hoffnung die Bugreports helfen euch weiter deepamehta zu
> verbessern.
>
> Ich benutze die deepamehta-2.0b8-rc4
> - Die Standalone Version unter Windows (interne DB) funktioniert
>   einwandfrei.
> - Unter Debian 4 funktioniert die Standalone Version, ebenso wie die
>   Client Server Version einwandfrei mit der internen DB und mit mysql5
>   (mysql4 habe ich nicht getestet)
> - nur mit den Webapps habe ich noch ein paar Probleme, siehe unten
>
> Einen Fehler habe ich im Installer bemerkt und zwar wenn ich als DB
> mysql5 auswähle und sowohl Deepamehta neu installiere, als auch die
> Movies Beispiele, dann wird nur eine der beiden Datenbanken angelegt.
> Ich muss dann ./run.sh install nochmal ausführen und bei der Deepamehta
> DB Nein auswählen, damit die Movies DB erstellt wird.

Oh, dieser Fehler war mir nicht bekannt!

=> Enrico: ich würde mich freuen, wenn Du Dir das Installer-Skript  
nochmal ansehen könntest und diesen Fehler ggf. beheben könntest.

> Auch ist es möglich wenn man die Webapps instaliert  die interne hsqlDB
> auszuwählen, was dann natürlich nicht funktionieren kann, das könnte  
> man
> vielleicht gegenseitig ausschließen im Installer oder im Readme noach
> erwähnen.

Ja, ich verstehe, was Du meinst. Bei der Konzeption des Install-Sktipts  
haben wir das diskutiert, und uns entschlossen, HSQL auch dann  
anzubieten, wenn die Webinterfaces "aktiviert" wurden, aus 2 Gründen:

1) Das vorrangige Ziel des Install-Skripts ist, DeepaMehta so schnell  
und einfach in Betrieb zu nehmen -- und zwar das "eigentliche"  
DeepaMehta (die Webinterfaces sind derzeit eher als "Dreingabe" resp.  
"Proof-of-Concept" zu sehen). Die Integration von HSQL trägt ganz  
wesentlich zur einfachen Installation bei (eine manuelle  
MySQL-Installation ist für Normalanwender eine zu große Hürde). Wir  
haben uns gedacht: wenn der Nutzer beim Installieren "aus Versehen" die  
Webinterfaces aktiviert (weil ihm vielleicht der Unterschied zwischen  
dem grafischen DeepaMehta und den Webinterfaces noch garnicht klar ist)  
soll er trotzdem HSQL auswählen können um das eigentliche DeepaMehta  
möglichst schnell sehen können.

2) Die Webinterfaces funktionieren ja auch mit HSQL. Sie funktionieren  
aber nur, wenn nicht gleichzeitig DeepaMehta (Standalone oder Server)  
läuft. Zumindest kann so auch ohne MySQL schonmal in die Webinterfaces  
"reingeschnuppert" werden (was, zugegeben, etwas langweilig ist, da  
gerade das Zusammenspiel DeepaMehta-Web interessant ist. Siehe TIPP  
ganz am Ende dieser Mail).

Im README haben wir versucht, den Anwender auf den richtigen Weg zu  
führen, indem wir in der Kurzanleitung für die automatische  
Installation geschrieben haben:

>> Wenn Beispielanwendungen oder Webfrontends installiert werden sollen,  
>> führe eine manuelle (Terminal-basierte) Installation durch, die im  
>> anschließenden Abschnitt "Installation" beschrieben ist.

... und dann bei der ausführlichen Anleitung für die manuelle  
Installation im Abschnitt "Schritt 2: Installieren => Datenbank":

>> WICHTIG: Wenn DeepaMehta Webfrontends und die grafische  
>> DeepaMehta-Oberfläche gleichzeitig auf einer Maschine benutzt werden  
>> sollen, muß als Datenbank MySQL benutzt werden.

Jetzt zum nächsten Punkt:

> Für die Webapps braucht es noch ein paar mehr Schreibrechte für die  
> Ordner
> install/client/images install/client/documents install/client/icons
> (eventuell auch noch für mehr ?) das hängt natürlich vom tomcat user ab
> und wer deepamehta installiert hat. Nach der Standradinstallation von
> deepamehta reichen die Berechtigungen jedenfalls noch nicht.

Ja, Du hast recht, das ist ein Fallstrick. Hier muß das Install-Skript  
noch nachgebessert werden.

=> Enrico: ich würde mich freuen, wenn Du das Installskript so  
erweitern kannst, daß automatisch User-Schreibrechte für folgende  
Verzeichnisse gesetzt werden:
	install/client/backgrounds
	install/client/documents
	install/client/icons
	install/client/images
	install/client/webpages

Es ist primär das grafische DeepaMehta, das programmatisch in diesen  
Verzeichnissen Dateien anlegt.

> Das weitere bezieht sich auf Debian 4 (etch) und einen Tomcat 5.5 in  
> der
> Standardversion
> Bei Debian muss (sofern man nicht die policiy entsprechend anpasst) den
> security manager aussschalten unter:
> /etc/default/tomcat5.5: TOMCAT5_SECURITY=no
> ebenfalls dort empfielt es sich den headless modus zu wählen (das hat
> bei mir Probleme mit der xalan lib behoben)
> /etc/default/tomcat5.5:  CATALINA_OPTS="-Djava.awt.headless=true"

Danke für den Security-Hinweis! In der Tat sind für Tomcat-Anwendungen  
unter Debian standardmäßig Dateizugriffe nur innerhalb ihres  
Anwendungsverzeichnis erlaubt. DeepaMehta-Webanwendungen greifen aber  
auf Konfigurationsdateien (und weiteres) der DeepaMehta  
"Mutterinstallation" zu.

Wie das am besten gelöst werden kann, weiß ich noch nicht. Vielleicht  
könnte das DeepaMehta-Deploy-Skript beim Deployen einer Webanwendung  
Tomcats Policy-Datei ergänzen, mit entsprechenden FilePermissions.

=> Über mögliche Lösungen möchte ich gerne mit Entwicklern diskutieren.

> Starten des Tomcats:
> -Die Integrierung der start Routinen in das run.sh script funktioniert
> bei Debian nicht, da die executables unter /usr/share/tomcat5.5 liegen,
> die webapps aber unter /var/lib/tomcat5.5 da müsste man entweder ein
> paar symlinks setzen, oder das Startscript verändern.

Ja, Du hast recht! Da es bei Debian kein gemeinsames "Tomcat-Home" für  
die Excecutables, Webapps, shared DeepaMehta-Libraries und Logfiles  
gibt, funktioniert das DeepaMehta-Install-Skript hier nicht.

Eine "generische" Lösung (die nichts davon wissen muß, auf welcher  
Plattform sie läuft) wäre, das DeepaMehta-Install-Skript so zu  
erweitern, daß es nicht wie bisher nach _dem_ Tomcat-Home fragt,  
sondern getrennt nach den 4 Tomcat-"Hotspots" (Excecutables, Webapps,  
shared Libraries, Logfiles)

=> Auch hier möchte ich gerne mit Entwicklern über mögliche Lösungen  
diskutieren.

> - was funktioniert ist im Ordner install/client den Tomact zu starten
> mit /etc/init.d/tomcat5.5 start
>
> Ich bin ja blutiger Neuling in Bezug auf deepamehta und Java, aber das
> Hauptproblem sieht mir danach aus, dass die Konfigurationsfiles von  
> einem
> fest verdrahteten Verzeichnis gelesen werden. So sieht es jedenfalls in
> http://svn.berlios.de/svnroot/repos/deepamehta/tags/deepamehta-2.0b8- 
> rc4/develop/src/de/deepamehta/Configuration.java
> zusammen mit dem Aufruf in
> http://svn.berlios.de/svnroot/repos/deepamehta/tags/deepamehta-2.0b8- 
> rc4/develop/src/de/deepamehta/service/ApplicationServiceInstance.java
> Da der Arbeitspfad eines Servlets ja unbestimmt ist (er wird nur
> durch das Starten vom tomcat in einem bestimmten Verzeichnis bestimmt,
> was ja durch den workaround auch funktioniert aber auf einer shared  
> hosting
> Umgebung nicht möglich ist) müsste man die Konfiguration besser mit  
> getResource()
> einlesen. Siehe auch die Beschreibung unter:
> http://www.velocityreviews.com/forums/t131134-specifying-path-for- 
> file-to-be-read-by-servlet-with-tomcat.html
> Wie gesagt habe ich nicht wirklich Ahnung, und hoffe Euch durch meine
> Gedanken etwas zu helfen.

Du hast völlig recht. Daß die DeepaMehta-Webanwendungen darauf  
angewiesen sind, daß Tomcat von einem bestimmten Verzeichnis aus  
gestartet werden muß, ist ein "quick-and-dirty-hack" und für  
Produktionsumgebungen völlig unakzeptabel.

Hintergrund: DeepaMehta-Webanwendungen müssen z.B. auf  
Konfigurationsdateien der DeepaMehta "Mutterinstallation" zugreifen (in  
install/config), wissen aber nicht, wo diese liegt. (Die von Dir  
erwähnte ServletContext.getResource()-Methode hilft hier nicht weiter,  
da sie relativ zum ServletContext arbeitet, also nur Resourcen  
_innerhalb_ der Webanwendung adressieren kann.)

Es gibt bereits einen Weg, DeepaMehta-Webanwendungen zu starten, ohne  
auf einen Tomcat-Neustart angewiesen zu sein. Dazu mußt Du allerdings  
im Deployment-Descriptor der Anwendung (WEB-INF/web.xml) mitteilen, wo  
die DeepaMehta-Installation liegt. Das geht mittels des  
Servletcontext-Parameters "home", z.B.:

	<context-param>
		<param-name>home</param-name>
		<param-value>/usr/local/deepamehta</param-value>
	</context-param>

Beachte: der absolute Pfad muß das DeepaMehta-Installationsverzeichnis  
angeben (ab dem dann install/config liegt), _ohne_ Slash am Ende.

=> Auch hier möchte ich gerne mit Entwicklern über mögliche Lösungen  
diskutieren.

> Test der Webapplikationen (bezieht sich alles auf eine neue  
> Installation
> ohne Änderung, tomcat gestartet von install/client aus)
>
> 1. dm-web
> scheint zu funktionieren, nur die
> url der icons sind local (file://..)und nicht http://... und können
> deshalb nicht angezeigt werden

Hierfür gibt es eine Lösung: Du kannst in DeepaMehta die Base-URL  
einstellen, zu der relative Pfade (z.B. zu Bild-Dateien, die im  
Propertypanel oder auch in den Webanwendungen) aufgelöst werden. Gehe  
dazu in DeepaMehta in den "Administration" Workspace, klicke den  
"CorporateWeb Settings" Topic an, und gebe als "Base URL" z.B. ein:

	http://www.mysite.de/deepamehta/install/client/

Du mußt also das client-Verzeichnis angeben (_mit_ Slash am Ende). In  
diesem findet dann z.B. die "dm-web" Anwendung das "icons" Verzeichnis.

Während der DeepaMehta-Installation wird als "Base URL" standardmäßig  
eine file: URL eingetragen, was funktioniert, solange DeepaMehta Client  
und Server resp. Webanwendungen auf der gleichen Maschine laufen.

> 2. dm-browser
> funktioniert teilweise,
> a) wenn ich etwas editiere (Stift icon) und auf OK klicke kommt:
>
> de.deepamehta.DeepaMehtaException: no PARAM_SEPARATOR "_" found in  
> "typeID"
> 	 
> de.deepamehta.service.web.DeepaMehtaServlet.getWeakRelationParameters(D 
> eepaMehtaServlet.java:857)
>
> aber die Änderung wird gespeichert.
> b) ebenso beim löschen (Papierkorb Icon) kommt die Fehlermeldung
>
> de.deepamehta.DeepaMehtaException: topic "t-1001" is missing in  
> corporate memory
> 	 
> de.deepamehta.service.ApplicationService.checkLiveTopic(ApplicationServ 
> ice.java:350)
>
> aber es wurde erfolgreich gelöscht
> c) alle topicmap icons sind wieder local (file://....) und können
> deshalb nicht angezeigt werden
>
> 3. dm-topicmapviewer
> funktioniert teilweise, fast alle topicmaps sind aufrufbar,
> a) die topicmaps werden korrekt gerendert, aber sind wieder local
> (file://....) und können deshalb nicht angezeigt werden,
> darum kann ich nicht sagen, ob die picture map funktioniert
> b) als einizge gibt es bei der Users and Groups (t-workgroupmap) eine
> Exception
>
> org.apache.jasper.JasperException
> 	 
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServl 
> etWrapper.java:512)
>
> java.lang.NullPointerException
> 	 
> de.deepamehta.service.RelationalCorporateMemory.createPreparedStatement 
> (RelationalCorporateMemory.java:1935)
>
> 4. dm-search
> funktioniert teilweise,
> a) wieder locale Icons
> b) wenn ich auf einen user Zugreife kommt die Exception
>
> org.apache.jasper.JasperException
> 	 
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServl 
> etWrapper.java:512)
>
> java.lang.NullPointerException
> 	 
> de.deepamehta.service.RelationalCorporateMemory.createPreparedStatement 
> (RelationalCorporateMemory.java:1935)
> 	 
> de.deepamehta.service.RelationalCorporateMemory.queryBaseTopics(Relatio 
> nalCorporateMemory.java:1522)
>
>
> 5. messageboard
> funktioniert vollständig
>
> 6. kompetenzstern
> funktioniert gar nicht, beim Aufruf kommt die Exception
>
> javax.servlet.ServletException: Servlet.init() for servlet  
> Kompetenzstern Servlet threw exception
> 	 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.jav 
> a:105)
>
> java.lang.NullPointerException
> 	 
> de.deepamehta.service.ApplicationServiceInstance.<init>(ApplicationServ 
> iceInstance.java:66)
> 	 
> de.deepamehta.service.ApplicationServiceInstance.lookup(ApplicationServ 
> iceInstance.java:117)
> 	 
> de.deepamehta.service.web.DeepaMehtaServlet.init(DeepaMehtaServlet.java 
> :108)
> 	javax.servlet.GenericServlet.init(GenericServlet.java:211)
>
>
>
> Danke für Eure Arbeit und
> Liebe Grüße,
> Torsten


Auf die anderen Webanwendungen kann ich gerne später eingehen. Der  
obige "Base URL" Tipp wird auch bei manchen der anderen Webanwendungen  
das Icon-Problem lösen.

Zur Zeit ist die Webanwendungen "dm-web" am nützlichsten. Die anderen  
sind eher proof-of-concepts von bestimmten DeepaMehta-Funktionen.  
"dm-web" ist das derzeit am besten ausgebaute generische Web-Frontend  
zum Anzeigen/Suchen/Navigieren/Anlegen/Ändern von Corporate Memory  
Inhalten. Was "dm-web" weiterhin eindrucksvoll demonstriert, sind die  
dynamischen Formular- und Informations-Generatoren, die auf den  
DeepaMehta-Typdefinitionen operieren. Wenn z.B. in DeepaMehta eine neue  
Property angelegt wird, erscheint diese sofort nach einem  
Webbrowser-Reload auch im HTML-Formular oder auf einer  
Topic-Info-HTML-Seite. TIPP: Damit diese Typdef-Synchronisation  
zwischen grafischen DeepaMehta und Webanwendungen funktioniert, muß der  
DeepaMehta-Server laufen, d.h. das grafische DeepaMehta im  
Client/Server-Modus benutzt werden. Dann nämlich kommunizieren Tomcat  
und DeepaMehta über einen Socket (mit dem Monolithen geht das nicht, da  
sind keine Sockets in Benutzung).

Torsten, ich danke Dir sehr für Deinen ausführlichen Report. Alle von  
Dir erwähnten Punkte sind von großer Relevanz. Du hast auch alle Punkte  
sehr gut beschrieben. Ich sehe, daß Du eine Menge Zeit investiert hast.  
Danke!

Mit der Hoffnung Dich trotz aller DeepaMehta-Unzulänglichkeiten als  
Anwender zu behalten:

Liebe Grüße
Jörg