gmane.comp.apache.shiro.devel

Re: Initial steps toward 2.0

Jared Bunting — 2013-05-16T16:13:55

I'm on the fence on the Java version.  At my day job we are stuck on 1.6
and it seems we will be for the foreseeable future.  So we won't be able to
use Shiro 2.0 until we can convince all of our customers to switch (which I
don't see happening until Cloudera tells them to).

On the other hand, I'm advocating for an update here, and agree with the
general sentiment expressed by Les and Kalle.




On Tue, May 14, 2013 at 9:10 AM, Thibault TIGEON
<thibault.tigeon-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: [VOTE] Release Apache Shiro 1.2.2

Les Hazlewood — 2013-05-16T00:39:47

This vote is now closed.  It passes with 4 +1 binding votes, one +1
community vote and no 0 or -1 votes.

I'll update the website and release the Maven repo as soon as I can.

Thanks!

--
Les Hazlewood | < at >lhazlewood
CTO, Stormpath | http://stormpath.com | < at >goStormpath | 888.391.5282

On Tue, May 14, 2013 at 7:00 AM, Jeremy Haile <jhaile-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

[jira] [Created] (SHIRO-440) Improve Permission creation performance

Cservenak, Tamas (JIRA — 2013-05-15T09:47:16

Cservenak, Tamas created SHIRO-440:
--------------------------------------

             Summary: Improve Permission creation performance
                 Key: SHIRO-440
                 URL: https://issues.apache.org/jira/browse/SHIRO-440
             Project: Shiro
          Issue Type: Improvement
            Reporter: Cservenak, Tamas
            Priority: Minor


On complex systems, where many permissions (and complex recursive roles exists), the generic WildcardPermissionResolver creates a LOT of different instances even of same String permission representations. This might cause spikes in heap usage, but also eats CPU (as WildcardPermission constructor does a lot of string and collection operations too).

One possible solution would be "instance cache" of permissions, something like used in Nexus:

https://github.com/sonatype/security/blob/master/security-system/src/main/java/org/sonatype/security/authorization/PermissionFactory.java
https://github.com/sonatype/security/blob/master/security-system/src

Re: Initial steps toward 2.0

Thibault TIGEON — 2013-05-14T14:10:44

Hi,

I think also that the integration with CDI will be a good thing for the
next version (2).

Rgds,

Thibault


2013/5/14 Brian Demers <brian.demers-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: [VOTE] Release Apache Shiro 1.2.2

Jeremy Haile — 2013-05-14T14:00:32

+1 Good job - lots of good fixes in there!  


On Tuesday, May 14, 2013 at 9:42 AM, Brian Demers wrote:

Re: Initial steps toward 2.0

Brian Demers — 2013-05-14T13:47:20

I think this is a good idea

On Mon, May 13, 2013 at 3:21 PM, Kalle Korhonen
<kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: [VOTE] Release Apache Shiro 1.2.2

Brian Demers — 2013-05-14T13:42:02

+1

On Tue, May 14, 2013 at 5:05 AM, Tamás Cservenák <tamas-ULXqXn3CxrFbRRN4PJnoQQ< at >public.gmane.org>wrote:

Re: [VOTE] Release Apache Shiro 1.2.2

Tamás Cservenák — 2013-05-14T09:05:24

+1 Good work!


On Tue, May 14, 2013 at 12:24 AM, Kalle Korhonen <kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org

[jira] [Comment Edited] (SHIRO-359) Realm not initialised when bound in servlet mode with guice

picpoc (JIRA — 2013-05-14T01:51:16

    [ https://issues.apache.org/jira/browse/SHIRO-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656626#comment-13656626 ] 

picpoc edited comment on SHIRO-359 at 5/14/13 1:49 AM:
-------------------------------------------------------

Late comment: it's not really a bug, just a subtlety of Guice.
Instead of binding realms like:

    bindRealm().to(SampleRealm .class).in(Singleton.class);

bind it like that:

    bind(SampleRealm.class);
    bindRealm().to(SampleRealm.class).in(Singleton.class);

and the init method is called.

"Behind the curtain" explanation can be found in the description of [SHIRO-369].
                
      was (Author: picpoc):
    Late comment: it's not really a bug, just a subtlety of Guice.
Instead of binding realms like:

    bindRealm().to(SampleRealm .class).in(Singleton.class);

bind it like that:

    bind(SampleRealm.class);
    bindRealm().to(SampleRealm.class).in(Singleton.class);

and the init method is called.

[jira] [Commented] (SHIRO-359) Realm not initialised when bound in servlet mode with guice

picpoc (JIRA — 2013-05-14T01:47:16

    [ https://issues.apache.org/jira/browse/SHIRO-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656626#comment-13656626 ] 

picpoc commented on SHIRO-359:
------------------------------

Late comment: it's not really a bug, just a subtlety of Guice.
Instead of binding realms like:

    bindRealm().to(SampleRealm .class).in(Singleton.class);

bind it like that:

    bind(SampleRealm.class);
    bindRealm().to(SampleRealm.class).in(Singleton.class);

and the init method is called.
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Initial steps toward 2.0

Ghislain Touratier — 2013-05-14T01:30:36

Hi,

My 2 cents about the Shiro 2 Brainstorming:
(Don't know if it is the good thread for that)

* In the model of the AuthenticationStrategy, delegate logic of the
ModularRealmAutorizer to an AuthorizationStrategy that will play with the
new AuthorizationRequest/Response classes (already suggested somewhere I
think).

* Clarify/extend the role of the shiro Environment. Actually in the
"bootstrap/framework" related classes there are:
Environment: which is the provider of the security manager and eventual
other "main" objects.
SecurityUtils: convenient class which relies on a thread context (or a
static value) to provide the "current" security manager and subject, and
which may use the default subject builder.
It may be interesting to extend Environment to give it the responsability
to:
  - Provide the main objects (with at least the security manager and a
subject builder).
  - Provide the "current" context holder (a thing to bind/unbind subject,
and wrap callable/runnable) which can be by default based on th

[jira] [Updated] (SHIRO-435) SecurityManager is not a singleton in ShiroWebModule

picpoc (JIRA — 2013-05-14T00:51:16

     [ https://issues.apache.org/jira/browse/SHIRO-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

picpoc updated SHIRO-435:
-------------------------

    Attachment: SHIRO-435.path

Patch proposal to fix the double SecurityManager singleton. Also prevent the same issue on Environment. Update test cases of ShiroWebModule accordingly.
                

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Initial steps toward 2.0

Les Hazlewood — 2013-05-13T22:48:27

As a matter of practice, we don't make estimates because people
inevitably try to hold us to them ;)

That caveat aside, my gut feeling is that it will take at least a few
months (or more) of part-time development and continued discussion (I
think most of the Shiro devs tinker with Shiro on nights and weekends
as their time allows).  And that's just before an initial Alpha can be
released, let alone a Beta or 2.0 final.

Note that Java 1.6 is already publicly end-of lifed and it goes into
'long term premium support' by Oracle in Dec 2013, which is 7 months
away.

Les

On Mon, May 13, 2013 at 12:54 PM, Martin Grigorov <mgrigorov-1oDqGaOF3Lkdnm+yROfE0A< at >public.gmane.org> wrote:

Re: [VOTE] Release Apache Shiro 1.2.2

Kalle Korhonen — 2013-05-13T22:24:35

Kalle Korhonen: + 1 (binding)

On Mon, May 13, 2013 at 12:35 PM, Les Hazlewood <lhazlewood-1oDqGaOF3Lkdnm+yROfE0A< at >public.gmane.org>wrote:

Re: Initial steps toward 2.0

Martin Grigorov — 2013-05-13T19:54:38

Hi,

Do you have any estimations how long it will take until 2.0 is released ?
I think it is OK to require 1.7 now and even more by the time you are ready
with 2.0.
If someone cannot upgrade to Java 1.7 then Shiro 1.2.x will be still an
option.


On Mon, May 13, 2013 at 9:21 PM, Kalle Korhonen
<kalle.o.korhonen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

Re: [VOTE] Release Apache Shiro 1.2.2

Les Hazlewood — 2013-05-13T19:35:12

+1

Les

Re: Initial steps toward 2.0

Kalle Korhonen — 2013-05-13T19:21:32

Don't have strong objections. I'm for JDK 1.7 for 2.0 for the same reasons
as Les. What I see is a small percentage of companies still on JDK 1.5 for
whatever reasons but those on JDK 1.6 either planning on upgrading to JDK
1.7 or have already done so (but that's all anecdotal). We could even test
the waters with an eventual alpha release of 2.0 with JDK 1.7 and if that
doesn't fly too well, we could still downgrade in beta/GA release.

Kalle


On Mon, May 13, 2013 at 12:04 PM, Les Hazlewood <lhazlewood-1oDqGaOF3Lkdnm+yROfE0A< at >public.gmane.org>wrote:

Re: Initial steps toward 2.0

Les Hazlewood — 2013-05-13T19:04:59

I don't have any strong objections to this.  Does anyone else feel
strongly one way or another?

On Mon, May 13, 2013 at 6:46 AM, Brian Demers <brian.demers-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Initial steps toward 2.0

Brian Demers — 2013-05-13T13:46:41

I'm a little hesitent about dropping 1.6, as it may slow the adoption of 2.0

It is unfortunate, but 1.6 is likely to stay in production in many shops
for a few years.




On Sat, May 11, 2013 at 8:22 PM, Les Hazlewood <lhazlewood-1oDqGaOF3Lkdnm+yROfE0A< at >public.gmane.org>wrote:

Re: Initial steps toward 2.0

Les Hazlewood — 2013-05-12T00:22:16

P.S. I also believe Shiro 2.x should target JDK 1.7 and above.  1.6 is
already past its public end-of-life period, and since it will take a
little while to get a 2.0 version out, I'd hesitate to target
something that will be even that much more out of date.

Anyone feel otherwise?

Best,

Les

On Sat, May 11, 2013 at 5:18 PM, Les Hazlewood <lhazlewood-1oDqGaOF3Lkdnm+yROfE0A< at >public.gmane.org> wrote:

Initial steps toward 2.0

Les Hazlewood — 2013-05-12T00:18:27

Hi dev team,

I made the following initial changes in SVN to facilitate kickstarting
development on Shiro 2.x:

1.  I moved (using 'svn move' to retain version history) the existing
trunk to a new 1.x branch located here:
https://svn.apache.org/repos/asf/shiro/branches/1.x

If we ever feel the need to release a 1.3 version before 2.0, this is
the branch where that work would exist (also continuously merging any
bugfixes from 1.2.x into 1.x).

2.  I copied (using 'svn copy') this 1.x branch to what is now the
trunk here: https://svn.apache.org/repos/asf/shiro/trunk

3.  I'll be updating the poms to reflect version 2.alpha.0-SNAPSHOT

I suspect we'll want to make some alpha and then beta releases before
we release 2.0.0 final.  If you guys have any concerns or ideas about
the versioning scheme, please discuss.

4.  I'll start extracting config-specific things (Ini-specific
configuration mechanisms, etc) to a separate config module.  Please
review (and edit)
https://cwiki.apache.org/confluence/display/SHIRO/Ver