That all sounds good to me :)
On Fri, Sep 11, 2009 at 2:20 PM, Jeremy Haile <[email protected]> wrote: >>> And why should our documentation and default examples >>> show using groovy to do programmatic configuration when we actually think >>> it's a better decision for our users to just embrace an actual "full >>> blown" >>> IoC container? I don't want to require any particular IoC container - >>> but I >>> don't see building our own IoC/configuration/whatever system as adding >>> any >>> value. >> >> I think this is where we probably disagree. I feel strongly there >> should not be a requirement, or even assumption, that an IoC container >> would or should be used when using Shiro. Sure, we should make it >> super simple in an IoC environment, but we shouldn't depend on that. > > I didn't say it should be a requirement - just that I don't think we should > "roll our own". If we want to support a dependency-injection based model of > configuration (i.e. like our current INI config), it makes no sense to me > for us to build our own and make that a core requirement. We should just > support existing frameworks. > >> If not depending on an IoC container, as an end-user I for one sure >> wouldn't like to recompile my application every time I needed to >> change configuration. That leaves text-based configuration. >> >> Groovy, IMO offers the best text-based configuration mechanism >> available. You don't need to recompile it, and it can even feel like >> a normal properties mechanism. > > Well - let's support this via a "support" module just like Spring. > shiro-groovyconfig.jar > >>> But what if I don't want to use groovy - can I still configure these in >>> Spring? Can I configure them in Guice? I don't understand the big >>> picture >>> being proposed here. >> >> Yep, you could, via the corresponding IoC-specific 'support' module. >> I'm talking about using just Shiro, in any environment - no >> assumptions on an IoC container or web environment. This is very >> important for the integrators and usages of Shiro in lightweight >> environments (I've been contacted by people working on a cell phone >> app - they probably don't have access to an IoC container or a web >> server). > > I never said they needed an IoC container - I just said they could use Java > to easily configure it. If we want to support a groovy config option, let's > make it a "support" module just like Spring or Guice. > > >>>> But I wonder - should our default Lowest Common Denominator >>>> configuration mechanism have _zero_ dependencies? >>> >>> I agree here. Our Lowest Common Denominator is Java. "Want zero >>> dependencies? Use Java and programmatically configure your Shiro >>> installation. Want nice configuration and dependency injection - then >>> use >>> an actual IoC container. We have great integration with Spring, Grails, >>> Guice, X, Y, and Z." >> >> I agree that the LCD is Java. But that's an LCD that most people >> won't like. There is a need and community desire for a >> no-compile-necessary configuration mechanism that does not assume >> container or web app environment. At least that's my feeling from the >> non-Spring users and framework developers that are integrating Shiro. > > Great - if that's their desire then let's create a support module for that > configuration option. The LCD in the core can still be Java and groovy is > one of several options for configuring it. I feel like a broken record - > sorry. > >>> BeanUtils is an apache-commons project that most big Java projects use >>> anyway. Groovy seems a much stranger core dependency to me. Don't get >>> me >>> wrong - I heavily use Groovy at work and love it. I just don't see how >>> it >>> makes sense here as a core dependency of the Shiro project. >> >> Actually, I don't think BeanUtils should be a core dependency anymore >> - it is only there to support .ini based 'poor man's IoC' >> configuration. And I agree that Groovy shouldn't be a core dependency >> either - it should be an addition as a support module. Then the end >> user can choose whatever they want based on what module(s) they >> include in their project. > > I don't think BeanUtils should be a dependency either. Let's shed off our > "poor man's IoC" implementation completely and just support several > different configuration mechanisms that can be chosen based on your > environment. (including simple, pure Java-based configuration) > >> That sounds pretty good to me - separate modules depending on the >> configuration mechanism you desire, with the default just being >> programmatic Java (by implementing the Configuration interface in >> normal Java code). > > Yep - I agree. The core has no IoC or config dependencies. Then you > include a support module JAR for groovy config, Spring, Guice, whatever if > you want to use that environment to configure it. Our docs should have a > section per support module to explain how to setup Shiro using each > mechanism. > > The broken record responder, > Jeremy
