[
https://issues.apache.org/jira/browse/CLK-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Schellink resolved CLK-703.
-------------------------------
Resolution: Won't Fix
I've spent some time creating a lazy class loading scheme using various
approaches. Couldn't find an easy way which preserved the simplicity and
performance of ConfigService. I'm sure with enough time and effort the
performance and locking issues could be resolved, however the complexity goes
up drastically when dealing with multiple threads. This is especially true for
services dependent on page class metadata such as SpringClickServlet. Under an
eager loading scheme, SpringClickServlet can cache page class metadata (ie page
setters) during the Servlet init() event without concern for synchronization.
Under a lazy loading scheme, metadata has to be obtained at runtime, pushing
synchronization handling onto this class. Not something I'd like to face.
My main motivation for this change was to address an issue with Google App
Engine where it doesn't allow Click to lookup template files under the root
("/") web folder. However it seems that GAE does allow looking up resources
under subfolders of root. By introducing a convention where pages are located
under the 'page' or 'pages' folder, we can again support automapping in
production environments, albeit with a small caveat.
> Load pages and templates on demand
> ----------------------------------
>
> Key: CLK-703
> URL: https://issues.apache.org/jira/browse/CLK-703
> Project: Click
> Issue Type: Improvement
> Components: core
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Fix For: 2.3.0-M1
>
>
> At startup time Click eagerly loads templates (and associated page classes)
> found under the web folder.
> The proposed change is to switch to a lazy loading scheme where pages and
> templates are only loaded when requested. Scenarios needed to be catered for
> include:
> - HTTP Request
> - Page.setRedirect
> - Page.setForward
> There is also an outstanding bug which depends on this proposal:
> https://issues.apache.org/jira/browse/CLK-639
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
