Geronimo has a number of assemblies, including geronimo-jetty6-javaee5, geronimo-jetty6-minimal, geronimo-tomcat6-javaee5, and geronimo-tomcat6-minimal. Each assembly has a pom.xml and a config.xml (in its src/main/resources/var/config directory) that determine its content of the possible configs. Each assembly's pom.xml configs dependency elements determine the assembly's content. All of the configs in the assembly's config.xml (in its src/main/resources/var/config directory) are started, unless they have a load="false" attribute. Finally, any config required by a config to be started is also started. (An example here is j2ee-system. It's not in config.xml, but rmi-naming has a dependency on it. (Shouldn't some of these j2ee- configs be renamed to javaee?))
This mechanism determines the server's content, as well as which configs are started when the server starts. There are two additional config.xml files in an assembly's src/main/resources/var/config directory: jsr88-configurer-config.xml and offline-deployer-config.xml. It seems that the configs in these config.xml files run in separate execution instances of jsr88-configurer and offline-deployer, so that those configs would not run in the server. It is not clear to me why those configs would be in the server, nor why they would show up in the deploy list-modules command. It seems that having them do so is only asking for trouble if the administrator starts them. The final set of configs to discuss is for the app client, which is another separate execution instance from the server. I have not been able to find a config.xml or pom.xml file for it. There are thus four entities with which a config may be associated: 1. server (many types here, but a server has a config.xml, unlike the other entities) 2. jsr88-configurer (jsr88-configurer-config.xml) 3. offline-deployer (offline-deployer-config.xm) 4. app client (? -- use client-corba-yoko as root?) It seems that the notion of "started" is only applicable to server entities. In terms of an automated way to generate a table of configs with their description, entity association and initial start attribute: 1. Visit each config in the configs directory, gathering its description and dependencies. 2. For each entity, consult its list of configs to determine content. For each config, insure that all its required configs are included. Ted Kirby On 10/4/07, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 3, 2007, at 6:21 PM, Prasad Kashyap wrote: > > > On 10/3/07, Ted Kirby <[EMAIL PROTECTED]> wrote: > >> Cool! I wrote a (cough, cough) perl script to generate wiki markup > >> for a table from the data in the configs/*/pom.xml files, and updated > >> the wiki page with it. I then produced a merged table to compare > >> existing pom descriptions to the ones I had entered. I'd like to get > >> further input, store updated descriptions in the pom.xml description > >> element, and then I think it makes sense to generate a page from the > >> pom.xml data. There appear to be two attributes for each that would > >> be nice to capture in doc: whether the module is initially started, > >> and whether it should *never* be started. I wonder if any sort of > >> attribute could be added for capturing this in pom.xml? > > > > IIUC, are you wondering if we should add attributes in the pom.xml > > that will say whether this configuration is initially started or > > should never be started ? > > > > Other than for updating the wiki, will this attribute be useful for > > anything else ? > > I think there's already an attribute for whether the plugin gets > started: otherwise we'd be running the client plugins in the server. > > "never start" is a misnomer.... it might be "never start in the > normal server".... if you really never start it ever then you can > just leave it out :-) > > I'm wondering if there's a way to have the plugin descriptor direct > its customizations to a particular kernel configuration: server > configs going into config.xml, artifact_aliases, and config- > substitutions, client configs going into maybe > client_aritifact_aliases, etc etc. If there's a way to make this > work then a more accurate description of "never start" would be "not > part of the server". > > So I'd like to wait with the "never start" attribute until we figure > out if this is practicable. > > thanks > david jencks > > > > > Cheers > > Prasad > >> > >> Ted Kirby > >> > >> On 10/2/07, David Jencks <[EMAIL PROTECTED]> wrote: > >>> Nice! > >>> > >>> In trunk, the <description> element in the config's pom gets put > >>> into > >>> the geronimo-plugin.xml description so it really needs to be > >>> accurate. It would be great if we could generate future versions of > >>> this page from the plugin catalog. Meanwhile it might be worthwhile > >>> comparing the descriptions here with the descriptions in the trunk > >>> configs' poms to make sure they are consistent and the most > >>> informative wins :-) > >>> > >>> thanks! > >>> david jencks > >>> > >>> On Oct 2, 2007, at 3:05 PM, Ted Kirby wrote: > >>> > >>>> I have added this wiki page > >>>> http://cwiki.apache.org/GMOxDOC20/system-modules.html to list the > >>>> modules that come with the (2.0.1) server, along with: > >>>> > >>>> 1. A brief description of what the module does > >>>> 2. Is it started by default, or > >>>> 3. Should it never be started? > >>>> > >>>> This is a first draft. I solicit feedback and encourage folks to > >>>> update the page as appropriate. There are some modules with > >>>> which I > >>>> am not familiar. > >>>> > >>>> Ted Kirby > >>> > >>> > >> > >
