Re: System Module descriptions
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 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
Re: System Module descriptions
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 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
Re: System Module descriptions
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 ? Cheers Prasad > > Ted Kirby > > On 10/2/07, David Jencks <[EMAIL PROTECTED]> wrote: > > Nice! > > > > In trunk, the 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 > > > > >
Re: System Module descriptions
This is great stuff! Any way to extract this information for placement on a wiki page? I was also thinking it would be great to get this wiki page info available on the console in text form so the administrator could read it, say starting with module description. Ted Kirby On 10/3/07, Joe Bohn <[EMAIL PROTECTED]> wrote: > > > Hernan Cunico wrote: > > Hi Ted, > > it would be great to add which modules are critical for Geronimo to run, > > in other words, those we should never mess with. We had a discussion > > some time ago but I don't think we ever properly covered this. > > I added some safety checks in the web console for this. There is now an > expert mode such that the stop, uninstall, restart action are only > available on org.apache.geronimo modules when the expert box is checked. > I also added some more specific warnings of consequences when the > actions are to be performed. Of course, this only provides some safety > for administrators when using the web console and does nothing for those > that prefer the command line. Then again the web console is > probably the place where it is a bit easier to do some damage. > > Joe > > > > > Cheers! > > Hernan > > > > 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 > >> > > >
Re: System Module descriptions
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? Ted Kirby On 10/2/07, David Jencks <[EMAIL PROTECTED]> wrote: > Nice! > > In trunk, the 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 > >
Re: System Module descriptions
Hernan Cunico wrote: Hi Ted, it would be great to add which modules are critical for Geronimo to run, in other words, those we should never mess with. We had a discussion some time ago but I don't think we ever properly covered this. I added some safety checks in the web console for this. There is now an expert mode such that the stop, uninstall, restart action are only available on org.apache.geronimo modules when the expert box is checked. I also added some more specific warnings of consequences when the actions are to be performed. Of course, this only provides some safety for administrators when using the web console and does nothing for those that prefer the command line. Then again the web console is probably the place where it is a bit easier to do some damage. Joe Cheers! Hernan 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
Re: System Module descriptions
Hi Ted, it would be great to add which modules are critical for Geronimo to run, in other words, those we should never mess with. We had a discussion some time ago but I don't think we ever properly covered this. Cheers! Hernan 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
Re: System Module descriptions
Nice! In trunk, the 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
System Module descriptions
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
