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
