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
onc:config
This tag is activated with the following value at the top of the page:
xmlns:onc=”http://jboss.org/on/component”
To Figure out what this tag means, I look in WEB-INF/web.xml. The web.xml value
facelets.LIBRARIES
Lets me know where the file is that defines the acceptable tags I can add to an xhtml page for this component.
/WEB-INF/tags/on.component.taglib.xml
This taglib defines the values
tag-name config
component-type org.jboss.on.Config
renderer-type org.jboss.on.Config
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:
javax.faces.CONFIG_FILES
In particular, I found what I wanted in
/WEB-INF/jsf-components/configuration-components.xml,
The values I care about are:
component-type org.jboss.on.Config
component-class org.rhq.core.gui.configuration.ConfigUIComponent
and the renderer for Config and ConfigurationSet components
component-family rhq
renderer-type org.jboss.on.Config
renderer-class org.rhq.core.gui.configuration.ConfigRenderer
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.
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.