The Newton Summit is behind us, and we have six months to prepare for the next release in both upstream OpenStack and RDO. Here is my attempt to build a prioritized list of the large tasks I want to tackle in this release.
These are my notes on how to reverse engineer what tags are doing in a JSF application. In this case, I am trying to figure out what are the classes behind the Configuration tags in the RHQ. I am trying to figure out what is being done by the tag
This tag is activated with the following value at the top of the page:
To Figure out what this tag means, I look in WEB-INF/web.xml. The web.xml value
Lets me know where the file is that defines the acceptable tags I can add to an xhtml page for this component.
This taglib defines the values
Note that these are JSF component names, and not Java class names. To resolve these to Java classes, we need to find the mappings. The mapping files are defined in web.xml under the entry:
In particular, I found what I wanted in
The values I care about are:
and the renderer for Config and ConfigurationSet components
This render extends javax.faces.render.Renderer. This is a Flyweight that parses and generates HTML. It has two main methods: decode an encode. decode parses the request that comes in, encode injects html into the response that goes out.
Decode appears to be called only on a post. Encode seems to be called even on a get.
I wasn’t super pleased with my results yesterday, so I kept plugging away. Better results today.
- Checked out sources. This time, I made a backup copy.
- ran mvn install in the jbossas directory
- ran mvn eclipse:eclipse in the jbossas directory
- imported the projects into eclipse. Saw about 100 errors.
- I had to exclude a couple of things from the source paths by hand.
In two cases, I had errors that showed different versions of standard Java classes regarding CORBA and JAAS. To get these to build correctly, I went to the Build Path popup and selected the Order and Export tab. In both cases, the JRE directory was the last one listed. I moved it to the top of the list. I suspect that some scripting is in order to reorder these in all of the .classpath files. However, once again, I have a project with no errors.
I notice that most of the projects refer to the jar files built from previous projects as opposed to depending on the projects themselves. Everything has been installed in M2_REPO, and is fetched from there as well. This is astep above installing in /thirdparty.