adding Struts modules

[ccrouch]

So Steve just asked me a question about adding new struts modules to the admin console, which I thought would be helpful for a wider audience.

First off each UI component in the admin-console is maintained as a separate Struts module. We have three so far: datasources (using the default module), jms (struts-config-jms.xml) and webservices (wsabi-struts.xml). Hibernate would make if four, presumably in struts-config-hibernate.xml

Each module needs to get setup in the web.xml, which just requires adding another element to the ActionServlet configuration, e.g.

<init-param>
 <param-name>config/hib</param-name>
 <param-value>/WEB-INF/struts-config-hibernate.xml</param-value>
 </init-param>

Once this is done the module's struts configuration file can be filled out. If you've followed the instructions above then you can setup an action to have its path attribute relative to the module prefix (hib, in the example above). For example creating an action definition like this in the hibernate struts module configuration...

<action path="/list"....>

would mean you would access the action like this:
http://localhost/admin/hib/list.html

See wsabi-struts.xml for an example of this.

For more general information on configuring Struts modules see here:

http://struts.apache.org/userGuide/configuration.html#dd_config_modules

[sebersole]

I would also suggest breaking up the stuff in WEB-INF a little bit. Something like:

WEB-INF/
 hibernate/
 struts-config.xml
 tiles-defs.xml
 ...

Otherwise, that directory will get unwieldy once we get many more modules...

They are all explicitly defined paths, so it won't really matter where they live

[ccrouch]

Agreed. We might as well go the whole hog and have:

WEB-INF/
 conf/
 hibernate/
 jms/
 ...

That way we have:

WEB-INF/
 classes/
 jsp/
 conf/

Lets start this way with the Hibernate module and we can migrate across the other modules as we progress.

[peterj]

Charles, I like your suggestion, makes the WEB_INF directory less cluttered andm ore orgranized. I'll schedule the migration for the JMS component.

[sebersole]

Another thing I have noticed is "common" resource bundle stuff contained in the module-specific bundles. For example, the datasource bundle defines keys for the various deployments states; I guarentee these will get used by other modules.

I started a common.properties resource bundle to contain these kinds of view label keys. I am using it from the hibernate module; I'll leave it to the other modules to migrate if they wish.

[peterj]

Since we are in the mood for some restructuring...

Charles and I talked earlier about an alternate directory scheme where each component was kept in it sown source tree. Right now, the directory that corresponds to the component is at the end of the list (e.g., admin-console/src/main/org/jboss/admin/model/jms). To foster separation of components, it might be best to have the module directory first, as in admin-console/jms/src/main/org/jboss/admin/model/jms (or perhaps admin-console/jms/src/main/org/jboss/admin/model). We could set ruls such that any module could referenbce the 'base' module but not any other module (e.g., jms could not reference datasource). The build.xml in admin-console would call the build.xml in ./base, ./datasource, ./jms, etc. This might make it easier to package the components as individual portlets when we move to the portal server.

We did want to do this originally because my team wanted to be a little more familiar with the processes and the admin console source before we tackled such a thing. But maybe now is the time.

[ccrouch]

"PeterJ" wrote:

To foster separation of components, it might be best to have the module directory first, as in admin-console/jms/src/main/org/jboss/admin/model/jms . We could set ruls such that any module could referenbce the 'base' module but not any other module (e.g., jms could not reference datasource). The build.xml in admin-console would call the build.xml in ./base, ./datasource, ./jms, etc. This might make it easier to package the components as individual portlets when we move to the portal server.

Agreed. Having talked to Ruel, master of the JBoss build system, he suggested we follow the example used in the 'aspects' component for handling the multiple src folders.
So riffing off that I thought we could have the following:

jboss-head\admin-console\src\main\.

\jms (includes org\jboss\admin\model\jms\*, org\jboss\admin\service\jms\*, org\jboss\admin\console\web\struts\jms\*)

\datasource (includes org\jboss\admin\model\datasource\*, org\jboss\admin\service\datasource\*, org\jboss\admin\console\web\struts\datasource\*)

\hibernate (includes org\jboss\admin\model\hibernate\*, org\jboss\admin\service\hibernate\*, org\jboss\admin\console\web\struts\hibernate\*)

\common (any .java files not in one of the other categories)

I think it is a good idea, for clarity and to reduce code changes, to maintain the current package names.

Once this is done we would remove the current main\org\* folder structure.

We can enforce the "rules" you refer to by ensuring the classpath for building the component source trees only includes \common and the standard jar dependencies. Clearly the build.xml, .classpath and .project will need to be updated to support this and also the general eclipse build jboss-head\build\eclipse.psf will need changing.

Since the tests will never get packaged up I don't think it makes much sense to refactor them.

First things first, Peter can you create a JIRA issue for this so we can track it?

[ccrouch]

"PeterJ" wrote:

Charles, I like your suggestion, makes the WEB_INF directory less cluttered andm ore orgranized. I'll schedule the migration for the JMS component.

Excellent. You should be able to use WEB-INF\conf\hibernate\* as a template.
Can you create a JIRA issue to track this one too?

[ccrouch]

Clearly the build.xml, .classpath and .project will need to be updated to support this and also the general eclipse build jboss-head\build\eclipse.psf will need changing.

To clarify: I would expect us to continue only using a single build.xml file in .\admin-console\, just that it would have several compile steps, one for each module.

[peterj]

An alternative would be to have a build.xml file for each component, and a master build.xml for the admin console as a whole. The component build.xml files could have targets to compile, test and package just that component. The master build.xml would call the component build.xml files to compile and test the components, but have its own target for packaging.

[walkerrl49]

An alternative would be to have a build.xml file for each component, ...

And we keep our fingers out of each others' build.xmls!

[peterj]

The Struts-related configuration files for JMS have been moved to WEB-INF/conf/jms.

The web service and datasource configuration files still have to be moved.