Freight Train
Observations
- speed
- FT is at least 300% faster than classic
- size
- runtime (composition layer) codebase is about 20% of classic
- buildtime codebase (type and component generator tasks) is about 70% of classic while packing a lot more functionality as class introspection is simply more efficient than javadoc tag handling
- note - auto-assembly functionality not included in FT
- impact
- buildtime validation is absolutely great - if something goes wrong is normally a build time error
- build exception reporting needs to be enhanced (not clear where an error is coming from when you have nested components
- runtime error reporting is good but on the other hand it feels a lot less important as a result of the strong buildtime validation
Issues
- logging manager
- transit or metro
- refactoring to use java.util.logging
- configuration and parameters
- some work remaining to be done
- safe to assume that config and params are immutable supply and forget artifacts (i.e. any runtime modification of a component would be through the context manager by the enclosing system)
- type and part viewers
- FT does not provide an XML view of a type or part
- can be addressed with a totally separate ant task - could be used to generate documentation about a component type and/or part automatically
- assembly logic
- all assembly directives are explicit
- need to add an assembly system in order to validate the explicit assembly instructions
- deployment and decommissioning ordering will be required when handling serialized models which in turn requires a deployment graph
- intergrate with Transit server mode
- Transit provides a server mode which triggers the setup of a reference transit instance. It is desirable to launch metro in server mode and direct cli requests to the remote metro instance.
- Server mode should be backed by an ant task that basically fires commands to a remote metro instance. Such a task could be used as part of a deployment test framework.
- a
Manager
inner interface- Thinking is needed about a
Manager
inner interface within a component. - Seems to be the right place for a component to publish instrumention info it makes available.
- Execution semantic are not currently handled.
- Thinking is needed about a
- context manager development
- More trials with
ContextManager
are needed to sort some of the details out. - Currently no validation on the
ContextManager
return type - but this is in effect a constraint declared by a container of the potential component that may be added as parts. This constraint needs to be handled as part of the component part creation task. - Implementation of the context manager invocation handler needs more work - specifically, we need to clone the model context entries and resolved values into the per-instance context table enabling a complete context model view (current implementation just exposes the modified values).
- More trials with
- default parts creation and parts management
- Packaging of default part with a component (e.g. [classname].parts) is required.
- The <type> task needs to be updated to include the part association or we could put in place a .parts serialized object colocated with the class.
- Parts builders need to updated to load and check for pre-declared default part entries.
- The PartsManager is not currently implemented (however, it is expected that this will follow closely the general approach used for context management.
- integration between FT and classic
- Need to update system context to load FT by default in no deployment targets are provided.
- If the target is classic metro then bootstrap the classic composition otherwise bootstrap FT.
- With an FT manager we could wrap classic with a dedicated controller - we could also do the same thing for Avalon 4 but this needs to be demand driven.
- But ultimately would should be working on the assumption concurrent maintenance of classic and FT should be temporary and that final numbered build of classic should be a milestone target following which we would freeze the classic codebase and continue with FT as the Metro codebase.
- classloader handling needs to move down to transit
- FT contains a specialized classloader with debugging support.
- This should be moved down to Transit as part of the net.dpml.transit package.
- general observations on Magic
- get some experience in on using links in Transit/Magic/Metro
- rebuild magic's index/module as this is currently Magic's weakest link
- model serialization
- model serialization is not implemented yet
- serialized models is central to the delivery of continuations
- documentation
- FT makes most of our technical documentation redundant.
- New tutorials are needed and documentation updates are required across the board.
- Lots of opportunities exist for additional tasks the load parts and generate documentation automatically.
Recommendations
The next section address recommendations based on the current development status.