shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Antoniazzi <>
Subject Re: Shiro Guice Integration
Date Mon, 18 Jul 2011 13:02:14 GMT
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 <>

> 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
> <> wrote:
> > On Fri, Jul 15, 2011 at 8:36 AM, Jared Bunting
> > <> wrote:
> >> About a month ago I posted a patch to 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
> >> ( 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message