[
https://issues.apache.org/jira/browse/WW-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5689:
------------------------------
Description:
h2. Goal
Reduce {{struts2-core}} to routing, dispatch, the OGNL value stack and the
interceptor/result machinery. View technologies become opt-in plugins, so a
REST/JSON-only application carries no JSP, no tag library and no FreeMarker.
The default assembly still bundles all three, so the out-of-the-box
distribution is unchanged for existing users — this is Ted Husted's "omnibus
jar" answer from the original 2007 dev@ thread.
Supersedes WW-2278 (closed Won't Fix — "move the tags into a plugin" is not the
change anyone would make today; see the triage comment there for the evidence).
Blocked by WW-4759. Its governing constraint applies here unchanged: OSGi
{{Export-Package}} and the JPMS direction forbid split packages, so every
module cut must be whole-package with FQCNs preserved, and the
API/implementation de-mixing has to land first.
h2. What "FreeMarker becomes optional" does and does not mean
The tag library is _fully_ dependent on FreeMarker and stays that way:
{{struts.ui.templateSuffix}} defaults to {{ftl}} and all 129 bundled theme
templates are {{.ftl}}. Splitting the tags out does not change that, and is not
meant to — an application using the tags pulls in {{struts2-tags-plugin}},
which depends on {{struts2-freemarker-plugin}}.
The benefit is for the application that renders no tags at all. Today it still
carries FreeMarker because _core itself_ uses it for three convenience pages.
Remove those and FreeMarker becomes a transitive dependency of the view plugins
rather than of core.
h2. Proposed modules
* {{struts2-freemarker-plugin}} — {{org.apache.struts2.views.freemarker}}
(FreemarkerManager, FreemarkerResult, FreemarkerThemeTemplateLoader),
{{components.template.FreemarkerTemplateEngine}}, and the FTL theme templates
* {{struts2-tags-plugin}} — {{org.apache.struts2.components}},
{{org.apache.struts2.views.jsp}} plus the generated
{{META-INF/struts-tags.tld}}, {{org.apache.struts2.views.annotations}}; depends
on a template engine plugin
* {{struts2-jsp-plugin}} — {{components.template.JspTemplateEngine}},
{{JspSupportServlet}}, JSP-side template support
The tags/JSP boundary is genuinely fuzzy and needs a design decision rather
than an assumption: the tag components are useless without some template engine
behind them.
h2. Core's own FreeMarker use: three convenience pages
None of these needs the module split to land first.
# {{DefaultDispatcherErrorHandler}}, the dev-mode problem report — WW-5690
(7.4.0) took the template load off the startup path; WW-5693 (8.0.0) removes
the dependency.
# WW-5691 (8.0.0) — {{ExecuteAndWaitInterceptor}} instantiates
{{FreemarkerResult}} for the fallback wait page.
# WW-5692 (8.0.0) — {{DebuggingInterceptor}}, resolved by moving it into its
own plugin rather than rewriting its templates.
WW-5691 and WW-5693 are paired: both delete an internal-but-overridable
template and share one migration-guide entry. They also share a trap —
{{FreemarkerManager}} sets {{HTMLOutputFormat}} with
{{ENABLE_IF_DEFAULT_AUTO_ESCAPING_POLICY}}, so these templates are HTML-escaped
today by configuration. A hand-written renderer loses that and must escape
deliberately.
WW-5692 deliberately avoids that trap by moving the templates rather than
replacing them. It carries its own open question instead: {{debugging}} is
referenced from *{{defaultStack}}* in {{struts-default.xml}}, and a plugin
cannot take that reference with it.
h2. Still unfiled, and dependent on WW-4759
# Core extension points currently living in view packages must move to
core-owned packages (WW-4759 step (i)): {{components.UrlRenderer}},
{{views.util.UrlHelper}}, {{components.date.DateFormatter}},
{{components.template.TemplateEngine}} and {{TemplateEngineManager}},
{{components.Component}}.
# {{StrutsBeanSelectionProvider}} and {{struts-beans.xml}} hard-register nine
view beans. Those registrations move into each plugin's {{struts-plugin.xml}}.
h2. Compatibility
FQCNs preserved throughout; {{struts2-core}} must never depend on a plugin.
Seven existing plugins import these packages and will need dependency updates:
javatemplates, velocity, jasperreports7, jasperreports, tiles, convention,
config-browser.
h2. Scope note
Major structural change, targeted for Struts 8.0.0, sequenced after WW-4759.
was:
h2. Goal
Reduce {{struts2-core}} to routing, dispatch, the OGNL value stack and the
interceptor/result machinery. View technologies become opt-in plugins, so a
REST/JSON-only application carries no JSP, no tag library and no FreeMarker.
The default assembly still bundles all three, so the out-of-the-box
distribution is unchanged for existing users — this is Ted Husted's "omnibus
jar" answer from the original 2007 dev@ thread.
Supersedes WW-2278 (closed Won't Fix — "move the tags into a plugin" is not the
change anyone would make today; see the triage comment there for the evidence).
Blocked by WW-4759. Its governing constraint applies here unchanged: OSGi
{{Export-Package}} and the JPMS direction forbid split packages, so every
module cut must be whole-package with FQCNs preserved, and the
API/implementation de-mixing has to land first.
h2. What "FreeMarker becomes optional" does and does not mean
The tag library is _fully_ dependent on FreeMarker and stays that way:
{{struts.ui.templateSuffix}} defaults to {{ftl}} and all 129 bundled theme
templates are {{.ftl}}. Splitting the tags out does not change that, and is not
meant to — an application using the tags pulls in {{struts2-tags-plugin}},
which depends on {{struts2-freemarker-plugin}}.
The benefit is for the application that renders no tags at all. Today it still
carries FreeMarker because _core itself_ uses it for three convenience pages.
Remove those and FreeMarker becomes a transitive dependency of the view plugins
rather than of core.
h2. Proposed modules
* {{struts2-freemarker-plugin}} — {{org.apache.struts2.views.freemarker}}
(FreemarkerManager, FreemarkerResult, FreemarkerThemeTemplateLoader),
{{components.template.FreemarkerTemplateEngine}}, and the FTL theme templates
* {{struts2-tags-plugin}} — {{org.apache.struts2.components}},
{{org.apache.struts2.views.jsp}} plus the generated
{{META-INF/struts-tags.tld}}, {{org.apache.struts2.views.annotations}}; depends
on a template engine plugin
* {{struts2-jsp-plugin}} — {{components.template.JspTemplateEngine}},
{{JspSupportServlet}}, JSP-side template support
The tags/JSP boundary is genuinely fuzzy and needs a design decision rather
than an assumption: the tag components are useless without some template engine
behind them.
h2. Core decoupling that must happen first
Core's own FreeMarker use is three convenience pages, none of which needs the
module split to land:
# {{DefaultDispatcherErrorHandler}} — the dev-mode problem report. WW-5690
(7.4.0) deferred the template load off the startup path; WW-5693 (8.0.0)
removes the dependency.
# WW-5691 (8.0.0) — {{ExecuteAndWaitInterceptor}} instantiates
{{FreemarkerResult}} for the fallback wait page.
# WW-5692 — {{DebuggingInterceptor}} instantiates {{FreemarkerResult}} for its
console and browser diagnostic pages.
WW-5691 and WW-5693 are paired in 8.0.0: both delete an
internal-but-overridable template and share one migration-guide entry. They
also share a trap — {{FreemarkerManager}} sets {{HTMLOutputFormat}} with
{{ENABLE_IF_DEFAULT_AUTO_ESCAPING_POLICY}}, so these templates are HTML-escaped
today by configuration. A hand-written renderer loses that, and must escape
deliberately.
Still unfiled, and dependent on WW-4759:
# Core extension points currently living in view packages must move to
core-owned packages (WW-4759 step (i)): {{components.UrlRenderer}},
{{views.util.UrlHelper}}, {{components.date.DateFormatter}},
{{components.template.TemplateEngine}} and {{TemplateEngineManager}},
{{components.Component}}.
# {{StrutsBeanSelectionProvider}} and {{struts-beans.xml}} hard-register nine
view beans. Those registrations move into each plugin's {{struts-plugin.xml}}.
h2. Compatibility
FQCNs preserved throughout; {{struts2-core}} must never depend on a plugin.
Seven existing plugins import these packages and will need dependency updates:
javatemplates, velocity, jasperreports7, jasperreports, tiles, convention,
config-browser.
h2. Scope note
Major structural change, targeted for Struts 8.0.0, sequenced after WW-4759.
> Lean core: extract FreeMarker, tag library and JSP support into dedicated
> plugins
> ---------------------------------------------------------------------------------
>
> Key: WW-5689
> URL: https://issues.apache.org/jira/browse/WW-5689
> Project: Struts 2
> Issue Type: Task
> Components: Core
> Reporter: Lukasz Lenart
> Priority: Major
> Fix For: 8.0.0
>
>
> h2. Goal
> Reduce {{struts2-core}} to routing, dispatch, the OGNL value stack and the
> interceptor/result machinery. View technologies become opt-in plugins, so a
> REST/JSON-only application carries no JSP, no tag library and no FreeMarker.
> The default assembly still bundles all three, so the out-of-the-box
> distribution is unchanged for existing users — this is Ted Husted's "omnibus
> jar" answer from the original 2007 dev@ thread.
> Supersedes WW-2278 (closed Won't Fix — "move the tags into a plugin" is not
> the change anyone would make today; see the triage comment there for the
> evidence).
> Blocked by WW-4759. Its governing constraint applies here unchanged: OSGi
> {{Export-Package}} and the JPMS direction forbid split packages, so every
> module cut must be whole-package with FQCNs preserved, and the
> API/implementation de-mixing has to land first.
> h2. What "FreeMarker becomes optional" does and does not mean
> The tag library is _fully_ dependent on FreeMarker and stays that way:
> {{struts.ui.templateSuffix}} defaults to {{ftl}} and all 129 bundled theme
> templates are {{.ftl}}. Splitting the tags out does not change that, and is
> not meant to — an application using the tags pulls in
> {{struts2-tags-plugin}}, which depends on {{struts2-freemarker-plugin}}.
> The benefit is for the application that renders no tags at all. Today it
> still carries FreeMarker because _core itself_ uses it for three convenience
> pages. Remove those and FreeMarker becomes a transitive dependency of the
> view plugins rather than of core.
> h2. Proposed modules
> * {{struts2-freemarker-plugin}} — {{org.apache.struts2.views.freemarker}}
> (FreemarkerManager, FreemarkerResult, FreemarkerThemeTemplateLoader),
> {{components.template.FreemarkerTemplateEngine}}, and the FTL theme templates
> * {{struts2-tags-plugin}} — {{org.apache.struts2.components}},
> {{org.apache.struts2.views.jsp}} plus the generated
> {{META-INF/struts-tags.tld}}, {{org.apache.struts2.views.annotations}};
> depends on a template engine plugin
> * {{struts2-jsp-plugin}} — {{components.template.JspTemplateEngine}},
> {{JspSupportServlet}}, JSP-side template support
> The tags/JSP boundary is genuinely fuzzy and needs a design decision rather
> than an assumption: the tag components are useless without some template
> engine behind them.
> h2. Core's own FreeMarker use: three convenience pages
> None of these needs the module split to land first.
> # {{DefaultDispatcherErrorHandler}}, the dev-mode problem report — WW-5690
> (7.4.0) took the template load off the startup path; WW-5693 (8.0.0) removes
> the dependency.
> # WW-5691 (8.0.0) — {{ExecuteAndWaitInterceptor}} instantiates
> {{FreemarkerResult}} for the fallback wait page.
> # WW-5692 (8.0.0) — {{DebuggingInterceptor}}, resolved by moving it into its
> own plugin rather than rewriting its templates.
> WW-5691 and WW-5693 are paired: both delete an internal-but-overridable
> template and share one migration-guide entry. They also share a trap —
> {{FreemarkerManager}} sets {{HTMLOutputFormat}} with
> {{ENABLE_IF_DEFAULT_AUTO_ESCAPING_POLICY}}, so these templates are
> HTML-escaped today by configuration. A hand-written renderer loses that and
> must escape deliberately.
> WW-5692 deliberately avoids that trap by moving the templates rather than
> replacing them. It carries its own open question instead: {{debugging}} is
> referenced from *{{defaultStack}}* in {{struts-default.xml}}, and a plugin
> cannot take that reference with it.
> h2. Still unfiled, and dependent on WW-4759
> # Core extension points currently living in view packages must move to
> core-owned packages (WW-4759 step (i)): {{components.UrlRenderer}},
> {{views.util.UrlHelper}}, {{components.date.DateFormatter}},
> {{components.template.TemplateEngine}} and {{TemplateEngineManager}},
> {{components.Component}}.
> # {{StrutsBeanSelectionProvider}} and {{struts-beans.xml}} hard-register nine
> view beans. Those registrations move into each plugin's {{struts-plugin.xml}}.
> h2. Compatibility
> FQCNs preserved throughout; {{struts2-core}} must never depend on a plugin.
> Seven existing plugins import these packages and will need dependency
> updates: javatemplates, velocity, jasperreports7, jasperreports, tiles,
> convention, config-browser.
> h2. Scope note
> Major structural change, targeted for Struts 8.0.0, sequenced after WW-4759.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
