svn commit: r899388 - in /incubator/shiro/trunk/core/src/main/java/org/apache/shiro: authz/Permission.java session/Session.java

[lh...@apache.org]

Author: lhazlewood
Date: Thu Jan 14 20:13:01 2010
New Revision: 899388

URL: http://svn.apache.org/viewvc?rev=899388&view=rev
Log:
Spelling/JavaDoc fixes

Modified:
    incubator/shiro/trunk/core/src/main/java/org/apache/shiro/authz/Permission.java
    incubator/shiro/trunk/core/src/main/java/org/apache/shiro/session/Session.java

Modified: incubator/shiro/trunk/core/src/main/java/org/apache/shiro/authz/Permission.java
URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/core/src/main/java/org/apache/shiro/authz/Permission.java?rev=899388&r1=899387&r2=899388&view=diff
==============================================================================
--- incubator/shiro/trunk/core/src/main/java/org/apache/shiro/authz/Permission.java (original)
+++ incubator/shiro/trunk/core/src/main/java/org/apache/shiro/authz/Permission.java Thu Jan 14 20:13:01 2010
@@ -23,26 +23,26 @@
  * granular, or atomic, unit in a system's security policy and is the cornerstone upon which fine-grained security
  * models are built.
  * <p/>
- * <p>It is important to understand a Permission instance only represents functionality or access - it does not grant it.
+ * It is important to understand a Permission instance only represents functionality or access - it does not grant it.
  * Granting access to an application functionality or a particular resource is done by the application's security
  * configuration, typically by assigning Permissions to users, roles and/or groups.
  * <p/>
- * <p>Most typical systems are what the Shiro team calls <em>role-based</em> in nature, where a role represents
+ * Most typical systems are what the Shiro team calls <em>role-based</em> in nature, where a role represents
  * common behavior for certain user types.  For example, a system might have an <em>Aministrator</em> role, a
  * <em>User</em> or <em>Guest</em> roles, etc.
  * <p/>
- * <p>But if you have a dynamic security model, where roles can be created and deleted at runtime, you can't hard-code
+ * But if you have a dynamic security model, where roles can be created and deleted at runtime, you can't hard-code
  * role names in your code.  In this environment, roles themselves aren't aren't very useful.  What matters is what
  * <em>permissions</em> are assigned to these roles.
  * <p/>
- * <p>Under this paradigm, permissions are immutable and reflect an application's raw functionality
+ * Under this paradigm, permissions are immutable and reflect an application's raw functionality
  * (opening files, accessing a web URL, creating users, etc).  This is what allows a system's security policy
- * to be dynamic: because Permission classes represent raw functionality and only change when the application's
+ * to be dynamic: because Permissions represent raw functionality and only change when the application's
  * source code changes, they are immutable at runtime - they represent 'what' the system can do.  Roles, users, and
  * groups are the 'who' of the application.  Determining 'who' can do 'what' then becomes a simple exercise of
  * associating Permissions to roles, users, and groups in some way.
  * <p/>
- * <p>Most applications do this by associating a named role with permissions (i.e. a role 'has a' collection of
+ * Most applications do this by associating a named role with permissions (i.e. a role 'has a' collection of
  * Permissions) and then associate users with roles (i.e. a user 'has a' collection of roles) so that by transitive
  * association, the user 'has' the permissions in their roles.  There are numerous variations on this theme
  * (permissions assigned directly to users, or assigned to groups, and users added to groups and these groups in turn
@@ -50,13 +50,13 @@
  * and groups can all be created, configured and/or deleted at runtime.  This enables  an extremely powerful security
  * model.
  * <p/>
- * <p>A benefit to Shiro is that, although it assumes most systems are based on these types of static role or
+ * A benefit to Shiro is that, although it assumes most systems are based on these types of static role or
  * dynamic role w/ permission schemes, it does not require a system to model their security data this way - all
- * Permission checks are relegated to {@link org.apache.shiro.realm.Realm} implementations, and only those implementatons
- * really determine how a user 'has' a permission or not.  The Realm could use the semantics described here, or it
- * could utilize some other mechanism entirely - it is always up to the application developer.
+ * Permission checks are relegated to {@link org.apache.shiro.realm.Realm} implementations, and only those
+ * implementations really determine how a user 'has' a permission or not.  The Realm could use the semantics described
+ * here, or it could utilize some other mechanism entirely - it is always up to the application developer.
  * <p/>
- * <p>Shiro provides a very powerful default implementation of this interface in the form of the
+ * Shiro provides a very powerful default implementation of this interface in the form of the
  * {@link org.apache.shiro.authz.permission.WildcardPermission WildcardPermission}.  We highly recommend that you
  * investigate this class before trying to implement your own <code>Permission</code>s.
  *
@@ -67,20 +67,20 @@
 public interface Permission {
 
     /**
-     * Returns <tt>true</tt> if this current instance <em>implies</em> all the functionality and/or resource access
-     * described by the specified <tt>Permission</tt> argument, <tt>false</tt> otherwise.
+     * Returns {@code true} if this current instance <em>implies</em> all the functionality and/or resource access
+     * described by the specified {@code Permission} argument, {@code false} otherwise.
      * <p/>
      * <p>That is, this current instance must be exactly equal to or a <em>superset</em> of the functionalty
-     * and/or resource access described by the given <tt>Permission</tt> argument.  Yet another way of saying this
+     * and/or resource access described by the given {@code Permission} argument.  Yet another way of saying this
      * would be:
      * <p/>
-     * <p>If &quot;permission1 implies permission2&quot;, (i.e. <code>permission1.implies( permission2 ) )</code>,
-     * then any Subject granted <tt>permission1</tt> would have ability greater than or equal to that defined by
-     * <tt>permission2</tt>.
+     * <p>If &quot;permission1 implies permission2&quot;, i.e. <code>permission1.implies(permission2)</code> ,
+     * then any Subject granted {@code permission1} would have ability greater than or equal to that defined by
+     * {@code permission2}.
      *
      * @param p the permission to check for behavior/functionality comparison.
-     * @return <tt>true</tt> if this current instance <em>implies</em> all the functionality and/or resource access
-     *         described by the specified <tt>Permission</tt> argument, <tt>false</tt> otherwise.
+     * @return {@code true} if this current instance <em>implies</em> all the functionality and/or resource access
+     *         described by the specified {@code Permission} argument, {@code false} otherwise.
      */
     boolean implies(Permission p);
 }

Modified: incubator/shiro/trunk/core/src/main/java/org/apache/shiro/session/Session.java
URL: http://svn.apache.org/viewvc/incubator/shiro/trunk/core/src/main/java/org/apache/shiro/session/Session.java?rev=899388&r1=899387&r2=899388&view=diff
==============================================================================
--- incubator/shiro/trunk/core/src/main/java/org/apache/shiro/session/Session.java (original)
+++ incubator/shiro/trunk/core/src/main/java/org/apache/shiro/session/Session.java Thu Jan 14 20:13:01 2010
@@ -41,7 +41,7 @@
      * Returns the unique identifier assigned by the system upon session creation.
      * <p/>
      * All return values from this method are expected to have proper {@code toString()},
-     * {@code equals()}, and {@code hashCode()} implementations. Good candiadates for such
+     * {@code equals()}, and {@code hashCode()} implementations. Good candidates for such
      * an identifier are {@link java.util.UUID UUID}s, {@link java.lang.Integer Integer}s, and
      * {@link java.lang.String String}s.
      *