[
https://issues.apache.org/jira/browse/WW-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136164#comment-18136164
]
Lukasz Lenart commented on WW-4147:
-----------------------------------
Closing as Won't Fix, for two reasons.
*The hook already exists.* As found in the second comment,
{{StrutsPrepareAndExecuteFilter}} (and {{StrutsPrepareFilter}}) has a protected
{{postInit(Dispatcher, FilterConfig)}} method that runs once the Dispatcher is
initialised. Overriding it warms FreeMarker up without any injection workaround:
{code:java}public class WarmFreemarkerFilter extends
StrutsPrepareAndExecuteFilter {
@Override
protected void postInit(Dispatcher dispatcher, FilterConfig filterConfig) {
dispatcher.getContainer()
.getInstance(FreemarkerManager.class)
.getConfiguration(filterConfig.getServletContext());
}
}
{code}
If you'd rather not subclass the filter,
{{DispatcherListener.dispatcherInitialized(Dispatcher)}} gives the same access.
*It shouldn't be the default.*
[WW-5690|https://issues.apache.org/jira/browse/WW-5690] deliberately took
FreeMarker off the startup path, so an application that never renders
FreeMarker no longer pays to configure it. That's part of the lean-core work in
[WW-5689|https://issues.apache.org/jira/browse/WW-5689]. Initialising it
eagerly by default would undo that. The hooks above leave the choice with each
application.
Also note that this only builds the {{Configuration}}. Theme templates are
still parsed the first time they're used. To warm those too, load them in the
same {{postInit}} override with {{configuration.getTemplate(...)}}.
> Have StrutsPrepareAndExecuteFilter initialize Freemarker rather than first
> actual Request
> -----------------------------------------------------------------------------------------
>
> Key: WW-4147
> URL: https://issues.apache.org/jira/browse/WW-4147
> Project: Struts 2
> Issue Type: Improvement
> Components: Other
> Affects Versions: 2.3.15.1
> Reporter: Jasper Rosenberg
> Priority: Minor
> Labels: freemarker, performance, startup
> Fix For: 7.5.0
>
>
> Currently, the first request to the web app triggers getting the Freemarker
> Configuration, which causes it to be built for the first time.
> Depending on circumstances, this might be a bit slow. It would be nice if
> when struts was coming up, it forced Freemarker initialization before it the
> server was declared ready to accept requests.
> The way I hacked around this was to extend StrutsPrepareAndExecuteFilter so
> that in init(FilterConfig), I get the current FreemarkerManager, and call
> .getConfiguration(filterConfig.getServletContext()) on it.
> As an aside, it was surprisingly difficult to get the Container to use to
> inject the FreemarkerManager instance in StrutsPrepareAndExecuteFilter. I'm
> guessing I'm just missing something.
> I recognize not all struts apps are using freemarker, which is probably why
> it inits lazily, but it would be great to have an easy hook, and
> StrutsPrepareAndExecuteFilter is the obvious place since you have access to
> the ServletContext.
> {code:java}
> private FreemarkerManager freemarkerManager;
> /**
> * Override to initialize freemarker hooks proactively.
> */
> @Override
> public void init(final FilterConfig filterConfig) throws ServletException
> {
> super.init(filterConfig);
> // Inject the freemarker manager
> prepare.assignDispatcherToThread();
> try {
> Dispatcher.getInstance().getContainer().inject(this);
> } finally {
> Dispatcher.setInstance(null);
> }
>
> // Force initialization of the freemarker configuration
> freemarkerManager.getConfiguration(filterConfig.getServletContext());
> }
> @Inject
> public void setFreemarkerManager(FreemarkerManager freemarkerManager) {
> this.freemarkerManager = freemarkerManager;
> }
> {code}
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
