|Luke Daley||Aug 19, 2007 11:12 pm|
|Peter Ledbrook||Aug 20, 2007 2:20 am|
|Luke Daley||Aug 20, 2007 4:21 am|
|Graeme Rocher||Aug 20, 2007 4:22 am|
|Luke Daley||Aug 20, 2007 4:34 am|
|Graeme Rocher||Aug 20, 2007 5:02 am|
|Luke Daley||Aug 20, 2007 5:33 am|
|Marc Palmer||Aug 20, 2007 5:34 am|
|Peter Ledbrook||Aug 20, 2007 10:29 am|
|Peter Ledbrook||Aug 20, 2007 10:33 am|
|Luke Daley||Aug 21, 2007 3:46 am|
|Luke Daley||Aug 21, 2007 11:33 pm|
|Graeme Rocher||Aug 22, 2007 1:59 am|
|Subject:||Re: [grails-dev] Plugin configuration management.|
|From:||Graeme Rocher (grae...@yahoo.co.uk)|
|Date:||Aug 22, 2007 1:59:31 am|
On 8/22/07, Luke Daley <ld...@ldaley.com> wrote:
Thoughts on that?
I'll take the silence as "yes that's a reasonable idea".
Also, for the actual loading of the config scripts, do I need to use any special Grails class loading stuff? Or can I use a plain GroovyClassLoader?
What I mean is that do I need to get the class loader from the application instance? Or can I just pass URLs to ConfigSlurper which will use a plain GroovyClassLoader?
You can use a plain GCL.
Also, if I use a pattern with PathMatchingResourcePatternResolver to load the Config.groovy script files I need a way to test that. At test time, where will the pattern be relative to?
Its better to somehow mock the bit that resolves these resources and return ByteArrayResources instead
Also also, this could impact the log4j file generation since it would be valid for people to split the logging config up over multiple files. In my opinion that is a pretty neat feature. Plugins could provide a config file template for their own logging at install time. Instead of comparing the timestamps on the Config.groovy file and the generated log4j props file, the whole app config would have to be loaded and the 'log4j' config object extracted. From there it could be just blindly converted to a properties file and written out, or it could be compared against what is already there. The comparison would probably be more expensive than just writing it though. Another option would be polling through all the *Config.groovy files and checking time stamps.
Currently log4j is only generated in Config.groovy changes, so yes you would have to poll all the config files
Also also also, what is the opinion on DataSource.groovy? For consistency it really should become DataSourceConfig.groovy. I did some digging and it wouldn't be too big a deal to make this change.
Hmm no, I prefer it just as DataSource.groovy
Also also also also, should the files in each plugins 'conf' directory be loaded into the app config. IMO there should be a way for plugins to influence the main app config *without* having to copy files into the main application conf dir.
Yes there shouldn't be copying going on.
Should I add this as a proposal to the wiki? There is a ticket for it http://jira.codehaus.org/browse/GRAILS-1505.
I think its fairly clear how it wil work
--------------------------------------------------------------------- To unsubscribe from this list please visit:
-- Graeme Rocher Grails Project Lead http://grails.org