Extended version for DanNotes

1. The Eureka Moment:
XPages Under The Covers
Paul Withers
Intec Systems Limited

2. Agenda
Introduction
XPages Server Processing
JVM and the NSF
Memory Management
JSF Event Model – Lifecycle
JSF Event Model – Performance
Rendered / Language Performance

3. About Me
Senior Domino Developer, Intec Systems Ltd
XPages Developer since 8.5.0
IBM Champion
Co-Host of The XCast
Co-Author of XPages Extension Library book

4. Why This Session?
Nothing in life is to be feared, it is only to be understood. Now
is the time to understand more, so that we may fear less.
Marie Curie
A matter that becomes clear ceases to concern us.
Friedrich Nietzsche
Furious activity is no substitute for understanding.
H.H. Williams
No. I am your father. Darth Vader

5. Why This Session?
XPages vs Domino HTTP
Language Performance
Language Roadmap and Justification
Persistence options
Which setting for which application
JSF Lifecycle – understand page processing
Partial refresh – beyond event defaults

6. Expectations
You should:
Know what XPages are
Know that XPages runs on a Domino Server
Know the Computed Field, Edit Box, Repeat controls
You don't:
Have a thorough understanding of JSF
Have expert knowledge of dataContexts, managed
beans, PhaseListeners and VariableResolvers

7. To Download Sample App
Source code at
http://projects.qtzar.com/projects/jsf_eureka
Source control with Git
Download and install eGit from OpenNTF
Create new project from source code
http://git.qtzar.com/jsf_eureka.git/
Associate with new NSF

8. Agenda
Introduction
XPages Server Processing
JVM and the NSF
Memory Management
JSF Event Model – Lifecycle
JSF Event Model – Performance
Rendered / Language Performance

9. Server Architecture
Java Virtual Machine
XSP Command Manager
Domino HTTP Server

10. So When an XPage Is Served...
Can HTTP Server resolve the URL?
HTTP 404 Error
Does user have access to NSF?
HTTP Authentication Page
Can HTTP Server find resource in the NSF?
HTTP 404 Error

11. So When an XPage Is Served...
Does the signer have access to run XPages?
HTTP 403 Error
Are there SSJS errors?
XSP Command Manager takes over
HTTP 500 error*
Return XPage

12. *HTTP Error 500 Reasons
No server / custom error page defined
Missing Extension Library or other library on
server
java.lang.NoClassDefFoundError
java.lang.securityException
Check <domino>dataIBM_TECHNICAL_
SUPPORTxpages_exc_ServerName_yyyy_
MM_dd@hh_mm_ss.log

13. XPiNC
Server-based NSFs need a local XSP
Command Manager etc.
Authentication via Notes logon on local PC
Signer access granted via ECL on local PC
XPages Extensions, Java packages must be
deployed locally
Logging accessible from Help → Support →
View Log on local PC

14. Agenda
Introduction
XPages Server Processing
JVM and the NSF
Memory Management
JSF Event Model – Lifecycle
JSF Event Model – Performance
Rendered / Language Performance

15. Java Virtual Machine Means...
Each NSF is a separate Java application
sessionScope is per NSF
Browser session, NOT user session
Setting sessionScope in Db1.nsf does NOT set
sessionScope in Db2.nsf
sessionScope is ONLY within JVM – not
cleared by HTTP logout

16. DEMO

17. JAVA Virtual Machine
XPages → Java classes → Java bytecode
Each control is a Java class
Extensions are pre-packaged Java classes
Define properties (what can be customised)
Define renderers (what is printed)
SSJS code is String passed to Java method
Java code prints HTML to browser

18. XPages Control Languages
Literal values
Strings, booleans etc
Expression Language
#{document1.FirstName}
SSJS
#{javascript:document1.getItemValueString(“FirstName”)}
Custom
All of the above

19. Hypotheses
How will fewer controls improve performance?
How will different languages affect
performance?
What is the comparison of standard Dojo vs
Extension Library perform?

20. DEMO

21. Performance of Languages
The fewer controls the better
= less Java code to be run
Reason for Extension Library controls
Less Java code in XPages / Custom Controls
Some controls lazy loaded
Combining languages is good
EL is quicker than SSJS

22. Agenda
Introduction
XPages Server Processing
JVM and the NSF
Memory Management
JSF Event Model – Lifecycle
JSF Event Model – Performance
Rendered / Language Performance

23. JSF and Serialization
HTTP is state-less
JSF keeps state-full server representation of
UI (component tree or view)
Objects stored in component tree must be
serializable (persist between requests)
Domino objects recycled after each request
Datasources are recycle-safe

25. Persistence Tab

26. Persistence options
Component tree (map of XPage on server)
either held in memory of JVM
or serialized to disk
xsp.persistence.XXX properties
See persistence tab of new xsp.properties
editor
Package Explorer → WebContentWEB-
INFxsp.properties

27. Demo

28. Persistence Summary
Keep Pages in Memory
Remembering, remembering, remembering
Keep Pages on Disk
Writing...next? You want it again? Reading
Keep Only The Current Page In Memory
Remembering, remembering, remembering
Oh, new page? Writing...and now
Remembering, remembering, remembering

29. Persistence Summary
Gzip Persisted Files
Writing ...next? You want it again? Reading
Persist Files Asynchronously
Server busy, remembering. Next? (Writing, writing)
Maximum Pages...
Remembering, remembering, remembering
Writing, retrieving, writing, writing

30. General Tab

31. General options
Settings available in xsp.properties editor
Application & Session timeouts
XSP Command Manager within HTTP server
Session timeout overridden by HTTP session
timeout
xsp.session.transient=“false”
XPage becomes stateless
Default VALUES overridden between requests
Default STATES not overridden

32. Demo

33. xsp.session.transient
State not persisted
NOT “Go to next page” from current
INSTEAD “Go to next page” from default
NOT “Toggle show detail” from previous state
INSTEAD “Toggle show detail” from default
Values persisted
Great for large, read-only pages – no storage
Need to build your own “relative” functionality

34. Agenda
Introduction
XPages Server Processing
JVM and the NSF
Memory Management
JSF Event Model – Lifecycle
JSF Event Model – Performance
Rendered / Language Performance

35. JSF LifeCycle

36. Six Phases
Restore View
JSF component tree retrieved
Apply Request Values
this.setSubmittedValue(passedValue) run
Any event logic run if immediate=“true”
Process Validation
Any converters applied
Any validators applied

37. Six Phases Continued
Update Model Values
this.setValue(this.getSubmittedValue());
this.setSubmittedValue(null)
Invoke Application
Any event logic run
Render Response
HTML rendered and state saved
Only event that runs during page load

38. AbstractPhaseListener
Abstract because it can't be instantiated
Implements javax.faces.event.PhaseListener
Allows us to track JSF lifecycle phases
Java class plus reference in faces-config

39. DEMO

40. Basic Processing
Validation fails
beforeRestoreView
afterRestoreView
beforeApplyRequestValues
afterApplyRequestValues
beforeProcessValidations
beforeRenderResponse
afterRenderResponse
Event logic not run

41. No Validation
Conversion still honoured
If failed, skips from ProcessValidations to RenderResponse
Event Logic not run
If no conversion errors, all phases run
Values passed from submittedValue to value
Component tree updated

42. immediate=“true”
Validation fails
beforeRestoreView
afterRestoreView
beforeApplyRequestValues
afterApplyRequestValues
beforeRenderResponse
afterRenderResponse
Event logic run in ApplyRequestValues phase
Component value never goes past submittedValue
Component tree not updated

43. DIY SSJS Validators
Runs AFTER Apply Request Values
Runs BEFORE Update Model Values
submittedValue property set
value property still NULL (or last stored value)
Use validator property of control
Check getSubmittedValue()
Post error with facesContext.addMessage()
Abort with this.setValid(false)

44. DIY Validator
Runs at same time as any other validator
Use xp:validator child of validators property of
control
validatorId property maps to validator-id in
faces-config.xml
validator-class maps to Java class

45. DIY Validator – Java Class
Use Java class implementing Validator
javax.faces.validator.Validator
validate(FacesContext,UIComponent,Object)
method performs validation, returns void
Post error using throw ValidatorException
Third argument is submittedValue – String
ValidatorException takes FacesMessage
javax.faces.application.FacesMessage

46. Agenda
Introduction
XPages Server Processing
JVM and the NSF
Memory Management
JSF Event Model – Lifecycle
JSF Event Model – Performance
Rendered / Language Performance

47. Performance Smackdown
Compute on Page Load (Loaded)
Compute Dynamically (Runtime)
Theme
dataContexts
“Global variables”
Scoped to XPage, Custom Control, Panel
Referenced via EL – #{var1}

48. Performance Smackdown
Page Load – how many calls
Partial Refresh – how many calls
execMode=“partial”
Runs over only part of component tree

49. DEMO

50. Smackdown Results
Loaded makes fewer calls
Theme cannot override loaded
Runtime and theme makes same calls
dataContext makes fewer calls
execMode=“partial” improves performance
IMPORTANT: Define id to execute lifecycle on
EventHandler – All Properties

51. Agenda
Introduction
XPages Server Processing
JVM and the NSF
Memory Management
JSF Event Model – Lifecycle
JSF Event Model – Performance
Rendered / Language Performance

52. Bonus – Repeats Revisited
See Bonus – Java Performance + Rendered
rendered property set for each of 50000 rows
SSJS in Script Library performs worst
SL much worse on partial refresh
VariableResolver best for performance
Deprecated in JSF 2.0 for ELResolver
DataContext next best (rendered property), but
only reusable within page

53. Summary
Scoped variables not cleared by ?logout
Combining controls improves performance
Persistence options can optimise application
JSF lifecycle affects event processing
Loaded and dataContexts offer benefits
execMode improves performance

54. Summary
Script libraries work for application reusability
dataContexts better for page reusability
VariableResolver best for application-level
reusability
Upgrade VariableResolver to ELResolver when
XPages updated to JSF 2.0
Use AbstractPhaseListener to test

55. Combining Controls Results

56. Language Lifecycle Results

57. Code Location Results

58. To Download Sample App
Source code at
http://projects.qtzar.com/projects/jsf_eureka
Source control with Git
Download and install eGit from OpenNTF
Create new project from source code
Associate with new NSF

59. Evals, Questions & Contact Details
Paul Withers
email: pwithers@intec.co.uk
twitter: @PaulSWithers
skype: PaulSWithers
blog: http://www.intec.co.uk/blog
YouTube channel: http://www.youtube.com/intecsystems
website: http://www.intec.co.uk