Spannend ist vor allem, dass es Evernote für Windows, Mac sowie für Windows Mobile und das iPhone gibt. Synchronisiert wird über den Webdienst von Evernote bei dem es for free ein monatliches Uploadvolumen von 40MB gibt. Wer mehr will, kann für 45 Dollar im Jahr zum Premium Account upgraden. Einen webbasierten Zugang zu seinen Notizen hat man über die Website von Evernote.

Auch interessant ist die Integration in den Webbrowser, die es erlaubt, einen (markierten) Abschnitt einer Webseite oder auch die gesamte Seite als Notiz zu speichern. Auch Screenschots lassen sich direkt in Evernote speichern.

Alles in allem das perfekte Tool für wirre Köpfe mit vielen Ideen…

URL: http://www.evernote.com

ScribeFire ist eine Firefox Extension, die bloggen direkt aus dem Browser unterstützt. Kein lästiges Wordpress-Backend mehr? Na mal sehen, was dieser nächste Versuch des Desktop Bloggings so bringt…

EDIT: Ja, das scheint hervorragend zu funktionieren, endlich mal!

EDIT 2: Und nun noch mit Bild - Jaaah, super!

Wer schon mal schnuppern möchte, was auf ihn zukommt, kann das mit der von MS veröffentlichten Beta 1 tun.

Ein erster Blick zeigt: So ganz reibungslos wird es nicht gehen. Vor allem beim Rendern von Paddings und Margins gibt es offensichtlich einige Abweichungen (ist man ja gewöhnt).

Also Frontendler dieser Welt: Rüstet Euch schon mal für die IE8-Fix Welle!

ERROR [proxy.pojo.BasicLazyInitializer] Javassist Enhancement failed:
org.alfresco.repo.avm.PlainDirectoryNodeImpl
java.lang.RuntimeException: by java.lang.IllegalAccessError:
class org.hibernate.proxy.HibernateProxy_$$_javassist_110 cannot access its
superinterface org.alfresco.repo.avm.PlainDirectoryNode
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:342)In der Datei server/default/deploy/ejb3.deployer/META-INF/persistence.properties ist der Hibernate Bytecode Provider von “javassist” auf cglib zu ändern:

#hibernate.bytecode.provider=javassist
hibernate.bytecode.provider=cglibWarum das so ist weiß der Geier. Und der hier, der weiß das offensichtlich auch. Danke!

Bin ja gespannt…

Hierzu gibt es, als undokumentiertes Feature, einen Hook:

1. localconf der eigenen Extension anpassen:

if (t3lib_extMgm::isLoaded('newloginbox') && (TYPO3_MODE == 'FE')) {
$GLOBALS ['TYPO3_CONF_VARS']['EXTCONF']['newloginbox']['loginFormOnSubmitFuncs'][] =
‘tx_myextension_newloginbox->loginFormOnSubmit’;
require_once(t3lib_extMgm::extPath(’my_extension’).’class.tx_myextension_newloginbox.php’);
}
2. class.tx_myextension_newloginbox.php schreiben

class tx_eccgeneral_newloginbox {
function loginFormOnSubmit(){
$onSubmit = '';
$hidden = "";
if(t3lib_div::GPVar("msg_uid")) {
$hidden .= '<input type="hidden" name="msg_uid" value="'.t3lib_div::GPVar("msg_uid").'">';
}
if(t3lib_div::GPVar("action")) {
$hidden .= '<input type="hidden" name="action" value="'.t3lib_div::GPVar("action").'">';
}
return array($onSubmit, $hidden);
}
}


Warning: Invalid argument supplied for foreach() in
/srv/www/blabla/typo3/class.db_list.inc on line 685

… der Solte in seiner ext_localconf.php folgende Einstellung vornehmen:

$GLOBALS['TYPO3_DB']->debugOutput = true;

Nun gibts auch aussagekräftige Fehlermeldungen.

Der Ordnung halber sollte das beim Livegang aber wieder deaktiviert werden.

Ein Klick auf home/service/imprint für damit zu home/service. Und das auch nur weil ‘postVarSet_failureMode’ => ‘redirect_goodUpperDir’ aktiviert wa, ansonsten hätte es eine häßliche Fehlermeldung gegeben. Mein Verdacht war immer, dass es was mit dem RealURL cache zutunhaben muss, den nach löschen des frontend caches und das Neuerzeugen des Links auf home/service/imprint durch Reload der Seite home/service ging es immer.

Nach einigem Googeln stellte ich fest, dass viele mit diesem Problem zu kämpfen haben und es eine Konfigurationsmöglichkeit gibt, die deses Problem behebt:

'pagePath' => array (
...
'firstHitPathCache' => true
)

Was das genau macht, weiss ich nicht, aber es hilft!

#content-section code br {
display: none;
}…hätt ich ja nicht gedacht, dass das geht…

Dem scp-Task ist das Attribut sftp=”yes” hinzuzufügen, dann wird über SFTP gesendet und alles ist gut.

Eclipse muss hierzu jedoch auf 3.3 upgegradet werden wg. neuer ANT-Version.

Wer’s genau wissen will: http://jira.jboss.com/jira/browse/JBPORTAL

Weiß irgendjemand warum dieses Statement:

SELECT distinct a.id, a.name
FROM ums_gesamtbenutzerrechte c, wfl_aktion a
LEFT JOIN wfl_status ON a.to_id=wfl_status.id
WHERE a.from_id=32 and a.recht_id=c.rechteid and c.benutzerid=2
AND wfl_status.prozess_id=6funktioniert, und dieses hier

SELECT distinct a.id, a.name
FROM wfl_aktion a,ums_gesamtbenutzerrechte c
LEFT JOIN wfl_status ON a.to_id=wfl_status.id
WHERE a.from_id=32 and a.recht_id=c.rechteid and c.benutzerid=2
AND wfl_status.prozess_id=6nicht?

Häh?

Das HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Insert title here</title>
<link rel="stylesheet" href="default.css" type="text/css">
</head>
<body>
<div id="positioner">
<div id="outer-container">
<div id="inner-container">
<div id="left">
<p>left</p>
</div>
<div id="right">
<p>right</p>
</div>
<div id="middle">
<p>middle</p>
</div>
<div class="clear"></div>
</div>
</div>
<!-- wichtig für IE 6 -->
</div>
</body>
</html>
Und das CSS:

* {
margin: 0px;
padding: 0px;
}
body {
text-align: center;
}
.clear {
clear: both;
}
#positioner {
width: 65em;
margin: 0px auto;
text-align: left;
}
#outer-container {
border-left: 10em solid #a0a0ff;
border-right: 10em solid #ffa0a0;
background-color: #e0e0e0;
}
#inner-container {
margin-left: -10em;
margin-right: -10em;
}
#left {
width: 10em;
float: left;
}
#middle {
float: left;
width: 45em;
}
#right {
width: 10em;
float: right;
}


When I try to combine both features, disable emailconfirmation (setfixed = false) and autologin after creating an account, I experience two strange behaviors:

• - The Template “a mail has been send … toconfirm” is shown after creation, even though he setfixed-feature is disabled
• Autologin doesn’t happen

after some debugging effort I supposably found a bug.

I used the following constants in template:

plugin.tx_srfeuserregister_pi1.enableEmailOnApprove = 0
plugin.tx_srfeuserregister_pi1.useMd5Password = 0
plugin.tx_srfeuserregister_pi1.enableAutoLoginOnCreate = 1
plugin.tx_srfeuserregister_pi1.userGroupAfterConfirmation = 4
plugin.tx_srfeuserregister_pi1.formFields =
username, password, gender, first_name, last_name, email,
address, zip, city, static_info_country
plugin.tx_srfeuserregister_pi1.enableEmailConfirmation = 0
plugin.tx_srfeuserregister_pi1.pid = 264
plugin.tx_srfeuserregister_pi1.userGroupAfterAcceptation = 4
plugin.tx_srfeuserregister_pi1.userGroupUponRegistration = 4
plugin.tx_srfeuserregister_pi1.enableAutoLoginOnConfirmation = 0
plugin.tx_srfeuserregister_pi1.loginPID = 229
plugin.tx_srfeuserregister_pi1.defaultCODE = CREATE
plugin.tx_srfeuserregister_pi1.file.templateFile =
fileadmin/templates/tx_srfeuserregister_pi1_css_tmpl.html
SOLUTION:

class: tx_srfeuserregister_pi1
funtion: init()

the lines

if (isset($this->conf['setfixed'])) {
$this->setfixedEnabled = $this->conf['setfixed'];
}
have to be located BEFORE the call

$this->control->init(
$this, $this->conf, $this->config, $this->display,
$this->data, $this->marker, $this->auth, $this->email, $this->tca);
…because the init function of tx_srfeuserregister_control references the pibase-member setfixedEnabled. Otherwise the setfixedEnabled used by the control class will always be true even though setfixed is set to false (enableEmailConfirmation = 0)

——————————–
SOLUTION
——————————–

CLASS: tx_srfeuserregister_pi1

function init(&$conf) {
global $TSFE, $TCA, $TYPO3_CONF_VARS;
// plugin initialization
$this->conf = $conf;
if (t3lib_extMgm::isLoaded('sr_freecap') ) {
require_once(t3lib_extMgm::extPath('sr_freecap').'pi2/class.tx_srfreecap_pi2.php');
$this->freeCap = t3lib_div::makeInstance('tx_srfreecap_pi2');
}
$this->lang = t3lib_div::makeInstance('tx_srfeuserregister_lang');
$this->data = t3lib_div::makeInstance('tx_srfeuserregister_data');
$this->auth = t3lib_div::makeInstance('tx_srfeuserregister_auth');
$this->marker = t3lib_div::makeInstance('tx_srfeuserregister_marker');
$this->tca = t3lib_div::makeInstance('tx_srfeuserregister_tca');
$this->display = t3lib_div::makeInstance('tx_srfeuserregister_display');
$this->email = t3lib_div::makeInstance('tx_srfeuserregister_email');
$this->control = t3lib_div::makeInstance('tx_srfeuserregister_control');
// BUGFIX Oliver Meimberg
// ADD THIS HERE
if (isset($this->conf['setfixed'])) {
$this->setfixedEnabled = $this->conf['setfixed'];
}
$this->lang->init($this, $this->conf, $this->config);
$this->lang->pi_loadLL();
$this->data->init($this, $this->conf, $this->config,
$this->lang, $this->tca, $this->auth, $this->control, $this->freeCap);
$this->control->init($this, $this->conf, $this->config, $this->display,
$this->data, $this->marker, $this->auth, $this->email, $this->tca);
$this->pi_USER_INT_obj = 1;
$this->pi_setPiVarDefaults();
$this->sys_language_content =
t3lib_div::testInt($TSFE->config['config']['sys_language_uid']) ?
intval($TSFE->config['config']['sys_language_uid']) : 0;
// prepare for character set settings
if ($TSFE->metaCharset) {
$this->charset = $TSFE->csConvObj->parse_charset($TSFE->metaCharset);
}
// Initialise fileFunc object
$this->fileFunc = t3lib_div::makeInstance(’t3lib_basicFileFunctions’);
// BUGFIX Oliver Meimberg
// REMOVE THIS
// if (isset($this->conf['setfixed'])) {
// $this->setfixedEnabled = $this->conf['setfixed'];
// }
[...]
}


Nun gibt’s Abhilfe: Im TYPO3- Extension Repositiory gibt es eine neue Version (1.4.4) der Extension rtehtmlarea, die dieses Problem behebt. Hurra!

Nummer gewählt, etwas Wartezeit…

• Sprachcomputer: Willkommen bei 1&1, wussten Sie schon … blabla, blubber sülz … unsere Produkte … blubber, blabla … Bitte nennen Sie mir nun Ihre Kunden- oder Vertragsnummer.
• Ich: K123456
• Sprachcomputer: Ich habe Sie leider nicht verstanden. Bitte nennen Sie mir Ihre Kunden- oder Vertragsnummer.
• Ich: K123456
• Sprachcomputer: Ich habe Sie leider nicht verstanden. Bitte nennen Sie mir Ihre Kunden- oder Vertragsnummer.
• Ich: K123456
• Sprachcomputer: Ihre Kundennummer ist: K123456. Ist das richtig?
• Ich: Ja
• Sprachcomputer: Ich habe Sie leider nicht verstanden. Ihre Kundennummer ist: K123456. Ist das richtig?
• Ich: Ja

… usw. … Irgendwann hat er es verstanden. Dann:

• Sprachcomputer: Bitte sagen Sie mir nun, ob sie Fragen zu Ihren Vertrag oder Fragen zur Technik haben.
• Ich: Vertrag
• Sprachcomputer: Ich habe Sie leider nicht verstanden. Bitte sagen Sie mir nun, ob sie Fragen zu Ihren Vertrag oder Fragen zur Technik haben.
• Ich: Vertrag
• Sprachcomputer: Okay, Technik.

HMPF!

• Sprachcomputer: Ich stelle Sie nun durch zu unserem technischen Support.

… etwas Wartezeit…

• Sprachcomputer: Willkommen beim technischen Support von 1&1 … blabla … Bitte halten Sie Ihre Kunden- oder Vertragsnummer bereit (!!!)

… etwas Wartezeit…

• Mitarbeiter: Willkommen beim technischen Support, was kann ich für Sie tun?
• Ich: Ich wollte eigentlich zur Vertragshotline, aber Ihr Sprachcomputer hat mich wohl nicht verstanden…
• Mitarbeiter: Kein Problem, ich stell Sie durch. Nennen Sie mir doch bitte mal Ihre Kundennummer.
• Ich: Die habe ich doch schon Ihrem Sprachcomputer mitgeteilt. Wird die nicht übertragen?
• Mitarbeiter: Nicht immer. (häh?)
• Ich: K123456
• Mitarbeiter: Okay, ich stell Sie nun durch.

… etwas Wartezeit…

• Sprachcomputer: Willkommen beim technischen Support von 1&1 … blabla … Bitte halten Sie Ihre Kunden- oder Vertragsnummer bereit (!!!)

Ich habe dann aufgelegt.

java.lang.UnsatisfiedLinkError: no Win32NetBIOS in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at [...]

Die Lösung: Das Bundle installieren und aus dem bin-Verzeichnis die Datei Win32NetBIOS.dll holen. Diese ins Verzeichnis ${jboss.home}/bin kopieren.

More than one root node in index: 2…deployment failed.

Die Ursache war einfach: wenn Die Alfresco-Datenbank gelöscht wird, MUSS auch das Verzeichnis alf_data geleert werden.

Über das Kommano

/usr/sbin/sshd -D -p8022 -dwird ein zweiter SSH-Deamon im Debugmodus gestartet (natürlich auf einem anderen Port, hier 8022).

Wird nun ein SSH-Connect auf den Server (natürlich über diesen alternativ-Port) durchgeführt, so teil dieser einem alle seine Sorgen direkt über die Console mit. Beispiel:

getnameinfo failed
Server listening on :: port 8022.
debug1: Bind to port 8022 on 0.0.0.0.
Bind to port 8022 on 0.0.0.0 failed: Address already in use.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 111.222.111.222 port 4810
debug1: Client protocol version 2.0; client software version JSCH-0.1.32
debug1: no match: JSCH-0.1.32
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_4.1
debug1: permanently_set_uid: 71/65
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server 3des-cbc hmac-md5 none
debug1: kex: server->client 3des-cbc hmac-md5 none
debug1: expecting SSH2_MSG_KEXDH_INIT
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user jboss service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "jboss"
Failed none for jboss from 111.222.111.222 port 4810 ssh2
debug1: PAM: setting PAM_RHOST to "p57a0dc1b.dip.t-dialin.net"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user jboss service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: temporarily_use_uid: 1002/1000 (e=0/0)
debug1: trying public key file /data/jboss/.ssh/authorized_keys
Authentication refused: bad ownership or modes for file
/data/jboss/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1002/1000 (e=0/0)
debug1: trying public key file /data/jboss/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for jboss from 111.222.111.222 port 4810 ssh2
Received disconnect from 111.222.111.222: 3: com.jcraft.jsch.JSchException: Auth fail
debug1: do_cleanup
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanupNach dem ersten Connection-Versuch wird der Prozess automatisch wieder beendet.

Hieraus ist z.B. zu lesen, dass die Berechtigungen für authorized_keys nicht korrekt sind. Na da wär ich doch sonst niemals drauf gerkommen…

Nun möchte man aber dennoch gerne Automatisches Deployment auf diese Server mittels SCP-Task über ANT realisieren.

Dies ist möglich über RSA-Keys. Da ich immer wieder vergesse, was man da nun genau machen muss, hier nun ein Kochrezept:

1. Per SSH mit dem User, der auch der Deploy-User wird, auf das Zielsystem einloggen
2. Im Home-Verzeichnis das Verzeichnis .ssh anlegen
   > md .ssh
3. Den SSH-Keygenerator starten
   > ssh-keygen -t rsa -f ./.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
4. Ein Passwort (Passphrase) eingeben:
   Enter same passphrase again:
5. Nochmal:
   Your identification has been saved in ./.ssh/id_rsa.
Your public key has been saved in ./.ssh/id_rsa.pub.
The key fingerprint is:
0a:c2:a5:bc:90:fb:5d:37:2c:95:21:54:6f:0b:86:38 jboss@blablablaNun sind zwei Dateien entstanden:

   ls -la .ssh/
-rw------- 1 jboss jboss 1743 2007-03-08 11:51 id_rsa
-rw-r--r-- 1 jboss jboss 398 2007-03-08 11:51 id_rsa.pub

6. Dem Verzeichnis .ssh die Rechte für others nehmen:
   > chmod 750 .ssh
7. Die Datei id_rsa wird auf den lokalen Rechner kopiert
8. Die Datei id_rsa.pub wird umbenannt zu authorized_keys
   > cd .ssh
> mv id_rsa.pub authorized_keys
9. So, nun kann der SCP-Task entsprechend gestartet werden:
   <scp
port="${scp.port}"
trust="yes"
remoteTodir="${scp.user}:${scp.pass}@${scp.host}:${scp.dir}"
verbose="yes"
passphrase="${scp.pass}"
keyfile="${scp.keyfile}">
<fileset dir="jboss" includes="**/*" />
</scp>…wobei ${scp.keyfile} der Pfad zu der lokalen Datei id_rsa und ${scp.pass} die eingegebene Passphrase ist.

Alles gut!

Data truncation: Data too long for column 'MODIFIABLE' at row 1

Wobei das Feld MODIFIABLE vom Typ bit ist und hier der Wert ‘1‘ eingefügt werden soll.

Die Lösung ist simpel: Es handelt sich um einen Bug im MySQL JDBC-Treiber Version 5.0.3. Also: Upgrade auf z.B. 5.0.4 und gut is.

So, jetzt kommt die Herausforderung: Integration von Alfresco 2.0 in JBoss AS 4.0.5 unter Portal 2.4.1 und MySQL. Zunächst also mal in den Alfresco-Foren gestöbert. Die schlechte Nachricht: Es geht nicht. Die gute Nachricht: Es geht doch, wenn man sich etwas Mühe gibt. Die Kernaussage dieses Wiki-Eintrages ist, dass im aktuellen Release einige Issues existieren, die den Betrieb von Alfresco 2.0 unter JBoss Portal 2.4.1 unmöglich machen. Diese Issues sin in aktuellen Revisionen des SVN-Repositories jedoch bereits gefixt, so dass ein manuelles Build eines SVN-Snapshots nötig ist. Es gibt glücklicherweise eine Wiki-Eintrag, der beschreibt, wie das zu bewerkstelligen ist. Na dann wollen wir mal sehen, ich werd das jetzt mal ganz brav step-bystep befolgen…

1. SVN-Client Installieren (Subclipse beispielsweise)
2. Das Alfresco-Repository unter svn://svn.alfresco.com/alfresco/HEAD konnektieren und Revision 574 holen (dauert erwartungsgemäß ewig…)
3. Die Umgebungsvariable JBOSS_HOME auf die JBoss AS Installation setzen
4. Ant herunterladen und als Standalone installieren. Das ANT-bin-Verzeichnis in die Umgebungsvariable PATH aufnehmen. Umgebungsvariable ANT_HOME setzen.
5. JAVA_HOME aufs JDK setzen
6. In dem Verzeichnis root/common des Alfresco-Projektes das Tartget build-jboss ausführen: ant build-jboss. Es entstehen folgende Dateien, die vom build-Script freundlicherweise gleich deployed werden:
7. • ${jboss.home}/bin/.hotspot_compiler (was auch immer der macht…)
   • ${jboss.home}/server/default/lib/mysql-connector-java-5.0.3-bin.jar (andere MySQL-Treiber werden entfernt)
   • ${jboss.home}/server/default/deploy/alfresco.war
8. In der Datei ${jboss.home}/bin/run.bat (bzw. run.sh) folgenden Code zu den JAVA_OPTS hinzufügen:
   -server -XX:MaxPermSize=128m cvx (Siehe auch: Das PermgenSpace-Problem)
9. Leere Datenbank “alfresco” in MySQL anlegen:
   create database alfresco;
grant all privileges on alfresco.* to 'alfresco'@'localhost'
identified by 'alfresco' with grant option;
grant all privileges on alfresco.* to 'alfresco'@'localhost.localdomain'
identified by 'alfresco' with grant option;
10. Und go!

So, jetzt kommt also der Moment, in dem die Kuh den Schwanz hebt… uuund … läuft! Fast.

Ein Problem gibt es jetzt noch: Nach dem erfolgreichen Einklinken des AlfrescoClientWindow-Portlets bzw. beim Anzeigen desselben erscheint die Fehlermeldung:

Unable to find setter method for attribute acceptCharset in /jsp/browse/browse.jsp.

Ein Blick in diese Dateio zeigt:

<h:form acceptCharset="UTF-8" id="browse">

Der h-Namespace kommt von MyFaces. Achja, da war ja noch was, die MyFaces-Bibliotheken sollten ohnehin ersetzt werden. Also:

${jboss.home}/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs/myfaces-* löschen und durch aktuelle (1.1.5+) ersetzen. Und? Nee!

Nun kommt im AlfrecoClientWindow:

javax.faces.FacesException: org.apache.jasper.JasperException:
The absolute uri: http://java.sun.com/jsf/html
cannot be resolved in either web.xml or the jar files
deployed with this application

Na toll, was soll das jetzt? Nach einiger Recherche habe ich nun die myfaces-libs in der Version 1.1.1 nach ${jboss.home}/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs kopiert. Nun ist alles super!

13:29:40,531 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel)
[4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)]
Started in 4m:11s:235ms (hmpf…)

Da wir gerade dabei sind, Alfresco (ursprünglich in der Version 1.4) bei einem unserer Kunden einzuführen, stellt sich nun
natürlich die spannende Frage, was uns dieses Major Release nun konkret bringt.

Zunächst wäre da mal die lange erwartete WCMS-Komponente, also ein JSR-170 konformes System für Webcontent.

Hier zunächst mal ein Ausschnitt aus dem Original Post:

[...] This release introduces a number of new features, including:

• GPL with FLOSS exception
• Web Content Managment 1.0 with:
  • Web Project Wizard
  • Forms Management Wizard
  • Website Development and Staging
  • XML Content Authoring
  • FreeMarker, XSL and XSL-FO transformations
  • Virtualization and In-Context Preview
  • Workflow for change sets
• Federated Search
• OpenSearch support
• Add-on Module Management
• Tree Navigation (AJAX)
• Multilingual Services

[...]

Nun gut, sagt mir erstmal noch so viel, muss ich gestehen. Werde mich mal dranmachen, das ganze zu evaluieren…

Folgende Schritte waren letztendlich nötig:

1. Server Konfiguration

In der Datei ${jboss.home}/server/default/conf/service.xml muss folgender Block eingefügt (bzw. einkommentiert und angepasst) werden:

<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">ports-01</attribute>
<attribute name=”StoreURL”>
${jboss.home.url}/server/default/conf/service-bindings.xml
</attribute>
<attribute name=”StoreFactoryClassName”>
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>Damit wird über service-bindings.xml ein alternatives Binding, also eine alternative Portkonfiguration definiert. Diese Date findet man als Vorlage unter ${jboss.home}/docs/examples/binding-manager/sample-bindings.xml

Inder Datei service-bindings.xml werden zwei Serverkonfigurationen definiert: ports-default, die bleibt so wie sie ist, und server-01, das ist unsere modifizierte Konfiguration.

Hier die wichtigen Stellen aus dieser Datei:

<service-bindings>
<!-- Standardkonfiguration -->
<server name="ports-default">
<service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
<delegate-config portName="Port" hostName="BindAddress">
<attribute name="RmiPort">1098</attribute>
</delegate-config>
<binding port="1099" host="${jboss.bind.address}" />
</service-config>
<service-config name="jboss:service=WebService"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
<delegate-config portName="Port" />
<binding port="8083" />
</service-config>
<!-- usw. für alle definierten Portnummern -->
</server>
<!-- Hier wirds spannend... -->
<server name="ports-01">
<!-- Umkonfiguration des Naming-Dienstes -->
<service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
<delegate-config portName="Port" hostName="BindAddress">
<attribute name="RmiPort">1198</attribute>
</delegate-config>
<binding port="1199" host="${jboss.bind.address}" />
</service-config>
<!-- Der Rest bleibt wie er ist... -->
</server>
</service-bindings>

2. Patch für JBoss ESB 4.0

Beim Hochfahren der jUDDI-Registry ver sucht der ESB, diese bei localhost:1099 anzumelden, was ja normalerweise auch richtig ist. Nutzt man den ESB mit jUDDI, so muss im Verzeichnis ${jboss.home}/server/default/conf die Datei juddi.properties vorhanden sein. In dieser lässt sich so einiges bzgl. der Registry für den Service-Bus konfigurieren, unter Anderem folgendes:

# JNDI settings (used by RMITransport
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1199
java.naming.factory.url.pkgs=org.jboss.namingSuper, genau, was man braucht! Denkste. Die olle Registry meldet sich immer noch auf localhost:1099 an. Der Grung dafür ist ein Bug im JBoss ESB, genauer am jUDDI-Proxy. Folgende Klasse existiert im ESB:

# JNDI settings (used by RMITransport)
package org.jboss.internal.soa.esb.dependencies;
import java.io.File;
import java.net.URI;
import java.util.Properties;
import java.io.IOException;
import java.io.InputStream;
import javax.naming.InitialContext;
public class JuddiRMIService extends ServiceMBeanSupport
implements JuddiRMIServiceMBean {
private Logger logger = Logger.getLogger(this.getClass());
protected void startService() throws Exception {
logger.info("starting juddi RMI service");
final String confURL = System.getProperty("jboss.server.config.url") ;
final URI confDirURI = new URI(confURL) ;
final File confDir = new File(confDirURI) ;
System.setProperty("juddi.propertiesFile", confDir + "/juddi.properties");
JNDIRegistration.register();
}
protected void stopService() throws Exception {
logger.info("Unbinding juddi services");
final InitialContext ic = new InitialContext() ;
ic.unbind(JNDIRegistration.INQUIRY_SERVICE) ;
ic.unbind(JNDIRegistration.PUBLISH_SERVICE) ;
}
}Der Fehler tritt bei JNDIRegistration.register() auf. Das Problem ist, dass die jUDDI-Konfiguratiuon beim Aufruf dieser Static-Methode noch gar nicht eingelesen ist, also wird fröhlich weiter beim Standard JNDI-Port localhost:1099 angemeldet. Hier der Patch:

package org.jboss.internal.soa.esb.dependencies;
import java.io.File;
import java.net.URI;
import java.util.Properties;
import java.io.IOException;
import java.io.InputStream;
import javax.naming.InitialContext;
import org.apache.juddi.registry.RegistryEngine;
import org.apache.juddi.registry.rmi.JNDIRegistration;
import org.apache.log4j.Logger;
import org.jboss.system.ServiceMBeanSupport;
import org.apache.juddi.util.Config;
import org.apache.juddi.util.Loader;
public class JuddiRMIService extends ServiceMBeanSupport
implements JuddiRMIServiceMBean {
private Logger logger = Logger.getLogger(this.getClass());
private static final String PROPFILE_NAME = “juddi.properties”;
protected void startService() throws Exception {
logger.info(”starting juddi RMI service”);
final String confURL = System.getProperty(”jboss.server.config.url”) ;
final URI confDirURI = new URI(confURL) ;
final File confDir = new File(confDirURI) ;
System.setProperty(”juddi.propertiesFile”, confDir + “/juddi.properties”);
logger.info(”** Patch om@form4: start preloading properties”);
try {
InputStream stream = Loader.getResourceAsStream(PROPFILE_NAME);
if (stream != null) {
Properties props = new Properties();
props.load(stream);
Config.addProperties(props);
logger.info(”** Patch om@form4: preloading properties successful”);
}
} catch (IOException ioex) {
logger.error(”An error occured while loading properties
from: “+PROPFILE_NAME,ioex);
}
JNDIRegistration.register();
}
protected void stopService() throws Exception {
logger.info(”Unbinding juddi services”);
final InitialContext ic = new InitialContext() ;
ic.unbind(JNDIRegistration.INQUIRY_SERVICE) ;
ic.unbind(JNDIRegistration.PUBLISH_SERVICE) ;
}
}Jetzt muss noch das Build der JBoss ESB-Quellen angeschmissen werden und es entsteht u. A. die Datei jbossesb-dependencies.jar, die in der Original-Distribution ersetzt werden muss.

Nun geht auch das.

3. Umkonfiguration des ESB

Was auch stundenlanges Debuggen erfordert hat, ist eigentlich ganz einfach: In der Datei ${jboss.home}/server/default/conf/jbossesb.xml wird die jndi-url lapidar mit “localhost” angegeben. Das muss konkretisiert werden. Aus:

<jms-provider name="JBossMQ"
connection-factory="ConnectionFactory"
jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
jndi-URL="localhost">wird:

<jms-provider name="JBossMQ"
connection-factory="ConnectionFactory"
jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
jndi-URL="localhost:1199">Ähnliches nochmal in ${jboss.home}/server/default/conf/jbossesb-properties.xml . Aus:

<property name="org.jboss.soa.esb.jndi.server.url" value="localhost“/>wird:

<property name="org.jboss.soa.esb.jndi.server.url" value="localhost:1199“/>

4. jndi.properties umkonfigurieren

Zu guter letzt noch in der Datei ${jboss.home}/server/default/conf/jndi.properties folgende Zeile ergänzen:

java.naming.provider.url=jnp://localhost:1199Jetzt ist alles gut!

folgende:
set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m
-XX:+CMSPermGenSweepingEnabled -XX:MaxPermSize=128m
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000

Der PermGenSpace liegt standardmäßig bei 64m, was für den feisten JBoss AS offensichtlich etwas knapp bemessen ist. Hierüber wird dieser Wert auf 128m erhöht.
Trotzdem geht der JBoss mit dem PermGenSpace offensichtlich etwas schluderig um, denn auch bei 128m ist dieser nach einem Tag Intensiver Entwicklung voll, und der Server muss neu gestartet werden. Deutet auf ein Speicherleck hin…

Kurz zur Erklärung: Smooks ist ein Framework zur generischen Verarbeitung von XML-Dateien, bzw. XML-Fragmenten. Die Verarbeitung ist einfach: In einer Mapping-datei wird für jeden XML-Pfad ein Handler definiert, der über das Visitor-Pattern irgendetwas ausführt. So kann für ein Element (oder einen Teilbaum) z.B. ein XSLT ausgeführt werden oder auch völlig individueller Java-Codeausgeführt werden.

Hier ein Beispiel aus der Mapping-Datei (smooks-res.xml):

<smooks-resource selector="ORDER"
useragent="from-type:text/xml:fullfillorder and
from:dvdstore:orderdispatchservice"
path="org.milyn.javabean.ProcessingPhaseBeanPopulator" >
<param name="beanId">ORDER</param>
<param name="beanClass">org.jboss.soa.esb.dvdstore.Order</param>
<param name="addToList">true</param>
</smooks-resource>
<smooks-resource selector="ORDER"
useragent="from-type:text/xml:fullfillorder and
from:dvdstore:orderdispatchservice"
path="org.milyn.javabean.ProcessingPhaseBeanPopulator" >
<param name="beanId">order</param>
<param name="attributeName">orderId</param>
</smooks-resource>
<!-- ... repeat for each attribute ... -->

In diesem Beispiel wird für jedes Element “ORDER” der ProcessingPhaseBeanPopulator “besucht”. Der ProcessingPhaseBeanPopulator wird vom smooks-Framework über eine sog. Cartridge mitgeliefert. Er hat die Aufgabe, aus dem element “ORDER” ein POJO, also eine Java-Klasse zu generieren. Attribute können zu Java-Properties gemappt werden und für Unterelemente können ebenfalls Visitors definiert werden, die beispielsweise wiederum Properties setzen. Sowie sogut. Das Problem ist bloss, dass bei “echten” Business-Daten die Datenstrukturen nicht so trivial sind, wie in dem vom ESB mitgelieferten Sample “quickstarts/transformXML2POJO“. Habe ich ein ORDER-Element mit 30 oder mehr Unterelementen, die die Properties der ORDER definieren, wird mein smooks-mappingfile recht umfangreich und vor allem sehr wartungsfeindlich.

Schön wäre eine Smooks-Cartridge, die die Unterlemente eines XML-Elements automatisch auf die Properties (genaugesagt auf die Setter) meines POJO Mappt. So kann mit minimaler Konfiguration eine ganze Reihe von umfangreichen XML-Strukturen auf POJOs transformiert werden, ohne tonnenweise quasi-redundanten Konfigurationscode zu erzeugen.

Hierzu habe ich die von smooks mitgelieferte javabeans-cartridge etwas modifiziert, so dass folgende Konfiguration möglich ist:

<smooks-resource selector="ORDER"
useragent="from-type:text/xml:fullfillorder and
from:dvdstore:orderdispatchservice"
path="org.milyn.javabean.MyProcessingPhaseBeanPopulator" >
<param name="beanId">order</param>
<param name="beanClass">org.jboss.soa.esb.dvdstore.Order</param>
<param name=”attributesFromChildren”>true</param>
</smooks-resource>

Damit das funktioniert, habe ich in der Klasse ProcessingPhaseBeanPopulator etwas Code ergänzt.

Zunächst das Einlesen der Konfiguration, die nun den Parameter “attributesFromChildren” unterstützen soll:

public void setConfiguration(SmooksResourceConfiguration config) {
// ... existing code
// START Added by om, form4
attributesFromChildren =
config.getBoolParameter("attributesFromChildren", false);
// END Added by om, form4
}

Und das Processing im eigentlichen Visitor:

public void visit(Element element, ContainerRequest request) {
Object bean = getBean(request);
// START Added by om, form4
if (attributesFromChildren) {
NodeList children = element.getElementsByTagName("*");
for (int i = 0; i < bean.getClass().getMethods().length; i++) {
Method method = bean.getClass().getMethods()[i];
if (method.getName().startsWith(”set”)) {
String attr = method.getName().replaceAll(”^set”, “”).toLowerCase();
for (int j = 0; j < children.getLength(); j++) {
Element child = (Element) children.item(j);
if (attr.equalsIgnoreCase(child.getNodeName())) {
try {
String val = DomUtils.getAllText(child, false);
method.invoke(bean, new Object[] { val });
} catch (Exception e) {
logger.error(e); // etwas ignorant…
}
break;
}
}
}
}
}
// END Added by om, form4
// … go on with original code …
}


<action class="org.jboss.soa.esb.actions.SeamProxy" name="MySeamComponent"/>

Der Name MySeamComponent würde innerhalb einer solchen Out-of-the-Box-Action automatisch auf das @Name der Seam-Komponente gemappt werden (die Action löst das intern über einen JNDI-Lookup).

Weiterhin im Gespräch ist ein Action-Interface MarshalledActionProcessor mit einer einzigen Methode mit folgender Signatur:

public Object process(Object[] objects) throws ActionProcessingException;

So kann innerhalb von Seam, wie in Seam üblich, mit einem ganz normalen Objekt gearbeitert werden, während sich das ESB-Developer-Team von JBoss überlegt wie sie eine ESB-Message in ein Objekt transformiert (marshalled).

Dies sind jedoch lediglich erste Gedanken der ESB-Entwickler. Die Diskussion hierüber kann derzeit im JBoss ESB Developer Forum nachvollzogen werden.

Einfache Lösung: Die Extension cl_becache installieren. Nun kann für eine Backendbenutzergruppe (be_groups) die Option “FE-Cache löschen” aktiviert werden.

Definitiv die falsche Gesellschaft.

Die Ausgabe von neuem Land wird offenbar zurückgehalten, um die Landpreise in die Höhe zu treiben. Ein freundlicher Immobilienmakler erzählte mir heute, First Land gäbe es derzeit quasi überhaupt nicht. Für 512 qm müsste ich round about 9000 - 10000L$ berappen, das sind etwa 35 US$.

Neben Sex und Parties ist der Immobilienhandel in SL der größte Markt. Heute fand ich z.B. ein hübsches Fleckchen Erde, nicht mal besonders groß, für sage und schreibe 230.000 L$ (ca. 850 US$). Wer gibt denn so viel Geld aus für Land, das ausschlißlich im “Grid” existiert? Spekulanten tun das, und Leute, die hoffen, auf Ihrer Parzelle ein gut laufendes Geschäft zu errichten.

Die Rücktauschmöglichkeit von Linden-Dollar in harte US-Dollar gibt dem ganzen die nötige Schubkraft, denn hier wird reales Business in einer virtuellen Welt gemacht. Es ist ein wenig wie New Economy hoch zehn: Turbokapitalismus und Hedo-Liberalismus pur. Normalerweise würde ich sagen: Von mir aus, warum nicht, wenns spaß macht. Aber einen entscheidenen Unterschied gibt es dann doch: Dies ist kein selbstregulierendes turbokapitalistisches System, sondern eine Diktatur. Die wenigsten Spekulanten und “Geschäftsleute” im neuen Land nehmen wahr, dass die wirtschaftlichen Entwicklungen einer zentralistischen Steuerung der Linden-Freaks unterliegen. Die Grundstückspreise werden über die das Angebotes genau gesteuert. Wie kann ich denn heute teuers Land kaufen und morgen werden vielleicht wieder 400 qkm frische neue Welt ins Grid gepustet? Oder der Bezirk in dem sich mein Land befindet wird zur Kampfzone erklärt?

Na dann schon lieber New Economy, die reguliert sich wenigstens noch selber…

Leider stürzt Eclipse nun (wie auch nach der Installation der JBoss IDE) ab und zu ab. Ich weiß nicht, ob es an diesem Plugin liegt. Weiterfahren und beobachten, würde ich sagen.

Fazit: Ich benutze jetzt BlogDesk.

Hallo ich bin Quelltext im CODE-Tag


Okay, scheint zu gehen. Jetzt ein Bild … Nee, geht nicht. Muss manuell hochgeladen werden und macht nichtmal Thumbnails. Kannste ja wohl vergessen…

Aahh, Bild einfügen geht auch (man beachte den rekursiven Screenshot im Screenshot … man, hab ich eigentlich nix besseres zu tun?).

Hmm, aber eine CODE-Formatierung finde ich hier auch nicht, schade…

Blockquote geht.

Bunt auch.

Aber kein CODE :(  Dafür ist es möglich, vorhandene Blogeinträge zu laden (und vermutlich auch zu verändern).

Na immerhin… Dann mal PUBLISH!

Wolln mal sehen, ob das ankommt…

Hier noch ein Bildchen:

• CODE-Formatierung (für Softwareentwickler nicht ganz unwichtig)
• Thumbnails mit Click auf Detailview (ambesten mit der unten beschribenen Thickbox-Klasse! (Oder hab ich mich nur zu blöd angestellt?
• Beiträge nachträglich bearbeiten? Ist das zuviel verlangt?

Na mal sehen, was andere Tools so können…

1. Thickbox herunterladen, entpacken und das Verzeichnis thickbox nach wp-content/plugins kopieren (ist aber eigentlich gar kein Plugin). Den ImageWizard kann man sich sparen.
2. Ins head-Tag im Template folgenden Code einfügen:
   <script type="text/javascript"
src="/wp-content/plugins/thickbox/jquery-latest.js"></script>
<script type="text/javascript"
src="/wp-content/plugins/thickbox/thickbox.js"></script>
<link rel="stylesheet" href="/wp-content/plugins/thickbox/thickbox.css"
type="text/css" media="screen" />

3. Nun noch die loadingAnimation.gif besorgen (z.B. von hier
   und nach /images kopieren.

So. das wars. Um das ganze zu aktivieren muss beim Einfügen eines Bildes in einen Post nur das Attribut class=”thickbox” in das A-Tag eingefügt werden. Fertig.

Hier ein Beispiel:

 
Wie das jetzt genau funktioniert ist mir jedoch schleierhaft… Aber man muss ja nicht alles wissen

10:32:40,531 WARN [ServiceController] Problem starting service
jboss.mq:service=PersistenceManager
org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions.
Message recovery may not be accurate; - nested throwable:
(com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Every derived table
must have its own alias)
at org.jboss.mq.pm.jdbc2….resolveAllUncommitedTXs(PersistenceManager.java:492)
…
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
… at blablabla …
at org.jboss.Main$1.run(Main.java:490)
at java.lang.Thread.run(Thread.java:595)
Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException:
Every derived table must have its own alias
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
… at blubber, sülz …
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.
executeQuery(WrappedPreparedStatement.java:236)
at org.jboss.mq.pm.jdbc2.PersistenceManager.
resolveAllUncommitedTXs(PersistenceManager.java:424)
… 111 more

Nach einigen Nachforschungen hat sich herausgestellt, dass das folgende SQL-Statement von der MySQL-Datenbank hochnäsig zurückgewiesen wurde:

SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS
UNION SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES)

Warum? Weil das Subselect offensichtlich auch einen Alias benötigt. Na von mir aus. Ein Schmökern in den JBoss-Foren und im JIRA hat mir auch nicht wirklich weitergeholfen. Beim Vergleich diverser User-Erfahrungen stellte sich herau, dass das Problem nicht auftritt, wenn man MySQL in einer Version größer als 4.0.13 und kleiner als 4.0.20 verwendet. Naja. Mit meiner brandheißen 5.0.27 bin ich da ja weit von entfernt. Im Bugtracker diskutieren die Entwickler lediglich die Frage, ob der Bug gefixt wird, dass er ja eigentlich schon gefixt ist, warum er dann nicht im Release ist, das das wohl vergessen wurde, ob er denn überhaupt gefixt werden muss, usw. usw…

Nun, die Lösung ist einfach:

Man schnappe sich die die Datei
[jboss.root]/server/default/deploy/jms/hsqldb-jdbc2-service.xml

und ändere diese Zeile:
SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS
UNION SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES)
wie folgt ab:
SELECT_MAX_TX = SELECT MAX(TXID) TXID FROM
(SELECT MAX(TXID) AS TXID FROM JMS_TRANSACTIONS UNION
SELECT MAX(TXID) AS TXID FROM JMS_MESSAGES) AS ichbindergottverdammtealias

Nun erzählt mir mein lieber JBoss Server noch dass die Tabelle JMS_TRANSACTIONS nicht existiert. Also in der selben Datei nochmal kurz gepatcht. Folgende Zeilen:

CREATE_MESSAGE_TABLE =
CREATE CACHED TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL,
DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1),
MESSAGEBLOB OBJECT, PRIMARY KEY (MESSAGEID, DESTINATION) )
CREATE_TX_TABLE = CREATE CACHED
TABLE JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) )

ändern zu:
CREATE_MESSAGE_TABLE =
CREATE TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL,
DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1),
MESSAGEBLOB BLOB, PRIMARY KEY (MESSAGEID, DESTINATION) )
CREATE_TX_TABLE = CREATE TABLE JMS_TRANSACTIONS ( TXID INTEGER, PRIMARY KEY (TXID) )


Nun ist Ruhe.

Für alle die nicht wissen, was “First Land” ist: “First Land” ist Land in der Größe von 512 qm das man zu einem extrem günstigen Kurs (für 512 L$) direkt kaufen kann. Angeblich wird fast täglich neues First Land zur Verfügung gestellt, das sich die Newbies dann unter den Nagel reißen können. Vorausetzung um First Land zu erwerben ist: 1. Man ist Premium Mitglied und 2. Man hat noch nie vorher Land besessen. Abgesehen vom “First Land” ist Land nämlich schweineteuer in der bunten Parallelwelt.

Unter Apache, PHP, MySQL und TYPO3 existieren natürlich sehr viele Stellschrauben, an denen man drehen kann. Was wie viel bringt lässt sich in dem Artikel nachlesen.

Im Ergebnis stellten sich das TYPO3-Caching und der Einsatz von PHP-Beschleunigern wie eAccelerator als die wirkungsvollsten Tuning-Maßnahmen heraus.

Zum vollen Artikel geht es hier.

Guckst Du hier: worlds-highest-website.com

Nur schade, dass ein solch idealistisches Thema mit kommerziellen Motiven verfolgt wird. Würde so etwas aus der Open Source Community erwachsen, wäre es eine echte Alternative zu “wirklichen” Leben…

Aber ein Blick in diese “schöne neue Welt” lohnt in jedem Fall, die Idee ist (wenn auch nicht ganz neu) großartig!