- We used "convert-junit-assertions-to-assertj.sh" script to launch the automatic conversion.
- The auto conversion of assertEquals(<List>, <List>) was wrong.
- The auto conversion of assertEquals(int, Integer.inValue()) was wrong.
- assertThat(result.get("REGISTRATIONTIME")).isEqualTo(new Date(20)) in HandlingEventRepositoryTest.java (in the testSave method) throw an exception, because equals call isn't symmetric between java.util.Date and java.sql.Timestamp. AssertJ and Junit equality assertion doesn't call equals method in the same way. One invoke expected.equals(actual) and the other actual.equals(expected).
Extracted a Projections value object in the Cargo aggregate, which handles predictions about the future of the cargo (next expected activity, ETA).
Migrating to a much cleaner way to propagate handling updates to the cargo aggregate: Cargo.handled(HandlingActivity).
Moved some logic into *Status enums, making them richer.
Improvements to a number of toString()s
Moved web interfaces, web service and RMI remoting facade to iface package (temporarily renamed due to refactoring problems in IntelliJ when a package is named as a reserved word)
Introduced asynchronous processing of incoming handling event registration attempts.
Removed the plain-delegation track() method from TrackingService (using repository directly in CargoTrackingController instead).
Fixed a few carrier movement -> voyage references in setters and JSP expressions.
Added cargoIsMisdirected() and cargoHasArrived() to DomainEventNotifier (but no consumers yet).
Routing a cargo is still broken due to database changes incompatible with the random route generation algorithm.
Cargo tracking web interface now sits immediately on top of the domain layer, forming one of the "user interface extremes" (the other one being complete remote-DTO-separation).
Slight refinement of packge structure under application - service is split into things like messagning and remoting.
The external routing team application is moved out to its own top-level package, to highlight the fact that it is a completely separate application from booking/tracking.
Purged last DTO from domain service layer, in preparation for a combination of dedicated remote facade with DTO assembly (booking application) and working directly against the domain service layer (tracking web interface).
Split routing service into two parts: "our" part with model translation, and remote service part for graph calculations. Still a bit sketchy though.
More flesh on RouteSpecification, with some ideas around factory methods for specifications.
Renamed a few service methods to match ubiquotous language more closely.
Pushed DTO assembly outside of service layer and into MVC controllers, pending creation of dedicated remoting layer. Service layer now uses pure domain model classes.
CarrierMovementId implements ValueObject.
Final destination is now just "destination" everywhere.
Persistence annotations removed from domain model classes.
DeliveryHistory is now immutable.
Domain model implements the new pettern interfaces (entity/value object/domain event)
Orphaned old itinerary is now deleted when attaching a new itinerary to a Cargo.
Big slew of changes (too big) leading up to draft presentation:
Removed unneeded constructors in Cargo and UnLocode.
Fixed spelling error in StatusCode - "e before i except after c", or whatever that was :-)
Cascade Itinerary/Leg on Cargo persist.
Cargo registration and routing web administration interface.
Better randomization in RoutingServiceImpl.
Replaced more test locations with the SampleLocations instances.
Persisted Itinerary and Leg, with sample data and mapping.
Introduced Itinerary.EMPTY_ITINERARY to represent an emtpy itinerary (null object pattern)
Added capability to display expected/misdirected status of cargo and events to web tracking interface (jsp, DTOs, etc)
Location constructor now only has package-level visibility, and test code uses static location instances.
Rewrote UN Locode import to use straight JDBC access.
Added asynchronous event emission whenever a handling event is registered, so that interested parties can be notified if a cargo is misdirected (is unloaded, is late, has arrived, or whatever).
Two different implementations a available: JMS and a simple thread-based one.
Also, the cargo service track method now uses TrackingId in the signature, for consistency.
Suggestion for handling domain validation as close to each domain object as possible - Location now requires UN locode argument to constructor to match a certain regexp, and each HandlingEvent.Type may answer type.requiresCarrierMovement() and type.prohibitsCarrierMovement(), evaluated from HandlingEvent constructor.
- Persistent implementations of all repositories are in place, with tests and sample data generation.
Sample data is shared between testing and web application, and is loaded through a ServletContextListener
- No relation Cargo -> HandlingEvent, it only goes the other way. A HandlingEvent is only associated to one Cargo.
- TrackingId and CarrierMovementId do not rely on toString() anymore, the accessor for the id string is now called idString().
- CarrierId is now CarrierMovementId
- HandlingEventService now has named methods for registerLoad(), registerUnload() etc instead of the String "type" argument, which was extremely fragile.
Tightened the CargoTrackingController a bit, treating "no cargo found" same way as a binding error
Introduced a Spring context for the web layer, where all web support components go.
Introduced the RequestContext attribute as "rc" in views.
Removed unneeded "unknown cargo" JSP.
c:out not needed anymore.
Mohamed Gara
Dan Eidmark
marlin
Patrik Fredriksson
peter_backlund
Patrik Fredriksson
Jesper Hammarbäck
jorgen_falk