Skip to content

GSIP 142

Jump to bottom
Jody Garnett edited this page Jun 15, 2016 · 10 revisions

GSIP 142 - Delay 2.9 Release for Spring 4 upgrade

Overview

Proposed By

Jody Garnett

Assigned to Release

This proposal is an adjustment to the GeoServer 2.9 release schedule.

State

  • Under Discussion
  • In Progress
  • Completed
  • Rejected
  • Deferred

Motivation

Spring 3 incompatibility with Java 8

With the GeoServer 2.9-beta going out we have found an incompatibility with Java 8 and the asm bytecode manipulation library used by Spring 3.

Q: Like what?

Internet research indicates ASM used to inspect a class structure and create dynamic proxies, so this should only happen if classes uses Java 8 byte code. Andrea researches shows the surefire way to cause this try to proxy a bean that uses Java 8 default method, or use java 8 syntax in a class that needs to be instantiated by Spring.

Q: Where is this happening? A: Kevin working on a GWC feature branch that causes this issue

The feature branch introduces this problem by writing a method using java 8 syntax, no change to GeoServer interfaces, no introduction of default methods etc...

Kevin has found the problem here (https://github.com/smithkm/geowebcache/commits/wmscap-refresh) in a feature branch of GWC. This is happening as Spring reads the class via asm to figure out the constructor arguments. Unit tests for GWC do not use spring, so this was only found late in the game during manual testing.

Temp Fix Proposal: Build and Run with Java 8 carefully

Build and run with Java 8, be careful, and depend on testing.

For this plan we can set the compile target=1.7 byte code to catch any use of Java 8 syntax in the codebase. The use of target=1.7 bytecode is not strictly required, it is just safer.

The approach would be to avoid the use of any Java 8 features ... in any bean that will be instantiated by spring.

Without the use of target=1.7 any java code that is not created by spring could make use of Java 8 features.

Pros:

  • This would keep our current release schedule, opening master up to spring 4 migration in march for a GeoServer 2.10 timeframe.
  • No change to bi-annual release schedule
  • Users could run with confidence on Java 8? Meeting security policies without licensing Java 7 from oracle.
  • Andrea strongly advocated for this solution
  • This would keep our current release schedule, opening master up to spring 4 migration in march for a GeoServer 2.10 timeframe.
  • No change to bi-annual release schedule
  • Users could run with "some" confidence (safety in numbers) on Java 8, would really reply on build box and user list testing

Cons

  • This plan risks application stability, possibly an acceptable risk for a bad situation
  • Developers would be unwise (or prevented with target=1.8) from use Java 8 features (since they are risky and may accidentally breaking things)
  • Even with target=1.7 we are at risk from GeoTools 15 beans (or those working on custom extensions built with Java 8)
  • We would still need to migrate to Spring 4 pretty much now, but would have "more time" to get it right
  • Less "pressure" means less chance to get this issue handled promptly, funded and resolved

timeframe

march 1st:

  • (done) review amount of work to back out java 8 use, minimal work needed
  • ask PSC to decide on course of action

short-term:

  • Start the 2.9.x branch and back out java 8 use
  • Estimate: 1-2 days to set target=1.7 and backout any use of Java 8
  • Issue 2.9-RC1 on March 3rd, 2.9.0 March 18th (according to schedule)

long-term:

  • Find finding/support to do the Spring 4 upgrade for GeoServer 2.10 (six month development window)
  • Spring 4 migration would still represent an outstanding risk (nobody wants to go through another wicket sprint experience)

research

Q: How much work to backup Java 8 use for GeoServer 2.9?

This would be a 2-3 days. Is this worth it?

Q: How many classes effected on master?

Changing jre and target=1.7 in eclipse show 35 errors (mostly lambda and function use)

Q: How stable is 2.9 series?

Andrea has some experience running GeoServer 2.9 in production: building on Java 8 for 2 months, a couple 2.9 systems in preproduction testing

Q: Would we need to make a target=1.7 change to GeoTools?

Looks like Spring ASM also touches on constructor arguments, so maybe ...

Upgrade Now Proposal: Delay Release and Migrate to Spring 4

Migrate to Spring 4 now, delaying the GeoServer 2.9 release.

This requires us to Extend GeoServer 2.8 time line:

  • We will need to backport some work need to backport (UTF-GRID for geosolutions customer commitments, wps remote, etc...)

Pros:

  • We would update spring now ... and avoid what happened to wicket
  • Developers able to use Java 8 features
  • less project risk
  • Users could run with confidence on Java 8 (Meeting security policies without licensing Java 7 from oracle).

Cons:

  • Delay to release schedule (2-3 months), would need to restore schedule or use 9 month schedule
  • can we do this quickly and safely?

timeframe

march 1st:

  • (done) andrea has looked into migration to spring mock library - thanks!
  • (done) Ask christian about cas security changes identified by justin
  • (pending) Ask PSC to decide on course of action

short-term:

  • adjust roadmap, write blog post
  • perform spring 4 upgrade immediately
    • compile: 2-3 weeks to get core application working
    • extensions (special attention to security, and security-cas)
    • community
    • test: migrate tests from mock runner to spring-test
    • integration: CITE, security LDAP, security CAS

long-term:

  • GeoServer 2.9 release would be delayed 2-3 months
  • Spring 4 migration would be taken care of immediately (and would not represent an outstanding risk)

research

Checking with key stakeholders:

  • Boundless - in favour of this, willing to commit resources to see this happen
  • GeoSolutions - require a release delay of three months, in favour but will need to scramble to meet customer contracts (example backporting work).

Q: How difficult is it to update security CAS?

Want to hear back from christian (CAS is a risk identified above)

Backwards Compatibility

Update to spring 4 will break backwards compatibility, and require updating many additional dependencies.

The following will require extensive work due to api change:

  • spring jdbc use
  • security

Discussion

See wiki [Spring 4 Upgrade](Spring 4 Upgrade).

Voting

member Build & Run with Java 8 Delay Release for Spring 4 Update
Alessio Fabiani ✅
Andrea Aime +1 +0
Ben Caradoc-Davies ✅
Brad Hards 🎱 🎱
Christian Mueller ✅
Ian Turton ✅
Jody Garnett ✅
Jukka Rahkonen ✅
Kevin Smith ✅
Simone Giannecchini ✅

Links

©2020 Open Source Geospatial Foundation

Home
Proposals
Release Schedule

Clone this wiki locally