Posts Tagged: ‘bug’

Quick-n-Dirty: Hotfix for DateTimeHelper

12. Juni 2017 Posted by Sven Hasselbach

This weekend I stumbled over a bug of the DateTimeHelper: If the value of the field is empty, no actions and/or action listeners connected with a managed bean will be executed anymore.

Here is an example of a small XPage to illustrate the problem:

<?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
 
    <xp:label 
        value="#{javascript:java.lang.System.currentTimeMillis()}" id="labelNow" />

     <xp:inputText id="inputTextDT" value="#{myBean.valueDT}">
         <xp:this.converter>
             <xp:convertDateTime type="date" />
         </xp:this.converter>
         <xp:dateTimeHelper />
     </xp:inputText>

    <xp:button id="button" value="OK">
        <xp:eventHandler
            event="onclick"
            submit="true"
            refreshMode="partial"
            refreshId="labelNow"
            actionListener="#{myBean.action}" />
     </xp:button>

</xp:view>

It does not matter if you set the disableValidators property for the text field to true, even an immediate=true won’t help here. The reason for the problem is that the renderer of the dateTimeHelper always uses the attached converter and fails with a null pointer exception if the value is empty (this infringes the JSF specification, but IBM has implemented it this way).

The workaround for this problem is to overwrite the existing renderer class and handle the NPE by yourself:

package ch.hasselba.xpages.renderer;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.ConverterException;
public class DateTimeHelperRenderer
    extends com.ibm.xsp.renderkit.dojo.DateTimeHelperRenderer{

    public Object getConvertedValue(FacesContext fc, UIComponent uiComponent, Object obj)
        throws ConverterException  {

          Object result = super.getConvertedValue(fc, uiComponent, obj);

          if( result == null )
            return new Object();

          return result;
    }
}

The renderer must now be registered in faces-config.xml:

<?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
<faces-config>
  <render-kit>
    <renderer>
      <component-family>javax.faces.Input</component-family>
      <renderer-type>com.ibm.xsp.DateTimeHelper</renderer-type>
      <renderer-class>ch.hasselba.xpages.renderer.DateTimeHelperRenderer</renderer-class>
    </renderer>
  </render-kit>
</faces-config>

Now the problem is solved, the managed bean’s action get executed even if the value is empty.

How To Crash a Domino Server in 500ms

21. Februar 2016 Posted by Sven Hasselbach

How To Crash a Domino Server in 500ms

1. Create a Java agent and do something in your finally routine (or in a ThreadDeath exception handling) which runs longer than 500ms

import lotus.domino.AgentBase;

public class JavaAgent extends AgentBase {

    public void NotesMain() {
        try {
            int i = 0;
            while (i < 1000) {
                i++;
                System.out.println("Round " + i);
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {}
            }
        } finally {
            try {
                Thread.sleep(1000);
            } catch (Exception e) {}
        }
    }
}

2. Run the agent on the server

2016-02-20 11_31_17-SH Domain - Dev01_Hasselba_CH - IBM Domino Administrator1

3. Quit the Agent Manager

2016-02-20 11_31_17-SH Domain - Dev01_Hasselba_CH - IBM Domino Administrator2

4. And then restart it

2016-02-20 11_31_17-SH Domain - Dev01_Hasselba_CH - IBM Domino Administrator3

5. Enjoy the silence

2016-02-20 11_31_17-SH Domain - Dev01_Hasselba_CH - IBM Domino Administrator4

Fun fact: This works well in a IBM Notes Client too! Just start the agent and cancel it a few times (<CTRL> + <BREAK>).

Interim Fix 1 für IBM Domino 9.0.1 FP4 verhindert Crash des Servers

14. Juli 2015 Posted by Torben Busch

 

IBM hat einen Bug im Domino Server 9.0.1 FP 4 gefunden, der den Server aufgrund einer fehlenden Datei abstürzen lassen kann. Das Interim Fix 1 behebt diesen Fehler und wird heute oder morgen in das Fix Pack 4 für die Version mit aufgenommen.

Wenn ihr also schon das FP4 für die Version 9.0.1 des Domino Servers installiert habt, solltet ihr euch 9.0.1 Fix Pack 4 Interim Fix 1 herunterladen und installieren:

Fix List und Download Optionen

Wenn ihr das noch nicht getan habt, könnt ihr ab dem 16. Juli einfach das Fix Pack 4 herunterladen und installieren, welches den Bug Fix dann bereits enthalten sollte. 

 

Yii Framework: Security Fix for Version 1.1.14

1. Juli 2014 Posted by Sven Hasselbach

A security fix for the Yii framework was released on 29th June: http://www.yiiframework.com/news/78/yii-1-1-15-is-released-security-fix/

The issue only affects the CDetailView component of Version 1.1.14, and can be upgraded safely without breaking existing code.

iNotes still shows old design after upgrading mailfiles with german mailtemplate to version 9.0

30. September 2013 Posted by Stephan Kopp

This bug is well known since the release of Domino 9 language packs, but I still can’t find a new download with a fixed mailtemplate version…

Currently many customers in Germany are upgrading to version 9 and may now getting into trouble because of this issue. So I post again this solution found in the IBM Forum, but with a little bit different coding.

The problem:
After upgrading a Domino server to version 9.0, your users might also want to use a german mailtemplate with version 9 features. That’s not a big deal, just put the german mailtemplate to your server and upgrade the maildatabase design. But this DOES NOT work for iNotes, users will still see the old version 8.5 iNotes!

The reason:
There is a hidden field in the database icon called “$FormsTemplateFile”, which provides the filename of the Forms.nsf to be used within iNotes. This Field should contain “iNotes/Forms9.nsf” to use the new version of iNotes, but sadly it contains “iNotes/Forms85.nsf”.

The solution:
The fastes solution is to delete the Forms85.nsf from your server and immediatelly all  users will see the new and very nice iNotes.

But in many cases, you don’t want to upgrade the userinterface of iNotes for all users without providing them also the new client and new mailtemplate. That’s why you should fix the bug in the german mailtemplate. Then you can provide your users a broad upgrade of all userinterfaces in one step (Notes Client, Mailtemplate + iNotes).

1. Step: Download my tool and open it

2. Step: Open the tool, press the button and apply the fix to your template

3. Step: Put the template to your server (sign it if necessary)

4. Step: Test the new template and then use it during your upgrade

DISCLAIMER: Techniques and code provided here are not guaranteed or warranted in any way and are free for you to use at your own risk


Filed under: IBM Notes/Domino

Desktop-Einstellungen werden unerwartet an ältere Clients verteilt

4. Juli 2013 Posted by Oliver Regelmann

Wer in einer nicht-englischen Domino-8.5.3-Umgebung noch Clients älter als 8.0 betreibt (die …ähem… gar nicht mehr supportet werden), sollte sich diese Technote anschauen:

IBM Unexpected desktop settings applied to User Preferences after policy document re-save – United States

Offenbar kann es dazu kommen, dass diese Clients Desktop-Einstellungen verpasst kriegen, die ihnen nicht zugeordnet werden. Den Fix kann man selbst in der pubnames.tf ausführen.

Irgendwie lässt mich der Eindruck nicht los, dass das Übersetzungsteam für Notes 9 entweder geschlafen hat oder eine zu kurze Deadline für die Qualitätssicherung bekam. Neben diesem haben wir ja noch diverse weitere Schablonenfehler:

assonos blog :: Vorsicht: Deutsche Notes 9-Mail-Schablone hat gleiche Replik-ID wie die von 8.5.3 (Update: noch mehr Schablonen betroffen)

IBM LO75258: IF SWIFTFILE IS INSTALLED, CLOSING ANY MAIL FILE GIVES ERROR MES SAGE FOR NON ENGLISH MAIL TEMPLATES. – United States

IBM Notes and Domino 9.0 Social Edition Forum – Wrong $FormsTemplateFile in german mail9.ntf

That’s not me!

12. September 2012 Posted by Sven Hasselbach

Hey! That’s not me on CollaborationToday.info!

That’s me:

http://www.gravatar.com/avatar/e3383e9bf66559af149b4b91e2f8787c?s=128&d=identicon&r=PG

Security: Another XSS Vulnerability in Domino

11. September 2012 Posted by Sven Hasselbach

Stephan Wissel wrote about a XSS vulnerabilty for Domino servers (< 8.5.4) and in his post you will get an advise how to protect your domino server against this attack. Thanks for this! Works great!

But there is still a problem with another URL pattern:

*/xsp/.ibmmodres/*

This resolves resources from databases, that’s why it only works in a database URL. But normally domcgf.nsf is reachable from outside.

Update:

The blog post was updated on wissel.net. Please update your server configuration!

Stolperfalle: “Cycle reference” in Serverside Javascript

24. März 2012 Posted by airwolf89

Mal wieder eine Stolperfalle.

Wochenenden sind doch etwas wunderbares um seine Zeit mit Xpages zu verschwenden =)

Ich war dabei ein bisschen Code zu testen und zum laufen zu bringen. Konkret ging es um ein paar Java Klassen mit ein paar netten Funktionen, auf welche ich von Java und Serverside Javascript aus zugreifen wollte. Daher habe ich dann noch 2 Scriptlibraries geschrieben welche diese Funktionen nutzen können.

Code lief so gesehen eigentlich wunderbar, wenn da nicht diese nervigen OutOfMemoryExceptions gewesen wären…

Nach einigem testen (8 wertvolle Stunden meines Lebens mittlerweile), bin ich dann auf die Lösung bzw. die Ursache des Problem gekommen.

Gegenseitige Referenzierung (Cycle references klingt irgendwie viel cooler =) ) von Scriptlibraries mag Notes scheinbar gar nicht.

Die eine Scriptlibrary war ein Logging Tool, das andere ein Tool um auf meine Konfigurationsdokumente zugreifen zu können. Leider kam ich auf die Idee in der Konfigurationslibrary mein Logging Tool zu verwenden und im Logging Tool die Log Datenbank aus Konfigurationsdokumenten zu laden. Diese Konstruktion war scheinbar schon vorher zum Scheitern verurteilt, denn selbst printouts im Einstiegspunkt der Libraries wurden nicht ausgegeben. Dann bin ich auf die Idee gekommen zu testen ob vielleicht die gegnseitige Refrenzierung der Grund war.

Ich schrieb mir 2 Libraries, jeweils nur mit einer Funktion welche ein Printout enthielten. Beide haben sich gegenseitig referenziert. In einer Test-Xpage habe ich dann nur eine der Libraries geladen. Sonst nichts. Kein weiterer Code, keine Funktionsaufrufe, kein gar nichts.  Auch hier erhielt ich schon die OutOfMemoryExceptions. Scheinbar verträgt Notes das gar nicht. Ob das nun ein Bug (oder normales Verhalten) in XPages oder im Javaumfeld ist weiß ich nicht. Auf jeden Fall war mir dies noch nicht bekannt, im Netz habe ich dazu auch noch nichts gefunden, und hoffe dem einen oder anderen damit vielleicht ein paar Stunden Debugging erspart zu haben.

Als Lösung versuche ich nun eine Wrapperklasse zu schreiben, welche die Libraries verwendet und somit das Problem behebt. Mal schauen obs funktioniert.

Übrigens, im XPages Forum habe ich auch noch ein anderes Phänomen gepostet, auf welches ich während meiner Debugging Orgie gestoßen bin. Hat hiermit zwar nichts zu tun, aber es geht um eine der hier verwendeten Scriptlibraries.

XPages Forum – Disappearing notesDatabase reference in Java under 8.5.3

Kurze Zusammenfassung: Im verwendeten Javacode verschwand nach dem ersten (fehlerfreien) Aufruf der Funktion die Referenz auf die aktuelle Datenbank. Keine Ahnung warum. Sobald dort etwas gepostet wurde werde ich das auch hier rein stellen.


Einsortiert unter:Notes & XPages, Stolperfallen Tagged: Attribute, Bug, Cycle reference, gegenseitige Referenzierung, Java, libraries, Notes, OutOfMemoryException, Scriptlibrary, Serverside Javascript, Stolperfalle, XPages

Bug: facesContext.getRenderResponse()

11. März 2012 Posted by Sven Hasselbach

Eigentlich sollte die Methode  getRenderResponse() true zurück liefern, wenn der Code in der Render Response-Phase ausgeführt wird, doch leider ist die Funktion nicht korrekt implementiert. So liefert die Funktion bei einem normalen Seitenaufruf falsche Ergebnisse, bei einem Partial Refresh hingegen funktioniert sie jedoch wie sie soll.

Zur Erläuterung verwende ich folgende XPage:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">

   <xp:label value="Label" id="label1">
      <xp:this.rendered>
         <![CDATA[#{javascript:
            if( facesContext.getRenderResponse() ){
               print( "Render Response!" );
            }else{
               print( "NOT Render Response!" );
            }
            return true}]]>
      </xp:this.rendered>
   </xp:label>

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

Öffnet man die XPage im Browser, wird auf der Serverkonsole folgendes ausgegeben:

Bei einem Partial Refresh hingegen wird die Phase korrekt erkannt:

Domino 8.5.3 Installation schlägt fehl (Java Virtual Maschine defekt)

29. Februar 2012 Posted by Henning von Roon

Vor kurzem ist uns ein Problem bei der Installation von Lotus Domino 8.5.3 aufgefallen. 

Nachdem die Domino 8.5.3 Installation durchgeführt worden ist, um einen Domino 8.5.2 Server anzuheben, konnte der Domino-Server seinen HTTP-Task nicht mehr starten. In den Logs wurden wir schnell fündig und konnten feststellen, dass der HTTP-Task nicht startet, da die JVM (Java Virtual Maschine) nicht ordnungsgemäß funktioniert. 

Nach einer kurzen Suche in Google, stellte sich heraus, dass eine erneut Installation (ohne zuvor etwas zu deinstallieren) das Problem behebt. Dies konnten wir erfolgreich nachstellen. Der Domino-Server konnte ordnungsgemäß gestartet werden (einschließlich des HTTP-Tasks). 

Sollten Sie dieses Problem beobachten, versuchen sie zunächst die Installation des Domino-Servers erneut auszuführen. 

Nachtrag: Die Installation wurde auf einem Windows Server 2008 (64 Bit) durchgeführt. 

Bug: Invalider Java-Code durch berechnete Tag-Attribute

17. Februar 2012 Posted by Sven Hasselbach

António A Ramos hat einen interessanten Bug entdeckt: Werden die Attribute eines HTML-Tags im Designer berechnet, wird die XPage nicht mehr verarbeitet und ein Internal Server Error tritt auf

So wird der folgende HTML-Tag ordnungsgemäß gerendert…

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
   <li data-theme="e"></li>
</xp:view>

… jedoch ist eine Berechung nicht zulässig:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
   <li data-theme="#{javascript:'e'}"></li>
</xp:view>

Der Grund ist dabei die Umsetzung in den Java-Code, denn dieser verwendet das Attribute ungeprüft als Variablenname – was natürlich fehl schlagen muss.

So sieht der generierte Java-Code aus:

Ein Workaround ist, den generierten Java-Code direkt im Designer zu ändern und fehlerhafte Variablendeklaration von Hand zu bereinigen – allerdings muss der Vorgang nach jedem Build wiederholt werden.

“It’s not a feature, it’s a bug!”

10. Februar 2012 Posted by Sven Hasselbach

In meinem letzten Beitrag habe ich einen Bug entdeckt, den ich an dieser Stelle noch etwas ausführlicher darstellen möchte, denn es handelt sich hierbei nicht um ein normales Verhalten von JSF, sondern schlichtweg um einen Bug während der Transformation nach Java.

Im Vorfeld möchte ich jedoch auf einen sehr guten Artikel von Paul Withers aufmerksam machen, in dem ausführlich dargestellt wird, wie es sein müsste:

http://www.intec.co.uk/xpages-bindings-when-runs-at-page-load/

Der Einfachheit halber greife ich das von Paul gegebene Beispiel auf, um den Bug zu verdeutlichen. Ergänzt man nämlich den Code um Anführungszeichen, dann wird der “On Page Load“-Code nicht mehr ausgeführt:

<xp:text id="computedField2" escape="true"
 value="You are logged in as '${javascript:@UserName()}'.
The fields id is #{id:computedField1}"></xp:text>

[Fett: Der "On Page Load"-Code // In Rot: Die zusätzlichen Anführungszeichen]

Das Ergebnis ist dann folgendes:

Zurückzuführen ist das auf einen Fehler bei der Transformierung, der generierte Javacode sieht wie folgt aus:

Dies ist ein Bug im Designer, denn jedwede Form der ${}-Syntax wird ungeprüft als “On Page Load” interpretiert. So wird der folgende Code trotz Fehler in EL übersetzt…

… hingegen wird diese Variante ordnungsgemäß als Fehler markiert und lässt sich nicht speichern:

Irrtümlicherweise habe ich in meinem vorigen Artikel weitere Beispiele aufgeführt, die Code enthalten, der ohne das Anführungszeichen ausgeführt wird. Dies war im Zuge des Schreiben des letzten Artikels, als ich noch weitere Test gemacht habe. Hier ist das Verhalten natürlich JSF-konform und der Code wird ordnungsgemäß ausgeführt.

Meine Beobachtung bezüglich der fehlerhaften Transformation jedoch bezieht sich nicht nur auf Output Scripts, sondern um jede Art des Value Bindings: Sobald eine x-beliebige Kombination von ${} (auch über mehrere Zeilen etc.) vorkommt, tritt der Fehler auf.

Bug: ${} in Output Script-Blöcken

8. Februar 2012 Posted by Sven Hasselbach

Bei der Verwendung eines Output Scripts muss darauf geachtet werden, dass kein Code verwendet wird, der eine Zeichenfolge beinhaltet, die eine “Compute On Load“-ähnliche Syntax hat: Ein Bug sorgt dafür, das bei der Verwendung von ${} (mit oder ohne Inhalt) einiges durcheinander gerät, und der komplette SSJS-Code falsch verarbeitet wird.

So gibt folgender Code wie zu erwarten eine Messagebox mit der Id des Labels aus…

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">

   <xp:label value="Label" id="label1"></xp:label>
   
   <xp:scriptBlock id="scriptBlock1">
      <xp:this.value>
         <![CDATA[$
            var id = '#{id:label1}';
            alert( id );
         ]]>
      </xp:this.value>
   </xp:scriptBlock>
   
</xp:view>

… wird aber an irgendeiner Stelle im Script Block die genannte Kombination verwendet, gerät alles in Schieflage:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">

   <xp:label value="Label" id="label1"></xp:label>
   
   <xp:scriptBlock id="scriptBlock1">
      <xp:this.value>
         <![CDATA[
            var id = '#{id:label1}';
            var bug = '${id:label1}';
             alert( "id: " + id + "\nbug: " + bug);
         ]]>
      </xp:this.value>
   </xp:scriptBlock>
   
</xp:view>

Die Variable id ist leer, und die Variable bug wird nicht verändert:

Es spielt keine Rolle an, welcher Stelle im Script Block die fehlerhafte Variante vorkommt, auch der Inhalt zwischen den eckigen Klammern ist unbedeutent: Ein auskommentierter Code über mehrer Zeilen hat die gleiche Auswirkung!

Varianten wie z.B.

//var bug = '${
// Kein Text!
//}';

oder

var bug = ${X}

werfen keine Fehler, sondern generieren im besten Fall “nur” fehlerhaften CSJS-Code.

Erst wenn keine Anführungszeichen verwendet werden und die EL-Syntax fehlerhaft ist, tritt ein Laufzeitfehler auf.

var bug = ${/EL}

 

Der Bug existiert in 8.5.2 als auch in 8.5.3. Andere Versionen können ebenfalls betroffen sein.

Security: Domino Server Backdoor

7. Januar 2012 Posted by Sven Hasselbach

Mit XPages lässt sich ein Domino Server auf einfachste Weise lahm legen, da man über die Java Runtime beliebige Threads starten kann.

Ein kleiner Button startet z.B. Notepad auf einem Windows Domino Server:

<xp:button value="Start NotePad!" id="buttonStartNotePad">
   <xp:eventHandler event="onclick" submit="true"
      refreshMode="norefresh">
      <xp:this.action>
         <![CDATA[#{javascript:
            java.lang.Runtime.getRuntime().exec("notepad");}]]>
      </xp:this.action>
   </xp:eventHandler>
</xp:button>

 

Bei jedem Klick wird auf dem Domino Server einmal Notepad gestartet. Eine kleine Schleife, und auch ein großzügig dimensionierter Server geht in die Knie.

Richtig übel wird es allerdings, wenn dieser Button geklickt wird:

ACHTUNG! NICHT AUF PRODUKTIVEN SYSTEMEN AUSFÜHREN!

<xp:button value="KILL NOTES!" id="buttonKillNotes">
   <xp:eventHandler event="onclick" submit="true"
      refreshMode="norefresh">
      <xp:this.action>
         <![CDATA[#{javascript:
            java.lang.Runtime.getRuntime().exec("nsd -kill");}]]>
         </xp:this.action>
      </xp:eventHandler>
</xp:button>

Dann ist der Domino Server weg!

Bei dem “zerlegten” Server handelt es sich um eine Standard-Installation. Die java.policy wurde nicht geändert.