Partial refresh aktualisiert auch andere Elemente

[eknori]

Bin letzte Woche im Zuge einer Fehleranalyse auf ein Problem gestossen, das auch für andere relevant sein könnte. Im XPages Forum bei IBM habe ich das Problem schon gepostet; dort hält man sich aber liever vornehm zurück.

Ich erkläre die Situation am besten einmal anhand eines kleinen code snippets,mit dem ich den Fehler unter 8.5.3UP1 reproduzieren kann

Code

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
	<xp:button value="Label" id="button1">
		<xp:eventHandler event="onclick" submit="true"
			refreshMode="partial" refreshId="col1" />
	</xp:button>
	<xp:table>
		<xp:tr>
			<xp:td id="col1">
				<xp:text escape="true" id="computedField2" value="#{javascript:@Now()}">
					<xp:this.converter>
						<xp:convertDateTime type="both" />
					</xp:this.converter>
				</xp:text>
			</xp:td>
			<xp:td id="col2">
				<xp:text escape="true" id="computedField1" value="#{javascript:@Now()}">
					<xp:this.converter>
						<xp:convertDateTime type="both" />
					</xp:this.converter>
				</xp:text>
				<xp:dataTable id="dataTable1" rows="30">
					<xp:this.value><![CDATA[#{javascript:
					print('You shall not refresh');
}]]></xp:this.value>
					<xp:column id="column1" />
				</xp:dataTable>
			</xp:td>
		</xp:tr>
	</xp:table>
</xp:view>

EinfacheXPage mit einer 2 spaltige Tabelle

col1 enthält ein computedText control mit @Now()
col2 enthält ein computedText control mit @Now() + einer datatable. In den Values der datatable gibt es lediglich ein print statement.

Das erwartete Verhalten ist:

Click auf den Button, der sich über der Tabelle befindet; dies löst einen partial refresh auf col1 aus. Die Anzeige wird dort aktualisiert. Die Anzeige in col2 nicht.
Das funktioniert.

Was aber ist mit der datatable? Man könnte erwarten, daß diese nicht vom partial refresh aktualisiert wird; sie befindet sich ja in col2

Aber weit gefehlt: Blick auf die ServerConsole. Und was sehen meine Augen dort bei jedem Click auf den Button?

Richtig: You shall not refresh

Das kann doch nicht wirklich richtig sein, oder ??

[Sven Hasselbach]

Hallo,

ich habe im XPages Forum eine kurze, aber einfache Antwort gegeben  

Es ist leider ein "normales" Verhalten seit es XPages gibt: Alle Datencontainer (Datatable, Repeats, Datacontexts ) werden bei Partial Refreshs neu berechnet, sogar mehrfach, auch Partial Execution hilf da nicht.

Für Datatables geschieht dies in der "Apply Request Values"-Phase, als auch in der "Render Response"-Phase, bei Data Context-Variablen sieht das ganz noch übler aus (in JEDER Phase findet die Berechnung statt).

Beispel Code für eine "verzögerte" Data Context-Variable, da kann man das auf der Konsole besser sehen:

Code

<xp:this.dataContexts>
   <xp:dataContext var="x">
      <xp:this.value><![CDATA[#{
         javascript:print( java.lang.System.currentTimeMillis() + " -> DC Recalc! ");
         java.lang.Thread.currentThread().sleep(100);
         '1'}]]>
      </xp:this.value>
   </xp:dataContext>
</xp:this.dataContexts>

Das Beispiel verdeutlich auch nochmal, das die Berechnung wirklich mehrmals ausgeführt wird. Richtig ist das nicht...

Ich habe mir damit beholfen, die Refresh-Id abzufangen, und dann die Berechnung ggf. Abzubrechen

Code

<xp:repeat id="repeat1" rows="30" var="rCol">
   <xp:this.value><![CDATA[#{javascript:
      function calculate(){
         var data:java.util.Vector = new java.util.Vector();
         data.add(java.lang.System.currentTimeMillis());
         return data;
      }

      if( viewScope.containsKey("data") == false){
         viewScope.data = calculate();
         return viewScope.data;
      }
      if( com.ibm.xsp.ajax.AjaxUtil.isAjaxPartialRefresh(facesContext) === true ){
         var pId = com.ibm.xsp.ajax.AjaxUtil.getAjaxComponentId( facesContext  );
         if( pId !== getClientId( 'repeat1' ) )
            return viewScope.data;
      }

      viewScope.data = calculate();
      viewScope.data}]]>
   </xp:this.value>
   <xp:label value="#{javascript:rCol }" id="label1"></xp:label>
</xp:repeat>

Sven

[eknori]

Danke für die Antwort (und die Bestätigung meiner beobachtungen)

werden bei Partial Refreshs neu berechnet, sogar mehrfach,

bei Data Context-Variablen sieht das ganz noch übler aus (in JEDER Phase findet die Berechnung statt).

Genau da ist das Problem bei uns aufgetreten; da wurden ~ 2.500 Dokumente insgesamt 8 mal komplett neu berechnet.  Und dann das Ganze gleich 1 - n fach, da wir mehrere Dokumente im TabContainer öffnen. Das geht dann ganz schnell in Richtung "Unbrauchbarkeit".

Dann wird also nichts weiter helfen, als das abzufedern. Gut, dann weiss ich wenigstens, dass es kein Bug, sondern ein feature ist.

Ist das eigentlich irgendwo "offiziell" dokumentiert, oder hast du es auch über den schmerzhaften Weg herausgefunden?


Würde dann also bedeuten, daß die Neuberechnungen auch dann ausgeführt werden wenn ich ein simple binding auf eine view mache. Nur daß es da nicht "auffällt", weil man dort nichts per print auf der Konsole ausgeben kann.
Wundert mich echt, daß das noch niemandem so wirklich aufgestossen ist. Offensichtlich enthalten die Applikationen bei anderen nur ein paar Datensätze. Dann ist das Verhalten sicher zu verschmerzen.
Bei uns kam schnell die Denke auf, "wenn das da passiert, dann möchte ich gerne mal wissen, wo solche versteckten Bremsen noch überall eingebaut sind". Und über mangelhafte Performance in manchen Situationen müssen wir uns dann auch nicht weiter wundern.
Das verkaufe mal dem Auftraggeber ... Selbst wenn sich im Idealfall ein paar leute finden, die gewillt sind auf den Zug PMR aufzuspringen, habe ich aus Erfahrung die Vermutung, daß das seitens IBM als "works as designed" abgetan wird. In JEDE Datenquelle eine Abfrage einzubauen ist ein netter Workaround, aber auf Dauer nicht der richtige Weg.

Auf der einen Seite freut es mich, daß ich nicht wieder der Einzige bin, auf der anderen Seite hat mir die Antwort den Tag echt vermiest.

[Sven Hasselbach]

Tut mir leid, Dir den gestrigen Tag vermiest zu haben.

Ich habe das auch über den schmerzvollen Weg rausbekommen und ich denke nicht, dass das näher dokumentiert ist. "Works as designed" ist das Stichwort, denn das Verhalten ist durchaus erklärbar und es ist (glaube ich) auf die nicht JSF-konforme Implementierung des SSJS zurückzuführen.

Beispielsweise das dürfte nicht gehen, geht aber:
${'#'}{javascript:Java.lang.System.currentTimeMillis()}

Ein Compute On Page Load wird zu einem Computer Dynamically aber das Binding ist weiterhin im Page Load... Gemäß Unified EL Spezifikation nicht zulässig.

Eine "saubere" EL hingegen könnte funktionieren, d.h. simple Bindings bzw. Managed Beans müssten ohne Neuberechnung funktionieren. Aber das muss ich noch ausprobieren, mache ich die Tage.

Zwei Tipps noch:
1. Partial Refreshs möglichst mit GET ausführen, das vermindert die Anzahl der Neuberechnungen (oder mit execMode="partial" arbeiten)
2. Datenquellen nach Möglichkeit mit Computer On Page Load berechnen

Einen schönen Sonntag noch
Sven

[eknori]

Jetzt kapier ich es gar nicht mehr, Habe in beiden Buttons PartialExecutionMode gesetzt und schon funktioniert es, wie beabsichtigt.
Ich bin mir 100% sicher, daß es in dieser Konstellation vorher nicht funktioniert hat.
Also, Testreihe noch einmal von vorne.

[Sven Hasselbach]

Das ist meine Beobachtung, die leider ein anderes Ergebnis auf der Konsole liefert. Ich habe die obige XPage um einen Zeitstempel für den Output ergänzt und einen Debug-PhaseListener dazwischen geschaltet. Zur Verdeutlichung habe ich jeweils den Code des Buttons inkl. der Ausgabe auf der Serverkonsole gepostet.

Hier der Code der Datatable:

Code

<xp:dataTable id="dataTable1" rows="30">
   <xp:this.value><![CDATA[#{javascript:
      print(java.lang.System.currentTimeMillis() + ' You shall not refresh');
   }]]></xp:this.value>
   <xp:column id="column1" />
</xp:dataTable>

Button

Code

<xp:button value="Label" id="button1">
   <xp:eventHandler event="onclick" submit="true" refreshMode="partial" refreshId="col1" />
</xp:button>

1. Öffnen der XPage

Code

19.02.2012 18:02:17   HTTP JVM: Before phase: RENDER_RESPONSE 6
19.02.2012 18:02:17   HTTP JVM: 1329670937472 You shall not refresh
19.02.2012 18:02:17   HTTP JVM: After phase: RENDER_RESPONSE 6

2. Partial Refresh

Code

19.02.2012 18:05:37   HTTP JVM: Before phase: RESTORE_VIEW 1
19.02.2012 18:05:37   HTTP JVM: After phase: RESTORE_VIEW 1
19.02.2012 18:05:37   HTTP JVM: Before phase: APPLY_REQUEST_VALUES 2
19.02.2012 18:05:37   HTTP JVM: 1329671137733 You shall not refresh
19.02.2012 18:05:37   HTTP JVM: After phase: APPLY_REQUEST_VALUES 2
19.02.2012 18:05:37   HTTP JVM: Before phase: PROCESS_VALIDATIONS 3
19.02.2012 18:05:37   HTTP JVM: After phase: PROCESS_VALIDATIONS 3
19.02.2012 18:05:37   HTTP JVM: Before phase: UPDATE_MODEL_VALUES 4
19.02.2012 18:05:37   HTTP JVM: After phase: UPDATE_MODEL_VALUES 4
19.02.2012 18:05:37   HTTP JVM: Before phase: INVOKE_APPLICATION 5
19.02.2012 18:05:37   HTTP JVM: After phase: INVOKE_APPLICATION 5
19.02.2012 18:05:37   HTTP JVM: Before phase: RENDER_RESPONSE 6
19.02.2012 18:05:37   HTTP JVM: 1329671137769 You shall not refresh
19.02.2012 18:05:37   HTTP JVM: After phase: RENDER_RESPONSE 6

Die Berechung der DataTable erfolgt zwei Mal, das Element wurde nicht refresht.

Ändere ich den Code des Buttons auf Partial Execution, ist das Ergebnis wie folgt:

Button

Code

<xp:button value="Label" id="button1" execMode="partial">
   <xp:eventHandler event="onclick" submit="true" refreshMode="partial" refreshId="col1" />
</xp:button>

1. Öffnen der XPage

Code

19.02.2012 18:13:54   HTTP JVM: Before phase: RENDER_RESPONSE 6
19.02.2012 18:13:54   HTTP JVM: 1329671634490 You shall not refresh
19.02.2012 18:13:54   HTTP JVM: After phase: RENDER_RESPONSE 6

2. Partial Refresh

Code

19.02.2012 18:14:02   HTTP JVM: Before phase: RESTORE_VIEW 1
19.02.2012 18:14:02   HTTP JVM: After phase: RESTORE_VIEW 1
19.02.2012 18:14:02   HTTP JVM: Before phase: APPLY_REQUEST_VALUES 2
19.02.2012 18:14:02   HTTP JVM: 1329671642321 You shall not refresh
19.02.2012 18:14:02   HTTP JVM: After phase: APPLY_REQUEST_VALUES 2
19.02.2012 18:14:02   HTTP JVM: Before phase: PROCESS_VALIDATIONS 3
19.02.2012 18:14:02   HTTP JVM: After phase: PROCESS_VALIDATIONS 3
19.02.2012 18:14:02   HTTP JVM: Before phase: UPDATE_MODEL_VALUES 4
19.02.2012 18:14:02   HTTP JVM: After phase: UPDATE_MODEL_VALUES 4
19.02.2012 18:14:02   HTTP JVM: Before phase: INVOKE_APPLICATION 5
19.02.2012 18:14:02   HTTP JVM: After phase: INVOKE_APPLICATION 5
19.02.2012 18:14:02   HTTP JVM: Before phase: RENDER_RESPONSE 6
19.02.2012 18:14:02   HTTP JVM: 1329671642360 You shall not refresh
19.02.2012 18:14:02   HTTP JVM: After phase: RENDER_RESPONSE 6

Selbst wenn ich das Event explizit auf Partial Execution setze, wird der Code berechnet (aber wenigstens nur noch einmal im Render Response)

Button

Code

<xp:button value="Label" id="button1" execMode="partial">
   <xp:eventHandler event="onclick" submit="true" refreshMode="partial" refreshId="col1" execMode="partial"/>
</xp:button>

1. Öffnen der XPage

Code

19.02.2012 18:23:17   HTTP JVM: Before phase: RENDER_RESPONSE 6
19.02.2012 18:23:17   HTTP JVM: 1329672197161 You shall not refresh
19.02.2012 18:23:17   HTTP JVM: After phase: RENDER_RESPONSE 6

2. Partial Refresh

Code

19.02.2012 18:23:18   HTTP JVM: Before phase: RESTORE_VIEW 1
19.02.2012 18:23:18   HTTP JVM: After phase: RESTORE_VIEW 1
19.02.2012 18:23:18   HTTP JVM: Before phase: APPLY_REQUEST_VALUES 2
19.02.2012 18:23:18   HTTP JVM: After phase: APPLY_REQUEST_VALUES 2
19.02.2012 18:23:18   HTTP JVM: Before phase: PROCESS_VALIDATIONS 3
19.02.2012 18:23:18   HTTP JVM: After phase: PROCESS_VALIDATIONS 3
19.02.2012 18:23:18   HTTP JVM: Before phase: UPDATE_MODEL_VALUES 4
19.02.2012 18:23:18   HTTP JVM: After phase: UPDATE_MODEL_VALUES 4
19.02.2012 18:23:18   HTTP JVM: Before phase: INVOKE_APPLICATION 5
19.02.2012 18:23:18   HTTP JVM: After phase: INVOKE_APPLICATION 5
19.02.2012 18:23:18   HTTP JVM: Before phase: RENDER_RESPONSE 6
19.02.2012 18:23:18   HTTP JVM: 1329672198875 You shall not refresh
19.02.2012 18:23:18   HTTP JVM: After phase: RENDER_RESPONSE 6

Selbst das Setzen der execId auf col1 ändert nichts - der Refresh führt immer zu einer Neuberechnung der DataTable (wenn auch nur einmal)...

Sven

[eknori]

@Sven: Vielen Dank für die wirklich ausführlichen Informationen. Werde heute noch einmal in Ruhe testen. Denke, ich werde zu dem gleichen Ergebnis kommen. Evtl. habe ich gestern irgend etwas durcheinander gebracht.

Da das Ergebnis nun offensichtlich feststeht, heisst es nun in der Folge, alle Stellen im Code zu prüfen und den Workaround zu implementieren. Ein gutes Stück Arbeit; wird sich aber lohnen.

[eknori]

Habe noch einmal getestet. Gleiches Ergebnis wie Sven.
Workaround ist schon an einigen Stellen implementiert. Der Unterschied ist gewaltig.
Wer sich also über schlechte Performance seiner Anwendung wundert, der sollte mal in dieser Richtung suchen. ...

[eknori]

Und ich habe noch etwas gefunden, was mir nicht wirklich logisch erscheint:

Auch event handler werden bei einem partial refresh getriggert, wenn sie ausserhalb der refrehId liegen ( in RENDER_RESPONSE phase )
1. zum Einen wird der Code unnötig ausgeführt
2. das Ergebnis des PR wird erst dann angezeigt, wenn der Code abgearbeitet wurde

Entweder habe ich ein Verständnisproblem, oder es läuft hier etwas Grundlegendes falsch ...

[Sven Hasselbach]

Bei Output-Scriptblöcken war das unter 8.5.2 auch der Fall, aber ist wohl mitlerweile (8.5.3) behoben worden.

Das der Partial Refresh erst komplett ist, wenn die Renderphase abgeschlossen ist, ist aber so wie es sein sollte, denn dann wird die Response erst an den Client gesendet.

Auch ein

Code

var response = facesContext.getExternalContext().getResponse();
response.flushBuffer();

hilft da nix...

Ich denke das es sich hierbei schlichtweg um einige Bugs in der Implementierung handelt.

[eknori]

Das der Partial Refresh erst komplett ist, wenn die Renderphase abgeschlossen ist, ist aber so wie es sein sollte, denn dann wird die Response erst an den Client gesendet.

Richtig, aber das rendering verzögert sich halt durch das unnötige Ausführen des event codes ausserhalb der refreshId.

Scriptblöcke werde ich als nächstes testen. Obwohl wir unter 8.5.3 entwickeln ...

[Sven Hasselbach]

Und dann schau Dir auch gleich mal das Verhalten eines Standard Pagers an... 

Um es vorweg zu nehmen:
Die komplette Seite wird refresht, hier wird nur mit execId gearbeitet (funktioniert korrekt, ist aber irgendwie - nun ja - sinnfrei)

[eknori]

Hier auch eine Reaktion von IBM derselbst

PHAN8RPL3D has been logged to track this

gut, dann gibt es sicher bald auch eine Lösung ... 

[flaite]

Is klar, muss natürlich auch meinen Senf dazugeben.... Warum ist es eigentlich so schwierig, die Neuberechnung auf Komponenten zu beschränken, die innerhalb der für den partial refresh angegebenen id-Bereiche liegen? Da hängt das Modell als Baum-Struktur auf dem Server mit den IDs. Und die Daten da werden mit den eigehenden AJAX-Request gesyncht und da stehen ja wohl die ids drin, da wo partial neu berechnet werden soll. So jedenfalls mein Verständnis von JSF.  Und wenn das mit so einem einfachen workaround umgangen werden kann wie dem vom Sven. Wieso ist das nicht im Produkt implementiert?

[eknori]

Warum ist es eigentlich so schwierig, die Neuberechnung auf Komponenten zu beschränken, die innerhalb der für den partial refresh angegebenen id-Bereiche liegen? Da hängt das Modell als Baum-Struktur auf dem Server mit den IDs. Und die Daten da werden mit den eigehenden AJAX-Request gesyncht und da stehen ja wohl die ids drin, da wo partial neu berechnet werden soll. So jedenfalls mein Verständnis von JSF

Du sprichst mir aus der Seele

So jedenfalls mein Verständnis von JSF

Sven hatte ja schon geäußert, dasß JSF wohl nicht richtig implementiert wurde

Und wenn das mit so einem einfachen workaround umgangen werden kann wie dem vom Sven. Wieso ist das nicht im Produkt implementiert?

Weil es offenbar niemanden wirklich interessiert. Das zeigen ja ganz deutlich die nur sehr wenigen Rückmeldungen zu meiner Frage ( nicht nur hier, sondern auch im XPages und Design Partner Forum)
Hatte noch keine zeit, mir die neuen Diskussions und Teamroomtemplate mal genauer anzuschauen. Bin mir aber ziemlich sicher, daß nicht einmal dort der Fehler aufgefallen ist. Würde auch erklären, warum das XPages Forum teilweise sehr langsam ist.

[Thomas Schulte]

Hallo Ulrich. Ich denke das die wenigen Rückmeldungen hier etwas ganz anderes zeigen. Nämlich, das X-PAGES noch nicht wirklich in der Welt da draussen angekommen sind.

Ein ganz anderes Thema ist es, das IBM das Problem noch nicht aufgefallen ist. Aber da ist es eher so etwas wie "Tests! Welche Tests?" ... Ich denke, und das hat sich in vielen anderen Bereichen ja auch schon gezeigt, das IBM, wie viele andere auch sich die Tests bis ins Detail bei neuen Funktionen einfach spart.
Wenn ich so zurückblicke, wieviele der in den letzten zehn Jahren neu eingebaute Funktionen im Domino Server oder dem Notes Client, oder für den Designer sich als nicht ausgereifte, oder nicht zu Ende Programmierte Rohrkrepierer erwiesen haben, dann reiht sich XPages da an manchen Stellen ziemlich nahtlos ein.

[eknori]

Das bei der Komplexität der Software Bugs unvermeidlich sind, ist verständlich. Das man nicht jeden Aspekt einer Funktion testen kann ist sicher eine Sache des Budgets.
Als Unternehmer, Hersteller und Abkassierer für eine Software und den damit zusammenhängenden Support wäre es mir aber oberpeinlich, wenn ein Problem gemeldet wird und das Problem nicht von meinen eigenen Mitarbeitern binnen kurzer Zeit verifiziert und gefixed wird.
Und wenn dann noch ein Workaround aus der Community kommt statt aus den eigenen Reihen ...

Wir erleben das hier tagtäglich, daß Alles wunderbar in "Hello World Size" Applikationen funktioniert. Hat die Anwendung aber einen gewissen Umfang, dann gibt es massive Probleme. Wir suchen uns hier dann mit der kompletten Mannschaft wund und blöde, um überhaupt erst einmal die Ursache zu finden. Von einer LÖSUNG mal ganz zu schweigen.

[m3]

Bei allem Verstaendnis fuer Euren Aerger ...

Der PMR wurde entgegengenommen, das Problem ist reproduzierbar, ein SPR wurde erstellt und ein Entwickler beschaeftigt sich mit dem Problem. Das ist doch eh wunderbar und entspricht dem dafuer vorgesehenen Prozess.
Dass IBM kein kleines Startup mit kurzen Loesungszeiten ist, ist uns doch allen klar, oder?

Und wenn es ein Fehler ist, wird er gefixed, sag ich mal (ich glaub auch an das Gute im Menschen).

[Sven Hasselbach]

Hier eine Version des Workarounds, der noch die Mehrfach-Berechnung abfängt. Es fehlt eigentlich nur noch die Überprüfung, ob der Refresh auf eine elterliche Komponente ausgeführt wurde.

Den Code in z.B. die Werte-Berechnung des Repeat Controls einbauen, die bisherige Berechnung in die Funktion "calculate" übertragen.

Code

/*****
 *** Workaround fuer Refresh-Problem und Mehrfach-Berechnung
 ***
 *****/
 
/*** Der eigentliche Code in die Funktion "calculate" einfügen ***/
function calculate(){
	var data:java.util.Vector = new java.util.Vector();
	data.add(java.lang.System.currentTimeMillis());
	return data;
}

/*** ab hier gehts los ***/
var clientId = getClientId( this.id );
var data = null;

/*** Bisher keine Berechnung **/
if( viewScope.containsKey("fixData-" + clientId ) === false){
	data = calculate();
	viewScope.put( "fixData-" + clientId, data );
    return data;
}

/*** Element wurde nicht refresht ***/
if( com.ibm.xsp.ajax.AjaxUtil.isAjaxPartialRefresh(facesContext) === true ){
   var rId = com.ibm.xsp.ajax.AjaxUtil.getAjaxComponentId( facesContext  );
   if( rId !== clientId )
	return viewScope.get( "fixData-" + clientId );
}


/*** Mehrfach-Berechnung abfangen ***/
if( requestScope.containsKey("fixData-" + clientId ) == true ){
	value = viewScope.get( "fixData-" + clientId );
}else{
	value = calculate();
	viewScope.put( "fixData-" + clientId, value );
	requestScope.put("fixData-" + clientId , true );
}

value

Sven

[Sven Hasselbach]

@m3:
So einfach ist es in meinen Augen leider nicht.

Erstens handelt es sich hierbei nicht um einen, sondern um zwei Bugs (Der Eine ist die Ausführung bei Partial Refreshs, der Andere ist die Mehrfachberechnung).

Zweitens sind das nicht "simple" Bugs (wie z.B. sowas hier: http://hasselba.ch/blog/?p=563),  die natürlich immer mal wieder passieren. Sondern es wurden hier extreme Bugs vorgelegt, die an der gesamten Qualität des Produktes "XPage" zweifeln lassen.

Drittens ist der Vergleich mit den "kleinen Startups" aber genau das Problem, denn warum sollte ich ein Produkt wie XPages einsetzen, wenn es Alternativen am Markt gibt? Siehe dazu die Ausführungen von David Marko: http://blog.tcl-digitrade.com/blogs/tcl-digitrade-blog.nsf/dx/21.02.2012114147DMAEK8.htm.

Und Viertens: Wenn die IBM den Code nicht im Griff hat, warum legt sie Ihn dann nicht einfach für die Community offen? Es würde das Verständnis für die Arbeitsweise von XPages deutlich erhöhen, und auch würde sich die Entwicklung von AddOns (z.B. von OSGi-Komponenten) deutlich einfacher gestallten.

Ich persönlich mag XPages, ich mache jetzt schon eine ganze Weile nichts anderes mehr, aber wenn ich mir anschaue, was die IBM mit dem Produkt macht, könnte ich heulen...

Just my two cents
Sven