Upgrade Meeting for Architecture Working Group: Spring 2 Issues, Spring 3 Benefits, and Oracle Migration
Table of Contents
- Meeting
- System upgrade (JVM, Tomcat, Spring)
- Spring 2 issues
- Some Spring 3 code is already in place
- Spring 3 benefits
- However, annotations can be a cause for concern
- Move to JVM 7; what's required?
- The schedule for moving from Resin
- Options for deprecation
- Business support is required to deprecate features
- Effects on Oracle migration with app deprecation
- New features will require upgrades to JVM and Tomcat
- Dependency management becomes much easier w/o Resin
- Major refactoring may force a sprint-long code freeze
- Scheduling
- Oracle migration
- Collections/Collectables/Actionable Object Collection
- Roadmap
Meeting
- Attendees: To: "jin.kim@memorylane.com" <jin.kim@memorylane.com>, "Davidson, Steven" <Steven.Davidson@memorylane.com>, "Davis, Lee" <Lee.Davis@memorylane.com>, "Skillen, Paul" <Paul.Skillen@memorylane.com>, Jason Walsh
- When: 3:00 PM - 4:00 PM January 12, 2012
- Subject: Architecture Working Group
- Location: Conf. SEA - Scream 6- 8 5335 <Conf.SEA-Scream@classmates.com>
System upgrade (JVM, Tomcat, Spring)
Spring 2 issues
Interceptors for controllers fragile
Forms: POST -> authentication -> SAT
Spring 2.5.6 requires monolithic interceptors.
If someone sets up the default controller the security is lost.
Spring 3.1 allows annotations on the controllers for multiple interceptors.
Some Spring 3 code is already in place
For tiles integration.
However, annotations can be a cause for concern
JPA mappings nearly difficulty.
Move to JVM 7; what's required?
Will require moving off of Resin before the jump to 7.
Current work is for moving search off of Resin.
Message boards are tentatively scheduled for deprecation.
The road-map includes references to "message board" that likely diverge.
The schedule for moving from Resin
Search
Photos
Likely just a technical debt issue.
No more presentation. Just supports the actual processing of the photos. There are fewer photos being uploaded as well.
Community (workplace, military, and neighborhood)
There was a comment of just noting that the person was in the military rather than a full affiliation.
Profile
As long as go/x isn't still present this could be done.
Directory
Being ported now (Titans).
Options for deprecation
EOL but available
Keep it available but have no upgrades.
Use all the new JDK and Tomcat.
Migrate
Not an active support. For example, header changes.
Things like trivial UI changes: link updates could still be done but core couldn't be rebuilt.
Business support is required to deprecate features
If deprecation occurs early then some of the upgrade work may just go away.
Effects on Oracle migration with app deprecation
For example, data migration of message boards. Data is threaded message by community including private communities.
New features will require upgrades to JVM and Tomcat
Tomcat 7: servlet
Async HTTP
Dependency management becomes much easier w/o Resin
No more dual builds.
Major refactoring may force a sprint-long code freeze
Could be other options but the merge locations may just go away.
This would largely just be about core.
Shouldn't affect UI changes
Would also require regression testing
Some work has already been done for the integration testing of services but this would need to be part of the planning.
Separating work between teams may be possible
Scheduling
Starting only depends on the deprecation
Splitting up core and Spring upgrade.
Switching over the pom files
Parent pom
Regression test the components
Spike on Spring 3.1
Q2 planning would need to be communicated early
Oracle migration
Neo4j is a quarter of the licensing costs
Standard hardware layout.