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

Reply via email to