Encapsulating Config Logic across Config.groovy, BootStrap.groovy, and resources.groovy

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Encapsulating Config Logic across Config.groovy, BootStrap.groovy, and resources.groovy

Brian Kotek
Hello, just curious if anyone here has any insight into this problem. One of our apps uses the Spring Security plugin, and what it does depends on the environment. Let me start off by saying all of this works as it is now, so this isn't a Spring Security question, that just happens to be what is prompting the question.

For example, in development mode we just log in with a user name and password. On QA/Staging, we log in using certificates. And in production, we use the Pre-Authentication provider (an F5 appliance handles authentication and clustering).

I have all this working, but the implementation is a bit messy. So in Config.groovy, I may set a flag based on the environment. In BootStrap, the config flag is used to modify the Spring Security filter chain (if needed). And in resources.groovy, the config flag is used to conditionally add beans (such as the authentication provider, filter, etc.).

What I'd like to do is wrap this up into a Helper class. For Config and BootStrap, I believe this would be pretty straightforward to call inline. Resources.groovy seems like the challenge, as I'm not sure how I can use the Helper class to conditionally generate and "embed" the closures that create the optional beans into Resources.groovy.

Any advice? 

Thanks,

Brian

Reply | Threaded
Open this post in threaded view
|

Re: Encapsulating Config Logic across Config.groovy, BootStrap.groovy, and resources.groovy

sergiomichels
Can you post what you're doing in Resources.groovy? If you use the Helper class in config to set your flag, ins't the case of still maintaining this flag in resources?

--
Sérgio Michels


On Mon, May 6, 2013 at 4:39 PM, Brian Kotek <[hidden email]> wrote:
Hello, just curious if anyone here has any insight into this problem. One of our apps uses the Spring Security plugin, and what it does depends on the environment. Let me start off by saying all of this works as it is now, so this isn't a Spring Security question, that just happens to be what is prompting the question.

For example, in development mode we just log in with a user name and password. On QA/Staging, we log in using certificates. And in production, we use the Pre-Authentication provider (an F5 appliance handles authentication and clustering).

I have all this working, but the implementation is a bit messy. So in Config.groovy, I may set a flag based on the environment. In BootStrap, the config flag is used to modify the Spring Security filter chain (if needed). And in resources.groovy, the config flag is used to conditionally add beans (such as the authentication provider, filter, etc.).

What I'd like to do is wrap this up into a Helper class. For Config and BootStrap, I believe this would be pretty straightforward to call inline. Resources.groovy seems like the challenge, as I'm not sure how I can use the Helper class to conditionally generate and "embed" the closures that create the optional beans into Resources.groovy.

Any advice? 

Thanks,

Brian


Reply | Threaded
Open this post in threaded view
|

Re: Encapsulating Config Logic across Config.groovy, BootStrap.groovy, and resources.groovy

Brian Kotek
Hi, Sergio.

I don't have the exact code in front of me right now, but the jist of it is: right now I'm doing something like this in resources.groovy (pseudocode):

beans = {

// normal beans DSL...
if( isStaging ) {
// beans DSL related to staging
}
else if( isProduction ) {
// beans DSL related to production
}
}


What I'd prefer is to do something like:

beans = {

// normal beans DSL...
// This would basically do what the above code does, but using a helper class to insert the DSL...
helperClass.addBeansForEnvironment( currentEnvironment )
}

So as I said, my uncertainty is how (or if) I can use another class like that to "embed" any necessary bean DSL items depending on the environment. I have some similar checks in BootStrap that could also be encapsulated in the same helper class. Since BootStrap isn't a DSL, calling the helper within BootStrap shouldn't be an issue. The trick is whether this can be done within the beans DSL to "generate" any necessary bean DSL inline.

Make sense?

Thanks,

Brian




On Mon, May 6, 2013 at 9:47 PM, Sergio Michels <[hidden email]> wrote:
Can you post what you're doing in Resources.groovy? If you use the Helper class in config to set your flag, ins't the case of still maintaining this flag in resources?

--
Sérgio Michels


On Mon, May 6, 2013 at 4:39 PM, Brian Kotek <[hidden email]> wrote:
Hello, just curious if anyone here has any insight into this problem. One of our apps uses the Spring Security plugin, and what it does depends on the environment. Let me start off by saying all of this works as it is now, so this isn't a Spring Security question, that just happens to be what is prompting the question.

For example, in development mode we just log in with a user name and password. On QA/Staging, we log in using certificates. And in production, we use the Pre-Authentication provider (an F5 appliance handles authentication and clustering).

I have all this working, but the implementation is a bit messy. So in Config.groovy, I may set a flag based on the environment. In BootStrap, the config flag is used to modify the Spring Security filter chain (if needed). And in resources.groovy, the config flag is used to conditionally add beans (such as the authentication provider, filter, etc.).

What I'd like to do is wrap this up into a Helper class. For Config and BootStrap, I believe this would be pretty straightforward to call inline. Resources.groovy seems like the challenge, as I'm not sure how I can use the Helper class to conditionally generate and "embed" the closures that create the optional beans into Resources.groovy.

Any advice? 

Thanks,

Brian



Reply | Threaded
Open this post in threaded view
|

Re: Encapsulating Config Logic across Config.groovy, BootStrap.groovy, and resources.groovy

Ian Roberts
On 07/05/2013 04:13, Brian Kotek wrote:

> What I'd prefer is to do something like:
>
> beans = {
>
> // normal beans DSL...
> // This would basically do what the above code does, but using a helper
> class to insert the DSL...
> helperClass.addBeansForEnvironment( currentEnvironment )
> }
>
> So as I said, my uncertainty is how (or if) I can use another class like
> that to "embed" any necessary bean DSL items depending on the
> environment. I have some similar checks in BootStrap that could also be
> encapsulated in the same helper class. Since BootStrap isn't a DSL,
> calling the helper within BootStrap shouldn't be an issue. The trick is
> whether this can be done within the beans DSL to "generate" any
> necessary bean DSL inline.

You should be able to do

import com.example.HelperClass

beans = {
  HelperClass.addBeansForEnvironment(currentEnvironment, delegate)
}

and then in the HelperClass

import grails.util.Environment

class HelperClass {

  void addBeansForCurrentEnvironment(env, b) {
    if(isStaging(env)) {
      b.someBeanOrOther(TheBeanClass) {
        prop1 = "hello"
      }
    }
  }
}

i.e. pass the "delegate" of the DSL from resources.groovy and use that
in the helper method to call into the DSL.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Encapsulating Config Logic across Config.groovy, BootStrap.groovy, and resources.groovy

Brian Kotek
Exactly what I was hoping for! Thanks, Ian, I'll give that a try.


On Tue, May 7, 2013 at 5:51 AM, Ian Roberts <[hidden email]> wrote:
On 07/05/2013 04:13, Brian Kotek wrote:
> What I'd prefer is to do something like:
>
> beans = {
>
> // normal beans DSL...
> // This would basically do what the above code does, but using a helper
> class to insert the DSL...
> helperClass.addBeansForEnvironment( currentEnvironment )
> }
>
> So as I said, my uncertainty is how (or if) I can use another class like
> that to "embed" any necessary bean DSL items depending on the
> environment. I have some similar checks in BootStrap that could also be
> encapsulated in the same helper class. Since BootStrap isn't a DSL,
> calling the helper within BootStrap shouldn't be an issue. The trick is
> whether this can be done within the beans DSL to "generate" any
> necessary bean DSL inline.

You should be able to do

import com.example.HelperClass

beans = {
  HelperClass.addBeansForEnvironment(currentEnvironment, delegate)
}

and then in the HelperClass

import grails.util.Environment

class HelperClass {

  void addBeansForCurrentEnvironment(env, b) {
    if(isStaging(env)) {
      b.someBeanOrOther(TheBeanClass) {
        prop1 = "hello"
      }
    }
  }
}

i.e. pass the "delegate" of the DSL from resources.groovy and use that
in the helper method to call into the DSL.

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK

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

    http://xircles.codehaus.org/manage_email