Structure101 for Java is based on a J2SE-style view of the classes in a code-base. Of particular significance is the implicit assumption that the runtime environment being mirrored is a single Java VM. This means that, if a class file is duplicated across multiple jars (or classes directories), then the first one "wins" and all subsequent occurrences will be masked (ignored).

On of the key aspects of the J2EE environment is that it explicitly sets out to allow multiple different versions of the same class (or jar) to exist in parallel (each ejb component, war, etc. runs in a separate VM). So component 1 can use version 1 of say an XML parser while component 2 uses version 2 of the same parser, without giving rise to any conflicts.

However, this aspect of J2EE is incompatible with the Structure101 J2SE-style view. If support for multiple parallel versions of the same classes is important to you, then, sadly, Structure101 for Java (in its current form) will not be of any use (though please do let us know - our impression is that there is very little general interest in this aspect of J2EE).

If, on the other hand, the issue of multiple parallel versions does not register very high on your radar, then you may well find lots of value in pointing Structure101 for Java at your J2EE code. The only question then is how this is achieved.

In effect, all J2EE code starts off as conventional J2SE code. It only becomes J2EE-compliant when it is packaged into J2EE-specific archives (ears, wars, etc.) Accordingly, the most straightforward way to load J2EE code into Structure101 is always simply to grab the compiler outputs before the packaging process kicks in. At this stage, you are guaranteed to have completely standard class and/or jar files than can be passed to Structure101 in the normal way. Moreover, because Structure101 works off incomplete class paths, there is no need to worry about any J2EE- or application server-specific runtime libraries.

You should be aware that the resulting model displayed by Structure101 will be an imperfect reflection of what would actually take place inside a J2EE container. For example, the model will not include any dependencies that manifest themselves solely through the use of deployment descriptor entries. Moreover, the model may show some dependencies that appear to be valid from a static analysis perspective (assuming a single Java VM), but which would actually fail in a J2EE environment where a target exists in a different container and is in fact invisible to the source class. In general, however, displayeds model should be perfectly suitable from the standpoint of static structural analysis.

Converting J2EE packages to J2SE

Things only really become fiddly if, for whatever reason, it is not possible to grab the outputs before the J2EE packaging kicks in. In this case, it is necessary first to reverse these packages back to a J2SE format that Structure101 understands. The remainder of this page describes the reversing procedure for various use cases.

Currently, Headway does not provide potted scripts for these operations, but we will review this depending on the level of interest.

Reversing a single war (web application)

First, let's suppose you have a single war file webapp1.war.

The first step is to unpack (e.g. using winzip) the war to some directory, e.g ..temp/webapp1. On completion (and assuming your war actually contains Java code other than jsps), you should see a subdirectory called "classes" or a subdirectory called "lib" (or both):

The classes directory, if present, will be a valid class path token in its own right, i.e. you can specify this path directly in the Structure101 for Java class path dialog.
The lib directory will contain (zero or more) jar files. In this case, you would select the jar files in the class path dialog (not the lib directory).

That's it.

Reversing multiple wars

Repeat the steps outlined above for each individal war file.

Tip (assuming use of classes directory)
If you are particularly interested in the interactions between the classes at the war level, go to the Composition perspective and, in the client Hierarchy windowlet (top-left) and switch to the Jar hierarchy from the dropdown. At the root level, you should now see one "jar" node for each set of war classes. Confusingly, both will be called "classes" but if you mouse-over you will see the fully qualified path. To simplify the naming, rename the classes directories (or move all classes up one directory) and reset the Structure101 class path accordingly.

Reversing an ear file (enterprise archive)

The first step is to unpack (e.g. using winzip) the ear to some directory, e.g ..temp/myear. On completion, you should see a a number of J2EE archive files appear in this directory. For any war files, perform the steps outlined above.

Legal