It is currently available on jamba and T-Online.

Published by: EFUSION-X LTD
Developed by: Michael Flad and Thomas Praxl
Graphics: Thomas Kronenberg and Fabian Jastremski
Music: Jesse Hopkins

We first thought it was a problem related to serialization / deserialization and debugged the concerned parts of the code. Then we found out that the type of the object in the session changed between some lines of code (without an explicit new assignment), not between HTTP-Requests.
His session object was assigned to $_SESSION["oProject"] and there was an assignment to a totally different object $oProject in the code before reading $_SESSION["oProject"].
Well.. I would have thought no serious provider turns on register_globals, well.. surprise surprise, 1&1 does that at the time of this writing.
You cannot simply do this:

//doesn't work!! You cannot set register_globals off while a script is running.
ini_set("register_global",0);

As recommended by php.net, you could add the following code to your .htaccess file:

php_flag register_globals on

This isn’t allowed by 1&1 though, but 1&1 recommends the following workaround, which may only work with 1&1:
Create a php.ini file and put it into the directory, you want it to apply for. The file may contain only the following line:

register_globals = off

If that wouldn’t work for you, you could as well make sure that your $_SESSION-indices are unique and don’t collide with local variables, but it’s not only the $_SESSION that is affected by register_globals, it’s $_GET and $_POST and so on. This can be highly dangerous, as it can inject values into your code, thus change the behaviour of your code.

Here’s a simple solution for those of you who are not allowed to change register_globals (I didn’t test it though and the other solutions on the page linked above might work even better).

public class App
{
    public static void main( String[] args )
    {
        BasicConfigurator.configure();
        try {
            String xml = "repository/configuration.xml";
            String dir = "repository";
            RepositoryConfig config = RepositoryConfig.create(xml, dir);
            Repository repository = RepositoryImpl.create(config);
            try {
                Thread.sleep(10000);
            } catch (InterruptedException ex) {
                Logger.getLogger(App.class.getName()).log(Level.SEVERE, null, ex);
            }
            ((RepositoryImpl) repository).shutdown();
        }catch (ConfigurationException ex) {
            Logger.getLogger(App.class.getName()).log(Level.SEVERE, null, ex);
        } catch (RepositoryException ex) {
            Logger.getLogger(App.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

The Repository configuration:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Repository
          PUBLIC "-//The Apache Software Foundation//DTD Jackrabbit 2.0//EN"
          "http://jackrabbit.apache.org/dtd/repository-2.0.dtd">
<Repository>
	<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem" >
		<param name="path" value="${rep.home}/repository" />
	</FileSystem>
	<Security appName="jackrabbit-nodez-poc" >
		<LoginManager class="org.apache.jackrabbit.core.security.SimpleAccessManager" />
		<LoginModule class="org.apache.jackrabbit.core.security.SimpleLoginModule" />
	</Security>
	<Workspaces rootPath="${rep.home}/workspaces" defaultWorkspace="default" />
	<Workspace name="${wsp.name}">
		<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem" >
			<param name="path" value="${wsp.home}" />
		</FileSystem>
		<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager"/>
	</Workspace>
	<Versioning rootPath="${rep.home}/version">
		<FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem" >
			<param name="path" value="${rep.home}/version" />
		</FileSystem>
		<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.BundleFsPersistenceManager"/>
	</Versioning>
</Repository>

It turned out that an NPE was thrown when I tried to shut down the Repository:

20223 [main] INFO org.apache.jackrabbit.core.RepositoryImpl  - Shutting down repository...
20224 [main] INFO org.apache.jackrabbit.core.RepositoryImpl  - shutting down workspace 'default'...
20224 [main] INFO org.apache.jackrabbit.core.observation.ObservationDispatcher  - Notification of EventListeners stopped.
Exception in thread "main" java.lang.NullPointerException: dispatcher
        at org.apache.jackrabbit.core.observation.ObservationManagerImpl.<init>(ObservationManagerImpl.java:97)
        at org.apache.jackrabbit.core.WorkspaceImpl.getObservationManager(WorkspaceImpl.java:748)
        at org.apache.jackrabbit.core.SessionImpl.removeRegisteredEventListeners(SessionImpl.java:1189)
        at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1217)
        at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doDispose(RepositoryImpl.java:2183)
        at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.dispose(RepositoryImpl.java:2138)
        at org.apache.jackrabbit.core.RepositoryImpl.doShutdown(RepositoryImpl.java:1175)
        at org.apache.jackrabbit.core.RepositoryImpl.shutdown(RepositoryImpl.java:1127)
        at ...

Solution

Make sure to login.
Yes. It’s that simple, just add

1

Session session = repository.login();

before you shut it down.
Note: It seems to be a better practice to shutdown using a RepositoryImpl you retreived from this Session as well:

1

 ((RepositoryImpl)session.getRepository()).shutdown();

The resulting “Hello Repository” code would look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

//use this to get a quick configuration for log4j output
BasicConfigurator.configure();
        try {
            String xml = "repository/configuration.xml";
            String dir = "repository";
            RepositoryConfig config = RepositoryConfig.create(xml, dir);
            Repository repository = RepositoryImpl.create(config);
            Session session = repository.login();
            try {
                Thread.sleep(10000);
            } catch (InterruptedException ex) {
                Logger.getLogger(App.class.getName()).log(Level.SEVERE, null, ex);
            }
            ((RepositoryImpl)session.getRepository()).shutdown();
        }catch (ConfigurationException ex) {
            Logger.getLogger(App.class.getName()).log(Level.SEVERE, null, ex);
        } catch (RepositoryException ex) {
            Logger.getLogger(App.class.getName()).log(Level.SEVERE, null, ex);
        }

String xulHome = new File("lib/xulrunner").getAbsolutePath();
NSSystemPropertySWT.WEBBROWSER_XULRUNNER_HOME.set(xulHome);
System.setProperty("org.eclipse.swt.browser.XULRunnerPath", xulHome);

This code needs to have the following directory-structure:

• yourapp.jar
• lib (directory)
  • xulrunner (directory)
    • xulrunner-files (e.g. xpcom.dll)

A complete example on how to set up a frame with a browser can be found in the example source code of DJ Native Swing.

First of all, I worked with utf-8 files without BOM.

In order to find possible searchwords, some regular expressions have been used.

The indexed words were supposed to be stored in lower case.

These are the suggestions, if you have a similar task:

There was no problem with reading the files using get_file_contents or writing the index file using file_put_contents. (as all of my files, even the php-sources were encoded in utf-8).

Make sure to use preg_split or preg_replace with the ‘/u’ option, for example preg_split(”/\b/u”, $haystack). This tells php to use utf-8. (see php.net – pcre pattern modifiers for more information). Make sure to use the lowercase ‘u’.

Using mb_split instead of preg_split didn’t work for me, as the results differed from my expectation. I didn’t go deeper into it though.

To convert utf-8 strings to lowercase, don’t use strtolower, but use mb_convert_case($word,MB_CASE_LOWER,”UTF-8″); instead.

That’s it. If you have any further tips related to this topic, I’d appreciate your comment.

Das Problem war, dass anfangs kein Geschäftszeichen für einen Klienten eingegeben wurde. Offenbar hat der Benutzer von BdB at Work in der Zwischenzeit aber versucht, das Geschäftszeichen einzutragen.
Es gab zu diesem Zeitpunkt bereits eine Reihe von Statusänderungen im Verlauf und diverse Dokumente / Schriftwechsel.

BdB at Work wird bei jeder Änderung des Geschäftszeichens versuchen, einen Ordner im Verzeichnis {bdbinstall}/Texte anzulegen, der einer bestimmten Nomenklatur folgt. Der Ordnername enthält die Geschäftsnummer des Klienten. Ist ein solcher Ordner bereits vorhanden, verweigert BdB at Work die Änderung der Geschäftsnummer. BdB at Work löscht einmal angelegte Verzeichnisse nach meiner Erfahrung auch dann nicht, wenn die alte Geschäftsnummer im System nicht mehr vorhanden ist.

Um die Geschäftsnummer zu ändern, habe ich zunächst eine Sicherung des Systems angelegt (Schließen von BdB at Work und Sicherung bestätigen).
Dann habe ich im Ordner Texte der BdB Installation nachgesehen, welche Ordner bereits für diesen Klienten angelegt waren. Die darin enthaltenen Dokumente habe ich verglichen mit den aufgeführten Dokumenten im Bereich Dokumentenverwaltung->Ordner und Scanfunktion.
So konnte ich den Ordner ermitteln, der aktuell für den Klienten verwendet wird. In diesem Fall waren die Dokumente des Klienten über mehrere Ordner verteilt, im System waren jedoch nur die Dokumente verwaltet, die der – nicht vergebenen – Geschäftsnummer entsprachen, also die Dokumente des Ordners “{klientenname}[]“.
Ich habe zunächst im Bereich Dokumentenverwaltung->Ordner und Scanfunktion die alten Dokumente importiert (rechte Maustaste auf das Feld mit der Dokumentenliste -> Dokumente importieren…)
Hierbei kam es zu Fehlern, es hat geholfen, immer nur wenige Dokumente auf einmal zu importieren.
Als alle Dokumente in der Ordner- und Scanfunktion aufgelistet waren, habe ich die verbleibenden Ordner des Klienten (die alten Ordner) gelöscht (bzw. in ein eigenes Backupverzeichnis verschoben).

Danach habe ich die Verlaufsdaten bearbeitet. Hierfür habe ich mir zunächst jeden Eintrag im Verlauf abgeschrieben und alle – bis auf den Beginn der Betreuung gelöscht. (Rechte Maustaste -> löschen).
Nun habe ich die Geschäftsnummer bei Beginn der Betreuung geändert. Da der alte Ordner mit der entsprechenden Geschäftsnummer gelöscht war, war dies erfolgreich.
Dann habe ich alle Verlaufseinträge wieder eingestellt, wobei die Geschäftsnummer von BdB at Work übernommen wurde.
Das Löschen ist deswegen erforderlich gewesen, weil bei einer Änderung der Geschäftsnummer in einem früheren Eintrag des Verlaufs nicht automatisch die Geschäftsnummern späterer Eintragungen geändert werden. Versucht man dann aber die Geschäftsnummer einer späteren Eintragung zu ändern, wird BdB at Work erneut versuchen, den Ordner mit dieser Geschäftsnummer anzulegen und dabei scheitern und somit die Änderung der Geschäftsnummer für spätere Ereignisse verweigern.

Die Lösung:

Variante a)

Microsoft Word verwenden

Variante b)

Das Häkchen bei Ausdruck mit Textverarbeitung wegnehmen.

Trotzdem kann es passieren, dass die Datumsspalte für die abrechnungsrelevanten Veränderungen zu schmal gerät. In diesem Fall klicken Sie mit der rechten Maustaste auf den Text Pauschalabrechnung unten links neben den Symbolen für Druckvorschau und Drucken. Dort wählen Sie “Mit Berichtsgenerator öffnen”->”Pauschalabrechnung”.

Wenn sich der Berichtsgenerator geöffnet hat, suchen Sie das Feld “HTMLtoTXT(crsevents.tdatum)” und klicken es mit der linken Maustaste an.

Mit Hilfe der jetzt sichtbaren “Greifer”-Rechtecke, die das Feld umranden, können Sie die Größe des Felds verändern. Es reicht in der Regel, den Greifer rechts in der Mitte zu nehmen und nur ein Stückchen nach rechts zu ziehen, so dass es direkt an das nächste Feld angrenzt.

Schließen Sie den Berichtsgenerator mit dem normalen Schließen-Knopf des Fensters (oben rechts, rot) und speichern Sie auf Anfrage.

Verwenden Sie die Druckvorschau, um zu überprüfen, ob Sie Erfolg hatten. Bedenken Sie, dass jeder tatsächliche Druck direkt zu einer Verbuchung führt.

Ist beim Ausdruck etwas schief gegangen, stornieren Sie den Vergütungsantrag wie folgt:

Öffnen Sie den Verlauf, entfernen Sie das Häkchen für “stornierte Vergütungsabrechnungen ausblenden”, klicken Sie mit der rechten Maustaste auf die stornierte Vergütungsabrechnung und wählen Sie “Löschen”. Dadurch wird die Rechnungsnummer wieder für das System freigegeben.

Select the path, using the path selection tool, then select the raster layer, using your layers-tab (this is the most important step. Having no raster layer selected, the stroke-option will be inactive). Following that, there are several options. You may right click the selected path on your canvas and select stroke subpaths.

Another option would be to first create a workpath, then select the raster layer, switch to the paths-tab and right click on your workpath. The option “stroke path” will be available at that time.