Eureka Moment UKLUG

2,063 views

Published on

Eureka Moment session

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,063
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Eureka Moment UKLUG

  1. 1. Eureka! The Padawans 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. 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. 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. 4. Tim Tripcony• XMage, GBS• IBM Champion• XPages Extension Library Book
  5. 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. 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 dont need to: • Know Java • Have a thorough knowledge of JSF • Have knowledge of dataContexts, managed beans, PhaseListeners or VariableResolvers
  7. 7. Agenda• Introduction• XPages Server Processing• JVM and the NSF• Memory Management• JSF Lifecycle: Event Model• JSF Lifecycle: Performance Smackdown• Summary• Bonus Material
  8. 8. XPages and Domino Server Java Virtual Machine XSP Command Manager Domino HTTP Server
  9. 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. 10. Agenda• Introduction• XPages Server Processing• JVM and the NSF• Memory Management• JSF Lifecycle: Event Model• JSF Lifecycle: Performance Smackdown• Summary• Bonus Material
  11. 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. 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. 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. 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. 15. Agenda• Introduction• XPages Server Processing• JVM and the NSF• Memory Management• JSF Lifecycle: Event Model• JSF Lifecycle: Performance Smackdown• Summary• Bonus Material
  16. 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. 17. Server-Side Map
  18. 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. 19. Persistence Tab
  20. 20. Demo
  21. 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. 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. 23. Agenda• Introduction• XPages Server Processing• JVM and the NSF• Memory Management• JSF Lifecycle: Event Model• JSF Lifecycle: Performance Smackdown• Summary• Bonus Material
  24. 24. JSF LifeCycle
  25. 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. 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. 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. 28. Demo
  29. 29. Basic• Validation fails • beforeRestoreView • afterRestoreView • beforeApplyRequestValues • afterApplyRequestValues • beforeProcessValidations • beforeRenderResponse • afterRenderResponse• Event logic not run
  30. 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. 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. 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. 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. 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. 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. 36. Agenda• Introduction• XPages Server Processing• JVM and the NSF• Memory Management• JSF Lifecycle: Event Model• JSF Lifecycle: Performance Smackdown• Summary• Bonus Material
  37. 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. 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. 39. Demo
  40. 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 youre processing and what youre refreshing (*B18)
  41. 41. Agenda• Introduction• XPages Server Processing• JVM and the NSF• Memory Management• JSF Lifecycle: Event Model• JSF Lifecycle: Performance Smackdown• Summary• Bonus Material
  42. 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. 43. Statistics – Combining Controls
  44. 44. Statistics – Lifecycle Sm ackdown
  45. 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. 46. Agenda• Introduction• XPages Server Processing• JVM and the NSF• Memory Management• JSF Lifecycle: Event Model• JSF Lifecycle: Performance Smackdown• Summary• Bonus Material
  47. 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. 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 youve added to the database, make sure it hasnt “fallen out” of the Build Path• If its in the Build Path, is it trying to write to the file system. Could be prevented by java.policy security settings
  49. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 doesnt toggle, just switches relative to default • Filter functionality doesnt work • Categories cannot be expanded • Detail can still be expanded, but only because dataView has detailsOnClient=true
  60. 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. 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. 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. 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. 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. 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. 66. B20 – Comparisons If youre separating business logic from presentation, Java is the way to go

×