[
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 decoupling that must happen first
Each is independently reviewable and shippable in 7.x, ahead of any module
move. Filed separately:
# WW-5690 — {{DefaultDispatcherErrorHandler}} renders the dev-mode error page
through FreemarkerManager, and initialises it unconditionally at startup even
in production.
# WW-5691 — {{ExecuteAndWaitInterceptor}} instantiates {{FreemarkerResult}} for
the fallback wait page.
# WW-5692 — {{DebuggingInterceptor}} instantiates {{FreemarkerResult}} for its
console and browser diagnostic pages.
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. 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}}
* {{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
Each of these is independently reviewable and can land in 7.x ahead of the
module split. Together they are what actually makes FreeMarker optional —
core's own dependency on it is three convenience pages.
# {{DefaultDispatcherErrorHandler}} renders the dev-mode error page through
FreemarkerManager. It needs a template-free default.
# {{ExecuteAndWaitInterceptor}} defaults to FreemarkerResult for the wait page.
The default must not hard-reference a view technology.
# {{DebuggingInterceptor}} imports FreemarkerResult and FreemarkerManager. Same
treatment.
# 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 decoupling that must happen first
> Each is independently reviewable and shippable in 7.x, ahead of any module
> move. Filed separately:
> # WW-5690 — {{DefaultDispatcherErrorHandler}} renders the dev-mode error page
> through FreemarkerManager, and initialises it unconditionally at startup even
> in production.
> # WW-5691 — {{ExecuteAndWaitInterceptor}} instantiates {{FreemarkerResult}}
> for the fallback wait page.
> # WW-5692 — {{DebuggingInterceptor}} instantiates {{FreemarkerResult}} for
> its console and browser diagnostic pages.
> 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)
