14 Years of Internal Pastebin Support: Lessons from Stack Evolution
An internal tool for sharing code and logs, similar to Pastebin, launched in 2012 and lasted 14 years. Initially, it was a simple web form for saving "pastes" with link generation and automatic deletion of outdated entries. Later, we added syntax highlighting, line-by-line comments, authorization, and drawing over text. The main value was local deployment without external services.
The project didn't claim to be unique: such solutions are easily reproducible. The key challenge was not creation, but long-term support, where technologies become obsolete, frameworks die, and user expectations grow.
Technology Stack: Scala Paired with Spring and Hibernate
The stack choice was driven by availability and interest: Scala instead of Java on a classic Spring-Hibernate-JSP setup. Scala 2.x compiled to JVM bytecode, but integration revealed compatibility issues.
- Annotations and class scanners: Spring and Hibernate incorrectly handled Scala bytecode. Example issue with Entity fields:
@ManyToOne(fetch = FetchType.EAGER, cascade = Array(CascadeType.PERSIST, CascadeType.MERGE))
@JoinColumn(name = "owner_id")
private var owner: User = nullFields required explicit default values.
- Data types, inheritance, enums, and annotations: A full range of incompatibilities, resolved through trial and error.
We avoided NoSQL and file storage: data loss on restart was unacceptable. Lucene for indexing caused duplicates during updates.
Build System: Maven Instead of sbt
In 2012, sbt was raw, with poor IDE and CI integration. Maven provided stability: support for SonarQube, multiple databases, and multiple servlet containers.
Advantages of Maven over a 14-year span:
- Predictable releases.
- Easy integration with the ecosystem.
- Minimal configuration changes.
sbt evolved, but migration wasn't necessary—Maven never let us down.
The Demise of Compass Search
Compass, the predecessor to Elasticsearch, integrated with Hibernate/Spring for embedded search. By 2014, the project died: the author moved on to distributed ES.
Consequences:
- Dependencies on outdated libraries broke updates.
- Supporting dead code took 5 years.
- Migration to Hibernate Search didn't succeed on the first try.
Lesson: monitor upstream project activity.
Issues with Apache Tiles and JSP Templates
Tiles added template composition to JSP, where the base technology was limited to include directives. Each page duplicated the structure:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE html>
<html>
<head>
<c:import url="header.jsp" />
</head>
<body>
<%@include file="body.jsp"%>
</body>
<footer>
<jsp:include page="footer.jsp" />
</footer>
</html>Refactoring became a nightmare. Tiles also died, worsening the problems.
Repository and Commits: 14 Years in One GitHub Repo
Development in spare time led to less-than-ideal commits. The code in recent versions is cleaned up, and the project is stable. Public access simplifies forks and contributions.
Key Takeaways
- Project support is more important than development: technologies become obsolete faster than expectations.
- Choosing a stack based on availability works but requires compatibility testing (Scala + Spring/Hibernate).
- Dead frameworks (Compass, Tiles) drag you down: monitor roadmaps.
- Maven remains the gold standard for stability in legacy projects.
- User data is critical even for temporary tools.
Overall, the project illustrates the reality of enterprise development—90% of effort goes into maintenance.
— Editorial Team
No comments yet.