Major Description
Developer tools are the first Magma fragment that has been created. They are currently a small set of web based information panels.
Now that we have an Eclipse plugin for Magma, it would be nice to see more and better developer tools for Magma inside Eclipse.
Main needs while developing in Magma are :
- Understand the current configuration
... Which packages/versions are being used (analysis of classpath entries)
... Which configuration files are being used (analysis of classpath resources)
... The complete list of configuration directives
... Current user and mode - The complete URI space
- Understand which file, and following which "path" (similar to a stack trace), is generating a specific part of a page
- Track environment interactions :
... read and write to session/cookies etc..
... Database interactions
... Email interactions
... (an extensible system would be great
) - Track log elements
- Track internationalization issues
... Missing keys for a specified language
... Which context and which key to use for a specified string
These functionalities are conceptually split in two different sets. Generic ones (apply to the whole running Magma instance) and page specific ones.
The first category can be obtained quite simply by calling specific URLs on a running instance, and obtaining some form (XML/Json/even HTML) dumps of data. Current developer implementation already offer some data, which should be reviewed and adapted to recent changes in Magma. This data should also be enriched enough to help the Eclipse plugin track the originating files and eventually line numbers.
Offering these informations via JMX is a possible way to expose them as well.
The second category is a mix of gathering data during page rendering, annotating the page so that those informations can be retrieved and offering a retrieve system. Again, data should be rich enough to help Eclipse track down single files and line numbers.
Gathering data is easy using a tracing aspect. Two different tracing systems should be in place :
- One system should track "global events", like access to session/cookies/request, database stuff, emails etc..
- Another system should track single output events, and annotate them properly.
Global events tracing will place events in a list and give each an ID, save the list with a "page ID", and annotate the output with that page ID for later retrival.
A similar mechanism will be used to save informations about single output events, except that these events will be more a tree than a list. In fact, calling a certain page will trigger output from a template, which will aggregate a number of components, that in turn will delegate to other components or producers, which may use files (like velocity templates). So, when looking at a box in the page resulting from a velocity template, all this trace should be present.
(If creating and managing a tree of identifier is too complex, then it can be handled on the server side. That is, the client will always require informations about a node, and the server will know that the given node is child of another one and so on. Moving this knowledge to the server makes the output annotation flat, instead of having a structured annotation system).
To annotate the output, XML/HTML comments are the only way that will preserve page integrity. Magma will inject comments inside the resulting HTML containing an ID to retrieve who is sending to output that part, and in which context.
Using progressive IDs for both tracing systems could help to integrate the two different tracings and present the user a single timeline of events.
To give enough informations so that Eclipse can find the originating file, we will have to use Maven Eclipse resolution of packages. In fact, using URLClassLoader specific methods, it's possible to find from which jar a given resource (.class file, or anything else) is coming. Given the presence in that jar file of the pom.xml, or using Maven naming conventions, it is possible to extract a Maven artifact key (groupid, artifactid, version), resolve it in Eclipse to obtain a JAR, a source folder or a dependant project, and then search the file there.
If such a resolution is not possible (for example, the file is being loaded from a "magma.locals" folder, so not from a maven jar) complete path of the resource will be given, so that inside Eclipse it will be possible to resolve it to a project folder in the workspace, or open directly the file outside the workspace.