I really would like to this this patch about Guice inside Shiro (or -extra). I have to keep in my project the Guice/Shiro glue code that could be hosted as third party. Moreover, I think that this is a good thing for Shiro to support Guice, maybe more than Spring, because all Spring users can use Spring Security, whereas Guice users do not have a ready to use Security framework.
2011/7/16 Les Hazlewood <[email protected]> > I agree that we should support Guice for balance reasons. If we > eventually get around to going ahead with a 'shiro-extras' project, we > can move all of the support modules (including Spring) to that project > so we don't show any favoritism. > > But I think it's a great idea to include Guice support now in the meantime. > > Jared, do you have a CLA on file w/ Apache? If you think you might be > participating regularly beyond the occasional patch, it is the easiest > way to go. If not, patches are fine, but I'm just thinking about what > may be easier in the long run. > > Cheers, > > Les > > On Fri, Jul 15, 2011 at 7:52 PM, Kalle Korhonen > <[email protected]> wrote: > > On Fri, Jul 15, 2011 at 8:36 AM, Jared Bunting > > <[email protected]> wrote: > >> About a month ago I posted a patch to SHIRO-23 > >> (https://issues.apache.org/jira/browse/SHIRO-23) for adding Guice > >> support to Shiro. At the time, I mentioned that it still needed some > >> refinement and test coverage. Rather than post continual patches as I > >> completed that, I started a small project on bitbucket > >> (https://bitbucket.org/jaredbunting/shiro-guice) for this code. > >> At this point, I feel like it's fairly feature complete, and I've added > >> some documentation to it as well. Is this something that could be > >> considered for inclusion into Shiro proper under SHIRO-23 ? > > > > I'm probably in the best position to handle it. I looked over your > > patch earlier and already thought it looks good enough for inclusion > > in principle but the remaining, generic contention is whether we want > > to support third-party libraries within Shiro. There are opinions both > > for and against integration modules. For historic reasons, we've > > always had support for Spring but in general we'd like each project to > > host shiro integration libraries themselves. However, the practical > > answer is we are willing to include anything we intend to support. > > Guice is so close to Tapestry-ioc's programming model and so far from > > (old-school) Spring (especially compared to setter vs. constructor > > injection) that personally, I'd like to see Guice being supported as > > part of Shiro, just to serve as a balance. I don't use Guice anywhere > > at the moment myself but perhaps there's a few things we can do to > > have better guarantees to maintain Guice integration in the future. If > > you think it's ready for inclusion, make the patch anyway and attach > > it to the issue - that way we can keep the paperwork in order. > > > > Kalle >
