Eureka Moment session

1. Eureka! The Padawan's Guide to
the Dark Side of XPages
#uklugEureka
Presenter: Paul Withers
Company: Intec Systems Ltd
Twitter: @paulswithers
Presenter: Tim Tripcony
Company: GBS
Twitter @timtripcony

2. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material (*B1)

3. Paul Withers
• Senior Domino Developer, Intec Systems Ltd
• XPages Developer since 8.5.0
• IBM Champion
• Co-Host of The XCast
• XPages Extension Library Book

4. Tim Tripcony
• XMage, GBS
• IBM Champion
• XPages Extension Library Book

5. 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

6. Ex pectations
• You should:
• Know what XPages are
• Know that XPages run on a Domino server
• Know Computed Field, Edit Box and Repeat controls
• You don't need to:
• Know Java
• Have a thorough knowledge of JSF
• Have knowledge of dataContexts, managed beans,
PhaseListeners or VariableResolvers

7. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material

8. XPages and Domino Server
Java Virtual Machine
XSP Command Manager
Domino HTTP Server

9. When An XPage Is Served...(*B3)
• Can HTTP Server resolve the URL to an NSF?
• HTTP 404 Error
• Does user have access to NSF?
• HTTP Authentication Page
• Can HTTP Server find resource in the NSF?
• HTTP 404 Error
• Does the signer have access to run XPages? (*B3)
• HTTP 403 Error
• Are there SSJS errors?
• XSP Command Manager takes over (*B1-B2)
• Return XPage

10. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material

11. Java Virtual Machine Means...
• Each NSF is a separate Java application
• applicationScope, sessionScope etc. is per NSF (*B4)
• 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

12. JAVA Virtual Machine
• XPages → Java classes → Java bytecode (*B5-B7)
• 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

13. XPages Languages
• Literal values
• Strings, booleans etc.
• SSJS
• #{javascript:document1.getItemValueString(“FirstName”)}
• Expression Language (*B8)
• #{VARIABLE.PROPERTY}
• #{document1.FirstName}
• #{database.title} = #{javascript:database.getTitle()}
• Custom
• Any of the above combined
• “Database title is #{database.title}”

14. Language Hypotheses
• Fewer controls should perform better (*B9)
• Literal strings should perform best. Expression Language
should perform better than Server-Side JavaScript
• Combining languages should allow:
• Fewer controls to be used
• Literal Strings and Expression Language to be used
instead of SSJS
• So better performance

15. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material

16. 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
• Objects stored in ViewScope etc must also be
serializable

17. Server-Side Map

18. 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

19. Persistence Tab

20. Demo

21. Persistence Summary
• Keep Pages in Memory
• Remembering, remembering, remembering
• xsp.persistence.mode=basic
• Best for...quick retrieval, few users
• Keep Pages on Disk
• Writing...next? You want it again? Reading
• xsp.persistence.mode=file
• Best for...lots of users, but slower retrieval
• Keep Only The Current Page In Memory
• Remembering, remembering, remembering
• Oh, new page? Writing...and now
• Remembering, remembering, remembering
• xsp.persistence.mode=fileex
• Best for...lots of users, quick retrieval of current page

22. Persistence Summary (*B11-13)
• Gzip Persisted Files
• xsp.persistence.file.gzip (default=false)
• default=false
• Writing...next? You want it again? Reading
• Persist Files Asynchronously
• xsp.persistence.file.async (default=true)
• Server busy, remembering. Next? (Writing, writing)
• Maximum Pages...
• xsp.persistence.tree.maxviews (*B10)
• Remembering, remembering, remembering
• xsp.persistence.file.maxviews
• Writing, retrieving, writing, writing

23. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material

24. JSF LifeCycle

25. 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

26. Six Phases
• 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

27. PhaseListener
• Must implement javax.faces.event.PhaseListener
• Or extend a Java class that implements it
• ExamplePhaseListener extends AbstractPhaseListener, which
implements javax.faces.event.PhaseListener
• Allows us to track JSF lifecycle phases
• Java class plus reference in WebContentWEB-
INFfaces-config.xml

28. Demo

29. Basic
• Validation fails
• beforeRestoreView
• afterRestoreView
• beforeApplyRequestValues
• afterApplyRequestValues
• beforeProcessValidations
• beforeRenderResponse
• afterRenderResponse
• Event logic not run

30. 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

31. im mediate="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

32. Custom Validator (SSJS)
• 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)

33. Custom Validator (Java)
• 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

34. Custom 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

35. JSF Lifecycle
• Now you understand validation and JSF lifecycle
• But validation prevents SSJS running
• So how can you show / hide buttons based on this
• *B14

36. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material

37. What Are We Testing?
• Computed Field control with value property computed
• Two Edit Box controls with rendered property
computed
• For each scenario:
• On Page Load – how many calls
• On Partial Refresh – how many calls (*B15)

38. What Are The Scenarios?
• Compute on Page Load (Loaded)
• Compute Dynamically (Runtime)
• Theme
• dataContexts
• “Global variables”
• Scoped to XPage, Custom Control, Panel
• Referenced via EL – #{var1}
• execMode=“partial”
• Runs over only part of component tree

39. Demo

40. Smackdown Results
• Loaded makes fewer calls
• Theme cannot override loaded (*B16)
• Runtime and theme makes same calls
• dataContext makes fewer calls (*B17)
• execMode=“partial” improves performance
• IMPORTANT: Define id to execute lifecycle on
EventHandler – All Properties
• Know what you're processing and what you're refreshing
(*B18)

41. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material

42. Summary
• Scoped variables not cleared by ?logout
• Combining controls improves performance – big takeaway
• Persistence options can optimise application
• JSF lifecycle affects event processing
• loaded and dataContexts (for rendered) offer benefits
• execMode improves performance – huge takeaway
• But things get REALLY interesting when you look at
performance of different languages for a rendered property in
our repeat... (*B19-B20) – massive takeaway

43. Statistics – Combining Controls

44. Statistics – Lifecycle Sm ackdown

45. Thank You
• Paul Withers, Intec Systems Ltd
• Email: pwithers@intec.co.uk
• Twitter: paulswithers
• Blog: http://www.intec.co.uk/blog
• Tim Tripcony, GBS
• Email:
• Twitter: timtripcony
• Blog: http://timtripcony.com
Please complete your evaluations
and check out the 20 bonus slides

46. Agenda
• Introduction
• XPages Server Processing
• JVM and the NSF
• Memory Management
• JSF Lifecycle: Event Model
• JSF Lifecycle: Performance Smackdown
• Summary
• Bonus Material

47. B1 - HTTP Error 500 Reasons
• No server / custom error page defined
• Falls back to $$ReturnGeneralError page, if available
• 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

48. B2 – Resolving HTTP 500 Errors
• XPages Log File Reader from OpenNTF allows you to view
server-based log files
• If this points to a Java class you've added to the database,
make sure it hasn't “fallen out” of the Build Path
• If it's in the Build Path, is it trying to write to the file system.
Could be prevented by java.policy security settings

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

50. B4 – “ServerScope”
• XSP Starter Kit contains an example of managed
beans that can be scoped to the server
• Good for multi-NSF applications
• Instead of managed bean server-scoped variables
could be a Map set / got from OSGi VariableResolver
• Application-based / server-based VariableResolvers
are processed for EVERY variable referenced in
XPages applications
• Includes e.g. context, sessionAsSigner, database
• Also includes var attributes of data, dataContexts
etc, e.g. document1

51. B5 – XPages Java Bytecode
• Editing is done in XPage / Custom Control design elements
• Build process (B5) creates .java
files, visible in Package Explorer

52. B6 XPages Java Bytecode
• These are compiled down to
.class files, which are only visible
in Project Explorer view
• Window → Show Eclipse Views → Other
• Start typing “Proj” and select Project Explorer
• Customize the view, clear all filters
and click OK
• Right-click the pane to load contents
• Java class files are visible under
WebContent WEB-INF classes
• Includes custom Java classes,
XPages, Custom Controls

53. B7 – Manual Build
• Build Automatically
• Builds any NSF when opened in Designer
• Builds any open NSF (even in “hidden” Working Sets)
when any design element is saved
• Has “broken” live applications when developer opened an
NSF in Designer just to look at design and did not have
access to run XPages code on the server
Switch it off!!
• When opening an NSF in Designer
• An initial build is required to create local Java files
• If no initial build has been done and a design element is
changed, the first build just does an incremental build
If you open an NSF in Designer and make a change,
you need to build TWICE to see changes in the browser

54. B8 – Language Caveat
• Expression Language (on its own or within Custom language)
can only be used in component attributes
• Value property
• Rendered property
• Loaded property
• It cannot be used in eventHandlers
• In Client you need to use
alert(“#{javascript:database.getTitle()}”) instead of
alert(“#{database.title}”)

55. B9 – Controls Investigation
• Look at the following pages under Bonus
• HTML vs XSP
• “Pass-thru HTML” on an XPage still creates a control in the
Java code
• Dojo Slider
• Ext Lib Slider
• Ext Lib controls exist to make it easier for developers
• They do not exist to enhance server-performance per se
• But some Ext Lib controls lazy-load functionality

56. B10 – Persistence: Save to Disk
• xsp.persistence.tree.maxviews only applies when
xsp.persistence.mode=basic
• Save to disk defaults to server temp directory, e.g.
C:WindowsTempnotes270C3Exspstate2D8YWSWLP34
• Ensure relevant drive has enough space for scalability
• Default folder can be overridden using
xsp.persistence.dir.xspstate
• Similar options for file uploads and attachments

57. B11 – Page persistence m ode
• xsp.persistence.viewstate=fulltree
• Default option, whole component tree persisted
• xsp.persistence.viewstate=nostate
• No component tree is stored, similar to
xsp.session.transient=true
• xsp.persistence.viewstate=delta
• Valid if pages stored in memory
• Only stores changes since page first loaded
• xsp.persistence.viewstate=deltaex
• Valid if multiple pages stored in memory
• Stores full component tree for current page, deltas for
others

58. B12 – x sp.session.transient
• xsp.session.transient=“false”
• XPage becomes stateless
• Default VALUES overridden between requests
• Default STATES not overridden
• 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

59. B13 – x sp.session.transient
• To see it in action, use the Teamroom database
• Check out normal dataView functionality
• Expand All / Collapse All, Sorting etc toggles
• Filter functionality works
• Categories can be expanded
• Detail can be expanded
• Set xsp.session.transient=true and build the app
• Check out dataView functionality now
• Sorting doesn't toggle, just switches relative to default
• Filter functionality doesn't work
• Categories cannot be expanded
• Detail can still be expanded, but only because dataView
has detailsOnClient=true

60. B14 – Manipulating JSF Lifecycle
• See Bonus – Check Values / Submit
• Scenario
• You want to display a button that says “Check
Values” until all values are completed
• Then you want to display a “Save” button
• But if the user then removes the value from a
required field, you want to display “Check Values”
button
• RenderResponse always runs, so do the checks
in the rendered property

61. B15 – Computing Refresh ID
• refreshId property can be computed
• How is this calculated during the JSF lifecycle?
• Bonus – Computed refreshId tests this
• The refreshId gets calculated during the
renderResponse phase

62. B16 – Themes and Loaded
• Bonus – Theme Failing page in sample database
• Themes cannot override a property that is Computed on
Page Load
• Bonus – Theme Failing Repeat
• Themes can set most properties on a control
• E.g. value property of a repeat control
• Required at page load time to create component tree

63. B17 – dataContex ts for value
• dataContexts can offer benefits for rendered property
• How do they perform when used for value property?
• Bonus – dataContext for Value demonstrates this
• Even though dataContext is overridden by theme, it is
calculated several times during the lifecycle

64. B18 – ex ecMode Goes Wrong
• execMode and execId are very powerful
• Be carefuly about execId and refreshId
• Bonus – execMode demonstrates this
• execId defines which control values get passed to
component tree
• refreshId defines which area gets updated on browser
• If refreshId is larger than execId, controls outside
execId will lose their values

65. B19 - Repeats Revisited
• See Bonus – Language Performance + Rendered
• rendered property set for each of 50000 rows
• rendered property set in different ways
• SSJS in Script Library performs worst
• SL much worse on partial refresh
• VariableResolver best for performance
• Deprecated in JSF 2.0 for ELResolver
• VariableResolver in OSGi plugin best for performance
and reusability (check out XSP Starter Kit)
• dataContext next best, but only reusable within page

66. B20 – Comparisons
If you're separating business logic from
presentation, Java is the way to go