Debug_AutoPop=2
Debug_AutoPop=2
Debug_AutoPop=2
Debug_AutoPop=2
A really interesting article about running your own servlets on domino server can be found here: http://www.ibm.com/developerworks/cn/lotus/xpage-servlet/index.html
It’s chinese, but you can translate f.e. with Google’s Translator.
With 8.5.3 I had have some problems because the required interface IServletFactory could not be resolved in DDE.
To get the example running, you have to add a JAR to your build path. Open Project properties, select “Java Build Path” and click “Add External JARs“:
Now you have to add the file “lwpd.domino.adapter.jar“. This can be found in the following folder:
<NOTES>\framework\shared\eclipse\plugins\com.ibm.domino.xsp.adapter_<VERSION>
The <VERSION> string depends on your current installation and Server-Version.
After adding this JAR to the build path, the compilation problems should be resolved.
After reading a question on stack overflow about setting an own HTTP expires header and the problem that an additional header is generated automatically, I made some tests how the domino server can be forced to stop this behaviour programmatically.
During my tests I was able to stop it by using facesContext.responseComplete() but this works only for “headless” XPages (set rendered to false). If you are calling the method in a normal XPage (set rendered to true), the generated output will be discarded and looks like the “headless” version.
Here are two examples including screenshots from firebug console (containing the HTTP response):
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
<xp:this.beforeRenderResponse>
<![CDATA[#{javascript:
var ec = facesContext.getExternalContext();
var response = ec.getResponse();
var writer = response.getWriter();
// set headers
var now = new Date();
response.setDateHeader("Expires",
now.getTime() + (60*60*1000));
response.setHeader("Cache-Control", "public");
// Output it
writer.write( now.getTime().toString() );
}]]>
</xp:this.beforeRenderResponse>
<xp:label value="Test!" id="label1"></xp:label>
</xp:view>
As you can see here, the output from the writer was added to the XPage first (the output will be added before the <HTML>-Tag and causes invalid HTML, but this can be ignored in this demo):
The response contains two HTTP expires header. The -1 is added after the programmatically generated one.
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
<xp:this.afterRenderResponse>
<![CDATA[#{javascript:
var ec = facesContext.getExternalContext();
var response = ec.getResponse();
var writer = response.getWriter();
// set headers
var now = new Date();
response.setDateHeader("Expires",
now.getTime() + (60*60*1000));
response.setHeader("Cache-Control", "public");
// Output it
writer.write( now.getTime().toString() );
}]]>
</xp:this.afterRenderResponse>
<xp:label value="Test!" id="label1"></xp:label>
</xp:view>
In this scenario, the output is added after the HTML code.
The HTTP expires header was added first.
After some research, I was able to remove the header programmatically:
First, you have to create a new java class which implements com.ibm.xsp.context.RequestParameters.ResponseCacheHeader.
package ch.hasselba.jsf.core;
import javax.servlet.http.HttpServletResponse;
import com.ibm.xsp.context.RequestParameters.ResponseCacheHeader;
public class SHResponseCacheHeader implements ResponseCacheHeader {
public SHResponseCacheHeader(){}
public boolean initResponseCacheHeader(HttpServletResponse arg0){
return true;
}
}
It is required that the initResponseCacheHeader() method returns true, otherwise this won’t work!
Then, you have to add the responseCacheHeader object to the requestParameters of facesContext:
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" rendered="false">
<xp:this.beforePageLoad>
<![CDATA[#{javascript:
importPackage( ch.hasselba.jsf.core );
var ec = facesContext.getExternalContext();
var response = ec.getResponse();
var writer = response.getWriter();
// set headers
var now = new Date();
response.setDateHeader("Expires",
now.getTime() + (60*60*1000));
response.setHeader("Cache-Control", "public");
// set response cache header object
var reqParam = facesContext.getRequestParameters();
var resCH = new SHResponseCacheHeader();
reqParam.setResponseCacheHeader( resCH );
// Output it
writer.write( now.getTime().toString() );
}]]>
</xp:this.beforePageLoad>
<xp:label value="Test!" id="label1"></xp:label>
</xp:view>
The output will be generated as expected, but the useless HTTP expires header won’t be added anymore:
With the assistance of Philippe Riand I was able to shorten the original idea of canceling a partial refresh to a single SSJS function. By setting the HTTP header “X-XspRefreshId” to “@none” it is possible to get the same result as in the posting before, but there is no “Dojo hack” required.
function cancelPartialRefresh(){
var response = facesContext.getExternalContext()
.getResponse();
response.setHeader("X-XspRefreshId", "@none");
response.reset();
response.commitResponse();
facesContext.responseComplete();
}
To use this function you just have to call it. Here is the same example like in the previous posting:
<?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="label1">
</xp:eventHandler>
</xp:button>
<xp:br/><xp:br/>
<xp:label id="label1">
<xp:this.value>
<![CDATA[#{javascript:
function cancelPartialRefresh(){
var response = facesContext.getExternalContext()
.getResponse();
response.setHeader("X-XspRefreshId", "@none");
response.reset();
response.commitResponse();
facesContext.responseComplete();
}
var ajax = new com.ibm.xsp.ajax.AjaxUtil();
if( ajax.isAjaxPartialRefresh(facesContext) == true){
cancelPartialRefresh();
return; // stop execution of SSJS code
}
java.lang.System.currentTimeMillis();}]]>
</xp:this.value>
</xp:label>
</xp:view>
I have added the code to the XSnippet Contest. Here is the link to the XSnippet: http://openntf.org/XSnippets.nsf/snippet.xsp?id=cancel-partial-refresh
If you want to read more information about the HTTP header you can read an earlier posting (Sorry, on german only).
After reading Tim Tripcony’s blog post , I thought about a way how to cancel a partial refresh via server side javascript. To bring this to life, there are just three things to do:
To stop the processing of a request on the server and to send an empty response to the client, this SSJS code can be used:
var response = facesContext.getExternalContext().getResponse(); response.reset(); response.commitResponse();
The client will receive an empty HTTP response body:
A HTTP Header has to be added to the response to inform Dojo that the request was canceled. In this example it is “X-Partial-Refresh-Cancel“:
response.setHeader("X-Partial-Refresh-Cancel", "1");
The header is now added to the HTTP response and sent back to the client:
The XHR response must be hijacked before it is processed by Dojo. To do this, a new XHR function has to be injected between the existing one. Here is a basic code snippet:
var xhrLoad = null; // placeholder for the original function
if( !dojo._xhr )
dojo._xhr = dojo.xhr;
dojo.xhr = function(){
var args = arguments[1];
xhrLoad = args["load"]; // "save" the original load function
// and overwrite with a new one
args["load"] = function( a, ioArgs ){
// execute custom code
// call the original load function:
xhrLoad( a, ioArgs );
}
// do XHR request
dojo._xhr( arguments[0], arguments[1], arguments[2] );
}
The load function of a Dojo XHR request has a parameter ioArgs. This parameter gives a handle to an object that allows to access the HTTP response headers, so the response can be identified as canceled:
var canceled = ioArgs.xhr &&
ioArgs.xhr.getResponseHeader("X-Partial-Refresh-Cancel");
if( canceled ){
XSP.allowSubmit();
return;
}
If the HTTP header is set, the processing of the request can be stopped. After stopping the request, the XSP object is not allowed to fire the next event. To allow this again, the function XSP.allowSubmit() must be called.
Here is a demonstration XPage with a button and a label. The partial refresh will never be processed, instead a “Canceled” message will occur.
<?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="label1">
</xp:eventHandler>
</xp:button>
<xp:br/><xp:br/>
<xp:label id="label1">
<xp:this.value>
<![CDATA[#{javascript:
var response = facesContext.getExternalContext().getResponse();
var ajax = new com.ibm.xsp.ajax.AjaxUtil();
if( ajax.isAjaxPartialRefresh(facesContext) == true){
response.setHeader("X-Partial-Refresh-Cancel", "1");
response.reset();
response.commitResponse();
return;
}
java.lang.System.currentTimeMillis();}]]>
</xp:this.value>
</xp:label>
<xp:br/>
<xp:br/>
<xp:scriptBlock id="scriptBlockXHRHandler">
<xp:this.value><![CDATA[
var xhrLoad = null;
dojo.addOnLoad( function(){
if( !dojo._xhr )
dojo._xhr = dojo.xhr;
dojo.xhr = function(){
try{
var args = arguments[1];
xhrLoad = args["load"];
args["load"] = function( a, ioArgs ){
var canceled = ioArgs.xhr &&
ioArgs.xhr.getResponseHeader("X-Partial-Refresh-Cancel");
if( canceled ){
alert("Canceled!");
XSP.allowSubmit();
return;
}
xhrLoad( a, ioArgs );
}
}catch(e){}
dojo._xhr( arguments[0], arguments[1], arguments[2] );
}
});]]>
</xp:this.value>
</xp:scriptBlock>
</xp:view>
I have submitted some XSnippets for the XSnippets-Contest. This is the first one, the XPages Localization Setter: The Snippet allows to change the language settings of a XPage “On-The-Fly”, including the browser language used, the dojo settings, the ressource files etc.
package ch.hasselba.xpages.jsf.core;
import javax.faces.context.FacesContext;
import javax.faces.application.Application;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import javax.faces.component.UIViewRoot;
import java.util.Locale;
import java.util.Map;
public class LocalizationSetter implements PhaseListener {
private static final long serialVersionUID = -1L;
private static final String scopeVarName = "Language";
private static final String scopeName = "sessionScope";
public void afterPhase(PhaseEvent event) {}
public void beforePhase(PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
UIViewRoot view = facesContext.getViewRoot();
view.setLocale( getLanguage(facesContext) ) ;
}
public PhaseId getPhaseId() {
return PhaseId.RENDER_RESPONSE;
}
private Locale getLanguage( FacesContext facesContext ){
try{
Application app = facesContext.getApplication();
Object obj = app.getVariableResolver()
.resolveVariable(facesContext, scopeName );
Object lang = ((Map) obj).get( scopeVarName );
if( lang != null ){
return new Locale((String) lang);
}
}catch(Exception e){}
return Locale.getDefault();
}
}
This phase listener updates the language settings of the UIViewRoot-Element during the rendering of the response. The language the XPage will be set to is stored in a session scope variable named “Language”. If you want to change this you just have to change the variable scopeVarName to fit your requirements.
To activate the phase listener in your XPages-Application you have to alter the faces-config.xml:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config>
<lifecycle>
<phase-listener>
ch.hasselba.xpages.jsf.core.LocalizationSetter
</phase-listener>
</lifecycle>
</faces-config>
Here is a simple example to demonstrate the XSnippet:
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
<xp:comboBox id="comboBox1" value="#{sessionScope.Language}">
<xp:selectItem itemLabel="Chinese" itemValue="zh" />
<xp:selectItem itemLabel="German" itemValue="de" />
<xp:selectItem itemLabel="Turkish" itemValue="tr" />
<xp:eventHandler event="onchange" submit="true"
refreshMode="complete" />
</xp:comboBox>
</xp:view>
If you are choosing “turkish” from the combobox, the html source looks like this after the refresh:
If you are add a simple date picker to your XPage and change the language to chinese, the dojo dialog will be in chinese from now on:
To add more languages you have to use the two letter ISO 639 code. To get a list of all available locales you can use this small repeat control:
<xp:repeat id="repeat1" rows="999" var="locale">
<xp:this.value>
<![CDATA[#{javascript:
java.text.SimpleDateFormat.getAvailableLocales();
}]]>
</xp:this.value>
<xp:label id="label1">
<xp:this.value>
<![CDATA[#{javascript:
locale.getDisplayName() + " -> " + locale.toString()
}]]>
</xp:this.value>
</xp:label>
<xp:br/>
</xp:repeat>
Note:
After changing the language a full refresh is required!
sc delete "Lotus Domino Server"
C:\IBM\Lotus\Domino\ntsvinst.exe -d -t"Lotus Domino Server"
sc create "Lotus Domino Server Controller (java console)" binpath"C:\IBM\Lotus\Domino\nservice.exe =C:\IBM\Lotus\Domino\notes.ini -jc -c" displayname= "Lotus Domino Server Controller (java console)"
C:\IBM\Lotus\Domino\jconsole.exe
"C:\Program Files (x86)\IBM\Lotus\Notes\jconsole.exe"
sc delete "Lotus Domino Server"
C:\IBM\Lotus\Domino\ntsvinst.exe -d -t"Lotus Domino Server"
sc create "Lotus Domino Server Controller (java console)" binpath"C:\IBM\Lotus\Domino\nservice.exe =C:\IBM\Lotus\Domino\notes.ini -jc -c" displayname= "Lotus Domino Server Controller (java console)"
C:\IBM\Lotus\Domino\jconsole.exe
"C:\Program Files (x86)\IBM\Lotus\Notes\jconsole.exe"
sc delete "Lotus Domino Server"
C:\IBM\Lotus\Domino\ntsvinst.exe -d -t"Lotus Domino Server"
sc create "Lotus Domino Server Controller (java console)" binpath"C:\IBM\Lotus\Domino\nservice.exe =C:\IBM\Lotus\Domino\notes.ini -jc -c" displayname= "Lotus Domino Server Controller (java console)"
C:\IBM\Lotus\Domino\jconsole.exe
"C:\Program Files (x86)\IBM\Lotus\Notes\jconsole.exe"
sc delete "Lotus Domino Server"
C:\IBM\Lotus\Domino\ntsvinst.exe -d -t"Lotus Domino Server"
sc create "Lotus Domino Server Controller (java console)" binpath"C:\IBM\Lotus\Domino\nservice.exe =C:\IBM\Lotus\Domino\notes.ini -jc -c" displayname= "Lotus Domino Server Controller (java console)"
C:\IBM\Lotus\Domino\jconsole.exe
"C:\Program Files (x86)\IBM\Lotus\Notes\jconsole.exe"
Aus einer XPages-Applikation lässt sich der XSP Command Manager (das zugrundeliegende OSGi Framework) fernsteuern. Das Kommando entspricht dem Befehl
tell http xsp <BEFEHL>
auf der Domino Serverkonsole, nur dass hierfür kein Serverkonsolenzugriff benötigt wird.
Mit Hilfe der folgenden XPage lassen sich beliebige OSGi-Kommandos absetzen, also z.B. Prozesse starten, Bundles installieren (egal von welcher Quelle, auch aus dem Internet) und vieles mehr.
<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
<xp:button value="Send XSP Command" id="button2">
<xp:eventHandler
event="onclick"
submit="true"
refreshMode="complete">
<xp:this.action><![CDATA[#{javascript:
var cmd = getComponent("inputTextXSPCmd").value;
if( cmd == null || cmd == "")
return;
var xcm = com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.getInstance();
xcm.tell( cmd );}]]>
</xp:this.action>
</xp:eventHandler>
</xp:button>
<xp:inputText id="inputTextXSPCmd" />
</xp:view>
Die Seite sieht wie folgt aus:
Beim Klicken auf “Send XSP Command” kann man das Ergebnis auf der Serverkonsole sehen:
Hier ein kleiner Auszug über mögliche Kommandos:
Auch Heap-, System, und Java-Dumps lassen sich hierdurch erstellen.
Analog zu den ViewDataSources lassen sich auch DocumentDataSources über die Adresszeile des Browsers manipulieren: Der URL-Parameter databaseName ermöglicht hierbei die Steuerung der zugrundliegenden Datenbank, und überschreibt einen eventuell in der XPage hinterlegten Wert.
<?xml version="1.0" encoding="UTF-8"?> <xp:view xmlns:xp="http://www.ibm.com/xsp/core"> <xp:this.data> <xp:dominoDocument var="document1" databaseName="DB1.nsf"> </xp:dominoDocument> </xp:this.data> <xp:button value="Label" id="button1"> <xp:eventHandler event="onclick" submit="true" refreshMode="complete"> <xp:this.action> <xp:save></xp:save> </xp:this.action> </xp:eventHandler> </xp:button> </xp:view>
Wird diese XPage mit dem Parameter databaseName=DB2.nsf aufgerufen und abgeschickt bzw. gespeichert, erfolgt das Anlegen des Dokumentes nicht wie definiert in der DB1.nsf, sondern in DB2.nsf.
Ebenso verhält es sich, wenn ein Dokument geöffnet wird: Auch hierbei lässt sich steuern, aus welcher Datenbank das Dokument stammten soll (in diesem Fall nur, solange keine documentId in der XPage eingestellt ist.)
Werden mehrere DataSources auf einer XPage verwendet, werden die URL-Parameter dort angewendet, “wo es passt”, d.h. es wird die nächste DataSource (View oder Document) verwendet, die nicht mit ignoreRequestParam=”true” abgesichert wurde.