<commit_before>H57 Shiro Example
=================

A Spring MVC 3.1.0 sample, leveraging Shiro 1.20, myBatis 3.0.6, and JSR-303 Validation (Hibernate reference implementation).

When playing around with these technologies, I found it challenging to find a solid sample implementation that I could wrap my head around. So I decided to to write one myself and then use it to write some tutorials.

Website: [Google +] (https://plus.google.com/u/0/113383164169998763938/about)

Bugs/Suggestions: [Google +] (https://plus.google.com/u/0/113383164169998763938/about) (till I have need of something more mature)

Compilation
-----------

We use maven to handle our dependencies.

* Install [Maven 3](http://maven.apache.org/download.html)
* Check out this repo and: `mvn clean package`

Installation
------------
You will need an empty mysql database to actually run this code. By default, we expect:
* url=jdbc:mysql://localhost/h57_shiro
* username=h57_shiro
* password=<PASSWORD>

However, you can change this in the [myBatis Development Properties file](https://github.com/bubba-h57/H57_Shiro/blob/master/src/main/resources/migrations/environments/development.properties) the user will need ownership to create tables, etc.

Once your database is setup, you can run: mvn migration:bootstrap

This will create and autopopulate all needed tables as per the [myBatis Bootstrap Script] (https://github.com/bubba-h57/H57_Shiro/blob/master/src/main/resources/migrations/scripts/bootstrap.sql)
Coding and Pull Request Conventions
-----------

* We generally follow the Java coding standards.
* No Spaces; use Tabs instead.
* No trailing whitespaces.
* No CRLF line endings, LF only, put your gits 'core.autocrlf' on 'true'.
* No 80 column limit or 'weird' midstatement newlines.
* The number of commits in a pull request should be kept to a minimum (squish them into one most of the time - use common sense!).
* No merges should be included in pull requests unless the pull request's purpose is a merge.
* Pull requests should be tested (does it compile? AND does it work?) before submission.
* Any major additions should have documentation ready and provided if applicable (this is usually the case).
* Most pull requests should be accompanied by a corresponding Google Plus post so we can associate commits with issues (this is primarily for changelog generation).
* Try to follow test driven development where applicable.

If you make changes or add classes it is mandatory to:
<commit_msg>Formatting Fix<commit_after>H57 Shiro Example
=================

A Spring MVC 3.1.0 sample, leveraging Shiro 1.20, myBatis 3.0.6, and JSR-303 Validation (Hibernate reference implementation).

When playing around with these technologies, I found it challenging to find a solid sample implementation that I could wrap my head around. So I decided to to write one myself and then use it to write some tutorials.

Website: [Google +] (https://plus.google.com/u/0/113383164169998763938/about)

Bugs/Suggestions: [Google +] (https://plus.google.com/u/0/113383164169998763938/about) (till I have need of something more mature)

Compilation
-----------

We use maven to handle our dependencies.

* Install [Maven 3](http://maven.apache.org/download.html)
* Check out this repo and: `mvn clean package`

Installation
------------
You will need an empty mysql database to actually run this code. By default, we expect:

* url=jdbc:mysql://localhost/h57_shiro
* username=h57_shiro
* password=<PASSWORD>

However, you can change this in the [myBatis Development Properties file](https://github.com/bubba-h57/H57_Shiro/blob/master/src/main/resources/migrations/environments/development.properties) the user will need ownership to create tables, etc.

Once your database is setup, you can run: mvn migration:bootstrap

This will create and autopopulate all needed tables as per the [myBatis Bootstrap Script] (https://github.com/bubba-h57/H57_Shiro/blob/master/src/main/resources/migrations/scripts/bootstrap.sql)

Coding and Pull Request Conventions
-----------

* We generally follow the Java coding standards.
* No Spaces; use Tabs instead.
* No trailing whitespaces.
* No CRLF line endings, LF only, put your gits 'core.autocrlf' on 'true'.
* No 80 column limit or 'weird' midstatement newlines.
* The number of commits in a pull request should be kept to a minimum (squish them into one most of the time - use common sense!).
* No merges should be included in pull requests unless the pull request's purpose is a merge.
* Pull requests should be tested (does it compile? AND does it work?) before submission.
* Any major additions should have documentation ready and provided if applicable (this is usually the case).
* Most pull requests should be accompanied by a corresponding Google Plus post so we can associate commits with issues (this is primarily for changelog generation).
* Try to follow test driven development where applicable.

If you make changes or add classes it is mandatory to:

{'fraction_non_alphanumeric': 0.09129298210335814, 'fraction_numerical': 0.029358536094912527, 'mean_word_length': 4.359913793103448, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6824938', 'n_tokens_mistral': 1465, 'n_tokens_neox': 1344, 'n_words': 623}