AS 7 JBoss Modules Tattletale Report

[bmaxwell]

Implementation thoughts:

- Create ModuleProfile creator class that can creates the profile containing the classes.  It could create a JBoss AS 7 profile in a single file, or it could create a profile for each module.  The generated module profile should also contain the module name from the module.xml, so that it can be retrieved in the report.

- Create a JBossModulesDependenciesReport that analyzes an archive and gives the MANIFEST.MF that lists the Dependencies:... for all of the modules needed.

1) Read the application, create a list of classes the application depends on
2) Remove classes from the list that are provided in the application
3) Compare the remaining classes to those classes contained in $JBOSS_HOME/modules (by loading the data created by the Module Profile)
4) If the class is supplied by a module, then read the module.xml and get the module name, store it in a list of moduleDependencies

Any thoughts?

[jaikiran]

Brad Maxwell wrote:

- Create a JBossModulesDependenciesReport that analyzes an archive and gives the MANIFEST.MF that lists the Dependencies:...

The jboss-deployment-structure.xml [1] in the deployment archive too allows for specifying module dependencies. So even that should be looked into.

[1] https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7

[jesper.pedersen]

Yeah, the end result should be a report which contains a jboss-deployment-structure.xml file and a MANIFEST.MF entry (Dependencies:) such that the user can choose.

However, it is easier to create a profile for AS7 which contains the module identifier for all classes, and extend the Archive class with a new field (getModuleIdentifier) which defaults to the archive name.

Then have a tool output the data with module identifier, class and archive name - which the profile loads. That way it is only done once.

Having said that, Navin is working on adding support for enterprise archives which is step 1 - as users deploys .war, .ear, and so on. So those are the files we need to generate the report based on.

Navin, anything you want to add ?

[bmaxwell]

Support for ear/war/etc would be good, but we have gotten around this by making sure the deployments are exploded.  For example tattletale run on a zipped war doesn't produce any output, however if we unzip the war, then tattletale generates the reports we have needed.  It maybe missing the classes in WEB-INF/classes, but typically in our use case the classes we are looking for are in the WEB-INF/lib jars.

I have some code I wrote to take a jboss distribution zip and generate a list of all of the classes in it.  It is a little messy, but let me know if it would be useful.  Basically it unzips the zip, then it will find all of the deployment types, and then it unzips them in place, it makes a copy so that it does not mess with the original.  A note when adding code to handle deployments such as ear, we have seem some users with massive deployments around 1 GB, so using temp files would be recommended else there will be memory issues.

[navssurtani]

In terms of the war/ear support that's nearly there. In fact, it should get done by this avo UTC. What's happened is that the zipped up war file gets extracted out into a temp directory and then the reports built from that. It's a bit hacky I guess but that's done.

Once that is done I'll get onto the JBoss Modules part of it and get crunching on that.