Comments inline :) >> Whatever mechanism(s) we choose, I feel they should all be in the same >> physical file (or single block of text). I wouldn't want end-users to >> specify multiple files - that would be an inconvenience that I at >> least would like to avoid as an end user. > > I agree to some extent (properties file perhaps excluded) - but to me this > implies if I'm using Spring I shouldn't have to go configure some groovy > script too. This is part of what feels wrong to me about the current config > - why do I have to configure somethings in an ini file and others in Spring?
Nope, you wouldn't have to - I've recently discovered that we've probably been doing Spring-based config in a less-optimal way all along. There is a much better way to configure Shiro when using Spring, and we're not using it in any of our samples: We need to change all the Spring samples to show in web.xml that the DelegatingFilterProxy should be used. Then the ShiroFilter itself and everything about it can be configured in a spring.xml file and benefit from things like the PropertyPlaceHolderConfigurer and other things. Much nicer. >> Would we be required then to use a 'pull' model, where our classes >> need to know how to acquire these values themselves? ... > A mediator that applies configured values is a good idea - just > not sure if it's over-engineering a configuration solution that should be > simple. I'm not sure it is over engineering - configuring the components is definitely a separate concern than how they operate. Keeping a clean separation of concerns has the added benefit that the components can be easily configured by any other configuration mechanism - something valuable to the integrators and framework developers that use Shiro (Trails, Wicket Security, Grails, etc). I wouldn't want to clutter up our components with configuration based concerns when our default configuration mechanism (a mediator?) can work like any of the other config mechanisms of 3rd party frameworks. >> We've already done this with our .ini mechanism, but it falls short in >> a few key areas. This is something I was looking to Groovy for > > But why should people need to use groovy if they're already using a "full > blown" IoC container. They shouldn't. They should use whatever their IoC container provides and what we can enable via a 'support' module for that IoC container. > 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. If this is to hold true - that we can't assume an IoC environment (and I'll definitely advocate it since many non-IoC-based frameworks are looking to us now for security) - then you have two options left for a Lowest Common Denominator config mechanism: - text based - Java programming. 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: securityManager.rememberMeManager.cookie.path = "/blah" As you know, that actually translates to object graph navigation and calling a final setter method - but it 'feels' like a simple property config. Very nice. >> Using Groovy could allow us to do other things as well - it'd be easy >> to config urls and 'global' properties in #1 using Groovy syntax, >> given how nice it is for custom Domain Specific Languages. > > 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). If all people ever did was use Shiro in Spring-based web-apps, this project probably wouldn't be necessary since most would just resort to Acegi/Spring Security. But because we can be used in any environment and be configured in any way because of JavaBeans compatibility, we offer a much more flexible (and still easier to understand!) alternative ;) >> 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. > 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. 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). Thoughts? Les
