Re: [Dspace-devel] Runtime reconfiguration [was Re: [DSJ] Commented: (DS-524)]
On Tue, May 18, 2010 at 04:48:47PM -0700, mdigg...@atmire.com wrote: On May 17, 2010, at 9:23 AM, Mark H. Wood wrote: On Fri, May 14, 2010 at 01:57:45PM -0700, mdigg...@atmire.com wrote: On May 14, 2010, at 12:53 PM, Mark H. Wood wrote: On Fri, May 14, 2010 at 02:17:01PM +, Tim Donohue (JIRA) wrote: (Sidenote: Eventually, someday, I feel we should move the majority of all configurations to the Admin UI -- so that there's no need to stop/start Tomcat/DSpace every time you need to modify dspace.cfg. However, in order to achieve this, we need to *trust* that the System Administrator knows what he/she is doing -- they should be allowed to make any change in the system.) If runtime reconfiguration is a goal, we need to agree on it (and I'm not disagreeing here) and then go through the code to make sure that we *always* call the ConfigurationManager for settings instead of e.g. caching config. data via static initializers. We should be using the DSpace Service ConfigurationService for such support. Application code can listen to the ConfigurationService for configuration changes and act accordingly. Is that something we're supposed to be using now, then? Yes, ideally, I am recommending adopting the use of DSpace services over the default Managers for new development wherever possible. There was a small bug that limited it form working in dspace 1.6.0, this has been corrected for the Dpace 1.6.1 release. I give your recommendations considerable weight. But there is a difference between I recommend and we all decided to start doing this. I hope that this week's special-topic meeting will move us toward a decision. What I'd really like to see is a discussion that involves more buy-in to the dspace -services support. Likewise, while doing the various GSoC projects we will want to review all the configuration parameters and discuss which should remain in the config files , database, and more importantly which should leave the configuration altogether in favor of being supported in the Spring and other framework configuration that is applied when an Addon Module is added into your DSpace instance. I'd like to see some discussion of what dspace-services *are* and what we need to be doing about them. Well, that is where the rubber meets the road isn't it... Aaron, Graham, Brad, Ben and I placed a great deal of work into creating the thing last year, the materials could stand some consolidation and community members are welcome to join in to assist in getting documentation and understanding to the next step. As a beginning, mostly to help myself begin to get my arms around Services, I've been hacking away at the Javadoc thereof. I don't claim to understand much of it yet, but I find the result more readable and the exercise did drag me through all of the code, which should help. Anyone who *does* understand Services is invited to correct my errors and omissions. Is Spring our direction now? Sensible, and I've begun using it where it doesn't impact established practice, but I wasn't aware that established practice is to be changed. What most people do not realize is that Spring has been our direction since DSpace 1.5.2 when we upgraded the XMLUI to use Cocoon 2.2. The DSpace 2.0 work was almost entirely Spring centric, though with a consideration that other IoC/DI solutions and frameworks may become of interest tot he community. If most people do not realize it, then it hasn't been our direction; it has been some folks' direction. IMHO probably a good direction. But, as with Services, we need a decision: are we all going to start doing this now? [Spring gives us good things] What we will need to see is greater embracing of Spring and training on how to configure the applications using it. Thats a project folk's like myself are will ing to take on, but theres a great deal of preparation that still needs to happen to be informative about it. Starting with the consensus. Probably that means a decision to make fuller use of Spring (in some fashion) happen in 1.7. You made a good point above which I had not sufficiently remarked: not only do we need to decide what configurations go in the database (if we're going to do that), but which ones belong in a Spring application context. I think we might classify things thus: o Operational controls o Deployment settings o Runtime assembly of the instance I think those are arranged in order from most likely belong in the database to most likely belong in the application context. But that's just a sketch, and needs more thought. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ pgpKQFahhKNlQ.pgp Description: PGP signature
Re: [Dspace-devel] Runtime reconfiguration [was Re: [DSJ] Commented: (DS-524)]
On May 17, 2010, at 9:23 AM, Mark H. Wood wrote: On Fri, May 14, 2010 at 01:57:45PM -0700, mdigg...@atmire.com wrote: On May 14, 2010, at 12:53 PM, Mark H. Wood wrote: On Fri, May 14, 2010 at 02:17:01PM +, Tim Donohue (JIRA) wrote: (Sidenote: Eventually, someday, I feel we should move the majority of all configurations to the Admin UI -- so that there's no need to stop/start Tomcat/DSpace every time you need to modify dspace.cfg. However, in order to achieve this, we need to *trust* that the System Administrator knows what he/she is doing -- they should be allowed to make any change in the system.) If runtime reconfiguration is a goal, we need to agree on it (and I'm not disagreeing here) and then go through the code to make sure that we *always* call the ConfigurationManager for settings instead of e.g. caching config. data via static initializers. We should be using the DSpace Service ConfigurationService for such support. Application code can listen to the ConfigurationService for configuration changes and act accordingly. Is that something we're supposed to be using now, then? Yes, ideally, I am recommending adopting the use of DSpace services over the default Managers for new development wherever possible. There was a small bug that limited it form working in dspace 1.6.0, this has been corrected for the Dpace 1.6.1 release. Item for next week's agenda? What I'd really like to see is a discussion that involves more buy-in to the dspace -services support. Likewise, while doing the various GSoC projects we will want to review all the configuration parameters and discuss which should remain in the config files , database, and more importantly which should leave the configuration altogether in favor of being supported in the Spring and other framework configuration that is applied when an Addon Module is added into your DSpace instance. I'd like to see some discussion of what dspace-services *are* and what we need to be doing about them. Well, that is where the rubber meets the road isn't it... Aaron, Graham, Brad, Ben and I placed a great deal of work into creating the thing last year, the materials could stand some consolidation and community members are welcome to join in to assist in getting documentation and understanding to the next step. Where the official documentation will one day live... http://wiki.dspace.org/confluence/display/DSTEST/DSpace+Services+Framework Where the current resources are today... http://wiki.dspace.org/confluence/display/DSPACE/DSpace+Services+Framework http://www.slideshare.net/mdiggory/dsug09-services-2255693 http://wiki.dspace.org/confluence/display/DSPACE/DSpace+2.0#DSpace2.0-CurrentDevelopment http://wiki.dspace.org/confluence/display/DSPACE/DSpace+2.0+Modelling+Services http://wiki.dspace.org/confluence/display/DSPACE/DSpace+2.0+Core+Services I think the question of runtime reconfiguration, yes or no, is a separate one. Both deserve discussion time. Yes it certainly is, but it would be silly to implement runtime config on a subsystem we are attempting to deprecate and do away with. We'll also need to stare hard at each of the configuration variables and work out which ones make sense to adjust at runtime. The only ones I would be really concerned with are the ones that configure the database connection (strictly because changing them may break the above process if they are stored in that database). Besides being a chicken/egg problem. :-) I've been thinking for some time that I ought to see whether it makes any sense to provide the database linkage through the servlet container. [goes to see] Things like environment entries and resource references seem to be optional parts of the servlet spec. Tomcat provides them but other non-J2EE containers may not. Drat. But database URLs and credentials could be made webapp context parameters. All J2EE containers have to provide a JNDI context where JNDI resources such as database connection pools can be configured. In JEE, such JNDI resources are generally served out to the webapps by the EAR+WAR installed into the server. The topic is relevant and has been discussed in the past, however, we are currently stuck with CLI needing to have the config as well, leaving us the need to configure it in two different places. Perhapse allowing such a violation DRY would actually be enabling and simplifying for the architecture. Eventually, I think many would prefer to see the CLI fade away in favor of a webapp driven job engine... something like the Quartz Scheduler I quickly hacked... Likewise, any plugin driven configuration, we should be looking at how to move out into Spring as a Service or Provider attached to a service. Then work on cleaning up the properties so there less of the current property value parsing format and key number enumeration nightmares happening and the properties are more
Re: [Dspace-devel] Runtime reconfiguration [was Re: [DSJ] Commented: (DS-524)]
On Fri, May 14, 2010 at 01:57:45PM -0700, mdigg...@atmire.com wrote: On May 14, 2010, at 12:53 PM, Mark H. Wood wrote: On Fri, May 14, 2010 at 02:17:01PM +, Tim Donohue (JIRA) wrote: (Sidenote: Eventually, someday, I feel we should move the majority of all configurations to the Admin UI -- so that there's no need to stop/start Tomcat/DSpace every time you need to modify dspace.cfg. However, in order to achieve this, we need to *trust* that the System Administrator knows what he/she is doing -- they should be allowed to make any change in the system.) If runtime reconfiguration is a goal, we need to agree on it (and I'm not disagreeing here) and then go through the code to make sure that we *always* call the ConfigurationManager for settings instead of e.g. caching config. data via static initializers. We should be using the DSpace Service ConfigurationService for such support. Application code can listen to the ConfigurationService for configuration changes and act accordingly. Is that something we're supposed to be using now, then? Item for next week's agenda? What I'd really like to see is a discussion that involves more buy-in to the dspace -services support. Likewise, while doing the various GSoC projects we will want to review all the configuration parameters and discuss which should remain in the config files , database, and more importantly which should leave the configuration altogether in favor of being supported in the Spring and other framework configuration that is applied when an Addon Module is added into your DSpace instance. I'd like to see some discussion of what dspace-services *are* and what we need to be doing about them. I think the question of runtime reconfiguration, yes or no, is a separate one. Both deserve discussion time. We'll also need to stare hard at each of the configuration variables and work out which ones make sense to adjust at runtime. The only ones I would be really concerned with are the ones that configure the database connection (strictly because changing them may break the above process if they are stored in that database). Besides being a chicken/egg problem. :-) I've been thinking for some time that I ought to see whether it makes any sense to provide the database linkage through the servlet container. [goes to see] Things like environment entries and resource references seem to be optional parts of the servlet spec. Tomcat provides them but other non-J2EE containers may not. Drat. But database URLs and credentials could be made webapp context parameters. Likewise, any plugin driven configuration, we should be looking at how to move out into Spring as a Service or Provider attached to a service. Then work on cleaning up the properties so there less of the current property value parsing format and key number enumeration nightmares happening and the properties are more normalized. Is Spring our direction now? Sensible, and I've begun using it where it doesn't impact established practice, but I wasn't aware that established practice is to be changed. I agree that there are areas of the current configuration that strongly resist being squashed into Properties format and should change *somehow*. I'll have to study a bit, though, to imagine ways they could be done in Spring other than maps-within-maps, which is largely the same mess only wordier. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ pgptCHBhEW7yJ.pgp Description: PGP signature -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Runtime reconfiguration [was Re: [DSJ] Commented: (DS-524)]
On Mon, May 17, 2010 at 12:23:14PM -0400, Mark H. Wood wrote: [moving complex configuration structures to Spring] I agree that there are areas of the current configuration that strongly resist being squashed into Properties format and should change *somehow*. I'll have to study a bit, though, to imagine ways they could be done in Spring other than maps-within-maps, which is largely the same mess only wordier. *sigh* nevermind. Configuration structures become beans or compositions of beans, or (if you're not a parsers anti-fan like me) we can even have property editors for them. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ pgpbiiXzLZSMO.pgp Description: PGP signature -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Runtime reconfiguration [was Re: [DSJ] Commented: (DS-524)]
I would say something like the database config / connection string would be the only thing that *needs* to stay in the configs. So if everything else moved to the DB, then that could be easily/safely modified in an admin section of the user interface, by the admin user. Somewhat like modifying settings. Peter Dietz Systems Developer/Engineer Ohio State University Libraries On Fri, May 14, 2010 at 3:53 PM, Mark H. Wood mw...@iupui.edu wrote: On Fri, May 14, 2010 at 02:17:01PM +, Tim Donohue (JIRA) wrote: (Sidenote: Eventually, someday, I feel we should move the majority of all configurations to the Admin UI -- so that there's no need to stop/start Tomcat/DSpace every time you need to modify dspace.cfg. However, in order to achieve this, we need to *trust* that the System Administrator knows what he/she is doing -- they should be allowed to make any change in the system.) If runtime reconfiguration is a goal, we need to agree on it (and I'm not disagreeing here) and then go through the code to make sure that we *always* call the ConfigurationManager for settings instead of e.g. caching config. data via static initializers. Item for next week's agenda? We'll also need to stare hard at each of the configuration variables and work out which ones make sense to adjust at runtime. Absolutely, the sysadmin. is allowed to break anything, so long as he is prepared to answer for it. :-) I expect that (both aspects) when I wear my sysadmin. hat. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel -- ___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
