Chore/upgrade spring to 5 3

[cbeach47]

Spring upgrade to 5.3.

• Brought in Liferay portlet support
• Fixed some deprecation warnings due to dependencies
  • Removed the json mapper view. The JSON portlet type does not appear to leverage that mapper view.
• Deprecated Gateway SSO portlet type
  • Compiles, but did not test runtime functionality
• Added lombok dependency and replace log instantiation with @Slf4j.
• Ensured all log4j dependencies/references were removed
• [EDIT]: Hook in uPortal parent pom and clean up deps.
  • parent pom PR: Add common deps from Webproxy Spring5 upgrade. Add and adjust plugins uportal-portlet-parent#3

Testing note: Due to available time, not all classes with the logging switch were tested. However - some were tested, and the logging switch was a simple switch across the board without logic adjustments.

[ChristianMurphy]

Thanks @cbeach47!
From skimming the code (I have not tested this locally) it looks good!

[groybal]

I see some issues with dependencies when I deploy the portlet to Tomcat. In WEB-INF/lib, I noticed:

• I see both of these jars but I think we only want the slf4j one: commons-logging-1.2.jar and
  jcl-over-slf4j-1.7.5.jar
• there are two jaxb-core jars (jaxb-core-2.2.7.jar and jaxb-core-2.3.0.1.jar)
• I see this jar,which I think is no longer needed: spring-webmvc-portlet-4.3.30.RELEASE.jar
• I see mockito-core-4.9.0.jar, which is only needed for testing and therefore should not be here

[groybal]

Why was this removed? When I deploy the portlet to Tomcat, I see both these jars in WEB-INF/lib, but I think we only want the slf4j one:

• commons-logging-1.2.jar
• jcl-over-slf4j-1.7.5.jar

[cbeach47]

For logging, the goal is logback (via the slf4j api). All other logging implementations (even transitive ones) should be removed. I'll look into how commons-logging is still getting deployed.

The JCL bridges (-over-) are now included in spring-jcl, so we don't have to explicitly declare them in the pom, however, I'll need to check if jcl-over-slf4j-1.7.5.jar is from spring-jcl, or a transitive dependency that should be excluded.

[groybal]

So, lines 201-206 actually prevent any dependency from pulling in commons-logging, which is why I think it should remain. Otherwise, you have to find which dependencies are pulling in commons-logging and add excludes.

[cbeach47]

As per our side discussion with @bjagg , I'm going in the direction of using the maven enforcer plugin, and then excluding the commons-logging jars as needed. @groybal - please let me know if you don't feel this is sufficient.

[cbeach47]

discussed in PR - change the parent pom to have a dependencies section with the excluded deps as 'provided'

[cbeach47]

@groybal -

• I see both of these jars but I think we only want the slf4j one: commons-logging-1.2.jar and
  jcl-over-slf4j-1.7.5.jar

I've now set up the maven enforcer to ban commons-logging, and adjusted the pom to not emit the commons-logging dep.

• there are two jaxb-core jars (jaxb-core-2.2.7.jar and jaxb-core-2.3.0.1.jar)

Took a deeper look at the jaxb-core jars - These 'duplicate' jars were present prior to upgrade, and deals with CAS and personDir flows. In order to control scope, I am to delay this. Added #217 for a future effort.

• I see this jar,which I think is no longer needed: spring-webmvc-portlet-4.3.30.RELEASE.jar

Good catch - I've removed it now.

• I see mockito-core-4.9.0.jar, which is only needed for testing and therefore should not be here

Ah - the scope was misconfigured. This is now removed in the deployment.

[cbeach47]

Since we only support Java 8+ , doclint is disabled at the maven-javadoc-plugin level in the parent pom.

[cbeach47]

Collapse dependencyManagement

[cbeach47]

Leave a note similar to SCP's plugin

[cbeach47]

Good to remove - note, that this locally builds, and pluto-izes the war file. Add this to the release notes.

[bjagg]

Hi @cbeach47 — thanks for the effort here. This is a substantial Spring 4.3 → 5.3 migration (47 files, +231/-582). Unfortunately it's been stale since 2023 and the fleet's direction has shifted: the other portlets that were at risk of mismatched Spring have settled into either 4.3.x (stay) or 5.3.x (when parent plugins forced it). This portlet is currently staying on 4.3.30 alongside the rest of the pinned fleet.

We've also recently landed a lot of concurrent work (parent-pom adoption through uportal-portlet-parent:48, Java 11 CI alignment, renovate pins) that would conflict with this branch significantly.

Closing this out. When the fleet is ready to move off Spring 4.3 — most likely as part of a coordinated Jakarta EE / Java 17 migration — we can revisit using what you sketched here as a reference for the Webproxy-specific changes (portletmvc4spring wiring, interceptor updates, view selector pattern).

Really appreciate the groundwork.