feat(resource-server-utils)!: flip context default; chore: drop dead lib bundles#352
Merged
bjagg merged 4 commits intoMay 9, 2026
Merged
Conversation
…rce-server Problem: ResourcesElementsProvider.DEFAULT_RESOURCE_CONTEXT defaulted to /ResourceServingWebapp — the legacy resource-server context path. That meant <rs:resourceURL>, <rs:aggregatedResources>, and every resource="true" entry in skin descriptors resolved to the legacy overlay by default, forcing every consumer that wanted to migrate to the modern resource-server-webapp 1.5.x overlay to set an explicit <context-param>resourceContextPath=/resource-server</context-param> in their web.xml. None of the 13 consumer webapps in the upstream uPortal-start fleet bother to set that override, so the legacy WAR remains load-bearing even after consumers visually migrate their literal paths. Goal: flip the library default so the modern overlay is the out-of-the-box resolution target. Consumers who deliberately want the legacy context can still pin it via the existing resourceContextPath context-param (no API change). Combined with the standard uPortal-start dual-overlay deployment + Tomcat crossContext=true, this lets the legacy overlay be retired without touching every consumer webapp's web.xml. Goal: BREAKING CHANGE — default behavior shifts from emitting /ResourceServingWebapp/... to /resource-server/... URLs. Should be released as resource-server-utils 2.0 (or at minimum 1.6). Changes: - resource-server-utils/src/main/java/org/jasig/resourceserver/utils/aggr/ResourcesElementsProvider.java: change the DEFAULT_RESOURCE_CONTEXT constant from "/ResourceServingWebapp" to "/resource-server". - resource-server-utils/src/test/java/org/jasig/resourceserver/utils/aggr/ResourcesElementsProviderImplTest.java: update the one expected-output literal that hardcoded the old prefix (testHtmlFragmentWithoutServer's local-fallback expectation is unchanged; only the cross-context case had the literal). The other callsites reference DEFAULT_RESOURCE_CONTEXT as a constant and auto-track the new value. Notes: deployers still on the legacy 1.0.48 ResourceServingWebapp overlay can pin per-webapp via <context-param><param-name>resourceContextPath</param-name> <param-value>/ResourceServingWebapp</param-value></context-param>; documented in the workspace deployer guide. Verified end-to-end against uPortal-start's full Playwright suite + a hand-rolled visual smoke that asserts zero /ResourceServingWebapp/... requests on guest/admin/student layouts. BREAKING CHANGE: DEFAULT_RESOURCE_CONTEXT is now "/resource-server" (was "/ResourceServingWebapp"). Consumers that depend on the legacy default must either deploy a webapp at /ResourceServingWebapp or set the resourceContextPath context-param explicitly.
Problem: resource-server-content's rs/** overlay shipped a kitchen-sink of front-end libraries dating from 2008-2015 (Bootstrap 3.x, CKEditor 3.x + 4.3.2, Apache Fluid Infusion, DataTables 1.9.4, fetch and Promise polyfills, the LESS compiler, lodash 4.17.4). uPortal core and every bundled portlet have either migrated to webjar-based modern equivalents or replaced the lib with a native API; a workspace audit confirmed zero remaining consumers of these directories. The bundle's old versions trip security scanners (BS3 < 3.4.1 and CKEditor 4.x < 4.22 carry XSS CVEs), even though no live page loads them. Goal: shrink the WAR and clear those scanner findings by deleting the consumer-free directories. The remaining rs/** content (tango, famfamfam, modernizr, normalize, fontawesome, jquery-plugins, etc.) still has live consumers and stays for now; future passes will migrate or replace them in turn. Changes: - resource-server-content/src/main/webapp/rs/bootstrap/, rs/bootstrap-namespaced/: delete (Bootstrap 3.x + namespaced variant). uPortal core consumes Bootstrap 5 via webjar. - resource-server-content/src/main/webapp/rs/ckeditor/: delete (CKEditor 3.x + 4.3.2 directories). SimpleContentPortlet now consumes CKEditor 4.22.1 via the org.webjars.npm:ckeditor4 webjar. - resource-server-content/src/main/webapp/rs/datatables/: delete (DataTables 1.9.4). uPortal core consumes DataTables 2.3.x via webjar. - resource-server-content/src/main/webapp/rs/fetch/, rs/promise-polyfill/: delete. Modern browsers have native fetch/Promise; uPortal targets BS5 baseline (no IE). - resource-server-content/src/main/webapp/rs/lesscss/: delete. uPortal core moved to Sass/esbuild for skin compilation. - resource-server-content/src/main/webapp/rs/lodash/: delete. Recent consumer-side commits removed lodash from uPortal-webapp/Search/searchRest.jsp, uPortal-webapp/Invoker/sitemap.jsp, and JasigWidgetPortlets/configLinks.jsp in favor of native ES. Notes: ~7,330 files / 818,604 lines deleted from source. Local resource-server-webapp 1.5.4-SNAPSHOT WAR shrinks ~115 MB → ~84 MB (~30 MB saved). The next resource-server release ships as 1.5.4 and deployers pick up the slimmer WAR transparently. End-to-end verified against uPortal-start's full Playwright suite.
Contributor
|
It looks like this PR needs org.webjars.npm:ckeditor4:4.22.1 added as a dependency, to webapp's pom: |
3 tasks
Problem: resource-server-webapp does not declare the ckeditor4 webjar, so the running resource-server has no CKEditor 4 assets to serve to consumers. SimpleContentPortlet PR #554 needs the asset path available before its CKEditor webjar swap can be verified. Goal: include org.webjars.npm:ckeditor4 in the webapp module so the served context exposes CKEditor 4 from the standard webjars path. Changes: - add org.webjars.npm:ckeditor4:4.22.1 to resource-server-webapp/pom.xml webjar dependencies, alphabetical position between bootstrap and jquery
Brings in: - uPortal-Project#342 update dependency foundation to v6 - uPortal-Project#349 bump parent v49 -> v50 (plexus-archiver CVE fix) Conflict resolution: kept HEAD's deletion of resource-server-content/src/main/webapp/rs/datatables/1.9.4/plugins/integration/foundation/index.html. The entire rs/datatables/1.9.4/ directory is being removed in this branch (see commit 85224df); upstream's uPortal-Project#342 modification to that file is irrelevant since the directory itself is doomed.
Naenyn
approved these changes
May 9, 2026
Contributor
Naenyn
left a comment
Naenyn
left a comment
There was a problem hiding this comment.
Looks good to me after the ckeditor addition. Deployed and tested locally.
ChristianMurphy
approved these changes
May 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
feat!flipResourcesElementsProvider.DEFAULT_RESOURCE_CONTEXTfrom/ResourceServingWebappto/resource-server. BREAKING CHANGE — should ship asresource-server-utils2.0 (or at minimum 1.6). With the standard uPortal-start dual-overlay deployment +crossContext="true", every consumer's<rs:resourceURL>/<rs:aggregatedResources>/resource="true"skin entries instantly start emitting/resource-server/...URLs without any per-webapp<context-param>change. Deployers still on the legacy 1.0.48 WAR can pin viaresourceContextPath=/ResourceServingWebappper-webapp.choredelete eight consumer-free legacy library directories fromresource-server-content/src/main/webapp/rs/:bootstrap(BS3),bootstrap-namespaced,ckeditor(3.x + 4.3.2),datatables(1.9.4),fetch,promise-polyfill,lesscss,lodash(4.17.4). 7,330 files / 818,604 lines deleted; WAR shrinks ~115 MB → ~84 MB.Test plan
mvn -B clean installfrom the parent — all six modules build greenmvn -B test—resource-server-utilstest suite green (all 17 tests; the one literal inResourcesElementsProviderImplTestwas updated to match the new default)resource-server-webapp:1.5.4-SNAPSHOTinto uPortal-start (resourceServerWebjarVersion=1.5.4-SNAPSHOT) and confirm:/resource-server/rs/lodash/4.17.4/lodash.min.js,/resource-server/rs/ckeditor/4.3.2/ckeditor.js,/resource-server/rs/bootstrap/3.3.5/css/bootstrap.min.css,/resource-server/rs/datatables/1.9.4/media/js/jquery.dataTables.jsreturns 404/resource-server/rs/modernizr/2.6.2/...,/resource-server/rs/normalize/2.1.2/...,/resource-server/rs/fontawesome/4.7.0/...,/resource-server/rs/famfamfam/silk/1.3/...,/resource-server/rs/tango/0.8.90/...,/resource-server/rs/canvg/r144/...,/resource-server/rs/template/1.0.0/.../resource-server/webjars/jquery/dist/jquery.min.js, etc.Notes
This PR pairs with consolidation PRs across the fleet (uPortal core, uPortal-start, and several portlet repos) that move every literal
/ResourceServingWebapp/path to/resource-server/and drop or replace the libraries the deleted bundle directories provided. The full migration story and per-deployer guidance live innotes/resource-server-consolidation-deployer-guide.mdin the workspace tracking docs.