atom feed13 messages in org.codehaus.grails.devRe: [grails-dev] Plugin configuration...
FromSent OnAttachments
Luke DaleyAug 19, 2007 11:12 pm 
Peter LedbrookAug 20, 2007 2:20 am 
Luke DaleyAug 20, 2007 4:21 am 
Graeme RocherAug 20, 2007 4:22 am 
Luke DaleyAug 20, 2007 4:34 am 
Graeme RocherAug 20, 2007 5:02 am 
Luke DaleyAug 20, 2007 5:33 am 
Marc PalmerAug 20, 2007 5:34 am 
Peter LedbrookAug 20, 2007 10:29 am 
Peter LedbrookAug 20, 2007 10:33 am 
Luke DaleyAug 21, 2007 3:46 am 
Luke DaleyAug 21, 2007 11:33 pm 
Graeme RocherAug 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
List:org.codehaus.grails.dev

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

Cheers

- LD.

--------------------------------------------------------------------- To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email