You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

GitBlitWebApp.java 10KB

Ticket tracker with patchset contributions A basic issue tracker styled as a hybrid of GitHub and BitBucket issues. You may attach commits to an existing ticket or you can push a single commit to create a *proposal* ticket. Tickets keep track of patchsets (one or more commits) and allow patchset rewriting (rebase, amend, squash) by detecing the non-fast-forward update and assigning a new patchset number to the new commits. Ticket tracker -------------- The ticket tracker stores tickets as an append-only journal of changes. The journals are deserialized and a ticket is built by applying the journal entries. Tickets are indexed using Apache Lucene and all queries and searches are executed against this Lucene index. There is one trade-off to this persistence design: user attributions are non-relational. What does that mean? Each journal entry stores the username of the author. If the username changes in the user service, the journal entry will not reflect that change because the values are hard-coded. Here are a few reasons/justifications for this design choice: 1. commit identifications (author, committer, tagger) are non-relational 2. maintains the KISS principle 3. your favorite text editor can still be your administration tool Persistence Choices ------------------- **FileTicketService**: stores journals on the filesystem **BranchTicketService**: stores journals on an orphan branch **RedisTicketService**: stores journals in a Redis key-value datastore It should be relatively straight-forward to develop other backends (MongoDB, etc) as long as the journal design is preserved. Pushing Commits --------------- Each push to a ticket is identified as a patchset revision. A patchset revision may add commits to the patchset (fast-forward) OR a patchset revision may rewrite history (rebase, squash, rebase+squash, or amend). Patchset authors should not be afraid to polish, revise, and rewrite their code before merging into the proposed branch. Gitblit will create one ref for each patchset. These refs are updated for fast-forward pushes or created for rewrites. They are formatted as `refs/tickets/{shard}/{id}/{patchset}`. The *shard* is the last two digits of the id. If the id < 10, prefix a 0. The *shard* is always two digits long. The shard's purpose is to ensure Gitblit doesn't exceed any filesystem directory limits for file creation. **Creating a Proposal Ticket** You may create a new change proposal ticket just by pushing a **single commit** to `refs/for/{branch}` where branch is the proposed integration branch OR `refs/for/new` or `refs/for/default` which both will use the default repository branch. git push origin HEAD:refs/for/new **Updating a Patchset** The safe way to update an existing patchset is to push to the patchset ref. git push origin HEAD:refs/heads/ticket/{id} This ensures you do not accidentally create a new patchset in the event that the patchset was updated after you last pulled. The not-so-safe way to update an existing patchset is to push using the magic ref. git push origin HEAD:refs/for/{id} This push ref will update an exisitng patchset OR create a new patchset if the update is non-fast-forward. **Rebasing, Squashing, Amending** Gitblit makes rebasing, squashing, and amending patchsets easy. Normally, pushing a non-fast-forward update would require rewind (RW+) repository permissions. Gitblit provides a magic ref which will allow ticket participants to rewrite a ticket patchset as long as the ticket is open. git push origin HEAD:refs/for/{id} Pushing changes to this ref allows the patchset authors to rebase, squash, or amend the patchset commits without requiring client-side use of the *--force* flag on push AND without requiring RW+ permission to the repository. Since each patchset is tracked with a ref it is easy to recover from accidental non-fast-forward updates. Features -------- - Ticket tracker with status changes and responsible assignments - Patchset revision scoring mechanism - Update/Rewrite patchset handling - Close-on-push detection - Server-side Merge button for simple merges - Comments with Markdown syntax support - Rich mail notifications - Voting - Mentions - Watch lists - Querying - Searches - Partial miletones support - Multiple backend options
10 years ago
Ticket tracker with patchset contributions A basic issue tracker styled as a hybrid of GitHub and BitBucket issues. You may attach commits to an existing ticket or you can push a single commit to create a *proposal* ticket. Tickets keep track of patchsets (one or more commits) and allow patchset rewriting (rebase, amend, squash) by detecing the non-fast-forward update and assigning a new patchset number to the new commits. Ticket tracker -------------- The ticket tracker stores tickets as an append-only journal of changes. The journals are deserialized and a ticket is built by applying the journal entries. Tickets are indexed using Apache Lucene and all queries and searches are executed against this Lucene index. There is one trade-off to this persistence design: user attributions are non-relational. What does that mean? Each journal entry stores the username of the author. If the username changes in the user service, the journal entry will not reflect that change because the values are hard-coded. Here are a few reasons/justifications for this design choice: 1. commit identifications (author, committer, tagger) are non-relational 2. maintains the KISS principle 3. your favorite text editor can still be your administration tool Persistence Choices ------------------- **FileTicketService**: stores journals on the filesystem **BranchTicketService**: stores journals on an orphan branch **RedisTicketService**: stores journals in a Redis key-value datastore It should be relatively straight-forward to develop other backends (MongoDB, etc) as long as the journal design is preserved. Pushing Commits --------------- Each push to a ticket is identified as a patchset revision. A patchset revision may add commits to the patchset (fast-forward) OR a patchset revision may rewrite history (rebase, squash, rebase+squash, or amend). Patchset authors should not be afraid to polish, revise, and rewrite their code before merging into the proposed branch. Gitblit will create one ref for each patchset. These refs are updated for fast-forward pushes or created for rewrites. They are formatted as `refs/tickets/{shard}/{id}/{patchset}`. The *shard* is the last two digits of the id. If the id < 10, prefix a 0. The *shard* is always two digits long. The shard's purpose is to ensure Gitblit doesn't exceed any filesystem directory limits for file creation. **Creating a Proposal Ticket** You may create a new change proposal ticket just by pushing a **single commit** to `refs/for/{branch}` where branch is the proposed integration branch OR `refs/for/new` or `refs/for/default` which both will use the default repository branch. git push origin HEAD:refs/for/new **Updating a Patchset** The safe way to update an existing patchset is to push to the patchset ref. git push origin HEAD:refs/heads/ticket/{id} This ensures you do not accidentally create a new patchset in the event that the patchset was updated after you last pulled. The not-so-safe way to update an existing patchset is to push using the magic ref. git push origin HEAD:refs/for/{id} This push ref will update an exisitng patchset OR create a new patchset if the update is non-fast-forward. **Rebasing, Squashing, Amending** Gitblit makes rebasing, squashing, and amending patchsets easy. Normally, pushing a non-fast-forward update would require rewind (RW+) repository permissions. Gitblit provides a magic ref which will allow ticket participants to rewrite a ticket patchset as long as the ticket is open. git push origin HEAD:refs/for/{id} Pushing changes to this ref allows the patchset authors to rebase, squash, or amend the patchset commits without requiring client-side use of the *--force* flag on push AND without requiring RW+ permission to the repository. Since each patchset is tracked with a ref it is easy to recover from accidental non-fast-forward updates. Features -------- - Ticket tracker with status changes and responsible assignments - Patchset revision scoring mechanism - Update/Rewrite patchset handling - Close-on-push detection - Server-side Merge button for simple merges - Comments with Markdown syntax support - Rich mail notifications - Voting - Mentions - Watch lists - Querying - Searches - Partial miletones support - Multiple backend options
10 years ago
Ticket tracker with patchset contributions A basic issue tracker styled as a hybrid of GitHub and BitBucket issues. You may attach commits to an existing ticket or you can push a single commit to create a *proposal* ticket. Tickets keep track of patchsets (one or more commits) and allow patchset rewriting (rebase, amend, squash) by detecing the non-fast-forward update and assigning a new patchset number to the new commits. Ticket tracker -------------- The ticket tracker stores tickets as an append-only journal of changes. The journals are deserialized and a ticket is built by applying the journal entries. Tickets are indexed using Apache Lucene and all queries and searches are executed against this Lucene index. There is one trade-off to this persistence design: user attributions are non-relational. What does that mean? Each journal entry stores the username of the author. If the username changes in the user service, the journal entry will not reflect that change because the values are hard-coded. Here are a few reasons/justifications for this design choice: 1. commit identifications (author, committer, tagger) are non-relational 2. maintains the KISS principle 3. your favorite text editor can still be your administration tool Persistence Choices ------------------- **FileTicketService**: stores journals on the filesystem **BranchTicketService**: stores journals on an orphan branch **RedisTicketService**: stores journals in a Redis key-value datastore It should be relatively straight-forward to develop other backends (MongoDB, etc) as long as the journal design is preserved. Pushing Commits --------------- Each push to a ticket is identified as a patchset revision. A patchset revision may add commits to the patchset (fast-forward) OR a patchset revision may rewrite history (rebase, squash, rebase+squash, or amend). Patchset authors should not be afraid to polish, revise, and rewrite their code before merging into the proposed branch. Gitblit will create one ref for each patchset. These refs are updated for fast-forward pushes or created for rewrites. They are formatted as `refs/tickets/{shard}/{id}/{patchset}`. The *shard* is the last two digits of the id. If the id < 10, prefix a 0. The *shard* is always two digits long. The shard's purpose is to ensure Gitblit doesn't exceed any filesystem directory limits for file creation. **Creating a Proposal Ticket** You may create a new change proposal ticket just by pushing a **single commit** to `refs/for/{branch}` where branch is the proposed integration branch OR `refs/for/new` or `refs/for/default` which both will use the default repository branch. git push origin HEAD:refs/for/new **Updating a Patchset** The safe way to update an existing patchset is to push to the patchset ref. git push origin HEAD:refs/heads/ticket/{id} This ensures you do not accidentally create a new patchset in the event that the patchset was updated after you last pulled. The not-so-safe way to update an existing patchset is to push using the magic ref. git push origin HEAD:refs/for/{id} This push ref will update an exisitng patchset OR create a new patchset if the update is non-fast-forward. **Rebasing, Squashing, Amending** Gitblit makes rebasing, squashing, and amending patchsets easy. Normally, pushing a non-fast-forward update would require rewind (RW+) repository permissions. Gitblit provides a magic ref which will allow ticket participants to rewrite a ticket patchset as long as the ticket is open. git push origin HEAD:refs/for/{id} Pushing changes to this ref allows the patchset authors to rebase, squash, or amend the patchset commits without requiring client-side use of the *--force* flag on push AND without requiring RW+ permission to the repository. Since each patchset is tracked with a ref it is easy to recover from accidental non-fast-forward updates. Features -------- - Ticket tracker with status changes and responsible assignments - Patchset revision scoring mechanism - Update/Rewrite patchset handling - Close-on-push detection - Server-side Merge button for simple merges - Comments with Markdown syntax support - Rich mail notifications - Voting - Mentions - Watch lists - Querying - Searches - Partial miletones support - Multiple backend options
10 years ago
Ticket tracker with patchset contributions A basic issue tracker styled as a hybrid of GitHub and BitBucket issues. You may attach commits to an existing ticket or you can push a single commit to create a *proposal* ticket. Tickets keep track of patchsets (one or more commits) and allow patchset rewriting (rebase, amend, squash) by detecing the non-fast-forward update and assigning a new patchset number to the new commits. Ticket tracker -------------- The ticket tracker stores tickets as an append-only journal of changes. The journals are deserialized and a ticket is built by applying the journal entries. Tickets are indexed using Apache Lucene and all queries and searches are executed against this Lucene index. There is one trade-off to this persistence design: user attributions are non-relational. What does that mean? Each journal entry stores the username of the author. If the username changes in the user service, the journal entry will not reflect that change because the values are hard-coded. Here are a few reasons/justifications for this design choice: 1. commit identifications (author, committer, tagger) are non-relational 2. maintains the KISS principle 3. your favorite text editor can still be your administration tool Persistence Choices ------------------- **FileTicketService**: stores journals on the filesystem **BranchTicketService**: stores journals on an orphan branch **RedisTicketService**: stores journals in a Redis key-value datastore It should be relatively straight-forward to develop other backends (MongoDB, etc) as long as the journal design is preserved. Pushing Commits --------------- Each push to a ticket is identified as a patchset revision. A patchset revision may add commits to the patchset (fast-forward) OR a patchset revision may rewrite history (rebase, squash, rebase+squash, or amend). Patchset authors should not be afraid to polish, revise, and rewrite their code before merging into the proposed branch. Gitblit will create one ref for each patchset. These refs are updated for fast-forward pushes or created for rewrites. They are formatted as `refs/tickets/{shard}/{id}/{patchset}`. The *shard* is the last two digits of the id. If the id < 10, prefix a 0. The *shard* is always two digits long. The shard's purpose is to ensure Gitblit doesn't exceed any filesystem directory limits for file creation. **Creating a Proposal Ticket** You may create a new change proposal ticket just by pushing a **single commit** to `refs/for/{branch}` where branch is the proposed integration branch OR `refs/for/new` or `refs/for/default` which both will use the default repository branch. git push origin HEAD:refs/for/new **Updating a Patchset** The safe way to update an existing patchset is to push to the patchset ref. git push origin HEAD:refs/heads/ticket/{id} This ensures you do not accidentally create a new patchset in the event that the patchset was updated after you last pulled. The not-so-safe way to update an existing patchset is to push using the magic ref. git push origin HEAD:refs/for/{id} This push ref will update an exisitng patchset OR create a new patchset if the update is non-fast-forward. **Rebasing, Squashing, Amending** Gitblit makes rebasing, squashing, and amending patchsets easy. Normally, pushing a non-fast-forward update would require rewind (RW+) repository permissions. Gitblit provides a magic ref which will allow ticket participants to rewrite a ticket patchset as long as the ticket is open. git push origin HEAD:refs/for/{id} Pushing changes to this ref allows the patchset authors to rebase, squash, or amend the patchset commits without requiring client-side use of the *--force* flag on push AND without requiring RW+ permission to the repository. Since each patchset is tracked with a ref it is easy to recover from accidental non-fast-forward updates. Features -------- - Ticket tracker with status changes and responsible assignments - Patchset revision scoring mechanism - Update/Rewrite patchset handling - Close-on-push detection - Server-side Merge button for simple merges - Comments with Markdown syntax support - Rich mail notifications - Voting - Mentions - Watch lists - Querying - Searches - Partial miletones support - Multiple backend options
10 years ago
Ticket tracker with patchset contributions A basic issue tracker styled as a hybrid of GitHub and BitBucket issues. You may attach commits to an existing ticket or you can push a single commit to create a *proposal* ticket. Tickets keep track of patchsets (one or more commits) and allow patchset rewriting (rebase, amend, squash) by detecing the non-fast-forward update and assigning a new patchset number to the new commits. Ticket tracker -------------- The ticket tracker stores tickets as an append-only journal of changes. The journals are deserialized and a ticket is built by applying the journal entries. Tickets are indexed using Apache Lucene and all queries and searches are executed against this Lucene index. There is one trade-off to this persistence design: user attributions are non-relational. What does that mean? Each journal entry stores the username of the author. If the username changes in the user service, the journal entry will not reflect that change because the values are hard-coded. Here are a few reasons/justifications for this design choice: 1. commit identifications (author, committer, tagger) are non-relational 2. maintains the KISS principle 3. your favorite text editor can still be your administration tool Persistence Choices ------------------- **FileTicketService**: stores journals on the filesystem **BranchTicketService**: stores journals on an orphan branch **RedisTicketService**: stores journals in a Redis key-value datastore It should be relatively straight-forward to develop other backends (MongoDB, etc) as long as the journal design is preserved. Pushing Commits --------------- Each push to a ticket is identified as a patchset revision. A patchset revision may add commits to the patchset (fast-forward) OR a patchset revision may rewrite history (rebase, squash, rebase+squash, or amend). Patchset authors should not be afraid to polish, revise, and rewrite their code before merging into the proposed branch. Gitblit will create one ref for each patchset. These refs are updated for fast-forward pushes or created for rewrites. They are formatted as `refs/tickets/{shard}/{id}/{patchset}`. The *shard* is the last two digits of the id. If the id < 10, prefix a 0. The *shard* is always two digits long. The shard's purpose is to ensure Gitblit doesn't exceed any filesystem directory limits for file creation. **Creating a Proposal Ticket** You may create a new change proposal ticket just by pushing a **single commit** to `refs/for/{branch}` where branch is the proposed integration branch OR `refs/for/new` or `refs/for/default` which both will use the default repository branch. git push origin HEAD:refs/for/new **Updating a Patchset** The safe way to update an existing patchset is to push to the patchset ref. git push origin HEAD:refs/heads/ticket/{id} This ensures you do not accidentally create a new patchset in the event that the patchset was updated after you last pulled. The not-so-safe way to update an existing patchset is to push using the magic ref. git push origin HEAD:refs/for/{id} This push ref will update an exisitng patchset OR create a new patchset if the update is non-fast-forward. **Rebasing, Squashing, Amending** Gitblit makes rebasing, squashing, and amending patchsets easy. Normally, pushing a non-fast-forward update would require rewind (RW+) repository permissions. Gitblit provides a magic ref which will allow ticket participants to rewrite a ticket patchset as long as the ticket is open. git push origin HEAD:refs/for/{id} Pushing changes to this ref allows the patchset authors to rebase, squash, or amend the patchset commits without requiring client-side use of the *--force* flag on push AND without requiring RW+ permission to the repository. Since each patchset is tracked with a ref it is easy to recover from accidental non-fast-forward updates. Features -------- - Ticket tracker with status changes and responsible assignments - Patchset revision scoring mechanism - Update/Rewrite patchset handling - Close-on-push detection - Server-side Merge button for simple merges - Comments with Markdown syntax support - Rich mail notifications - Voting - Mentions - Watch lists - Querying - Searches - Partial miletones support - Multiple backend options
10 years ago
Ticket tracker with patchset contributions A basic issue tracker styled as a hybrid of GitHub and BitBucket issues. You may attach commits to an existing ticket or you can push a single commit to create a *proposal* ticket. Tickets keep track of patchsets (one or more commits) and allow patchset rewriting (rebase, amend, squash) by detecing the non-fast-forward update and assigning a new patchset number to the new commits. Ticket tracker -------------- The ticket tracker stores tickets as an append-only journal of changes. The journals are deserialized and a ticket is built by applying the journal entries. Tickets are indexed using Apache Lucene and all queries and searches are executed against this Lucene index. There is one trade-off to this persistence design: user attributions are non-relational. What does that mean? Each journal entry stores the username of the author. If the username changes in the user service, the journal entry will not reflect that change because the values are hard-coded. Here are a few reasons/justifications for this design choice: 1. commit identifications (author, committer, tagger) are non-relational 2. maintains the KISS principle 3. your favorite text editor can still be your administration tool Persistence Choices ------------------- **FileTicketService**: stores journals on the filesystem **BranchTicketService**: stores journals on an orphan branch **RedisTicketService**: stores journals in a Redis key-value datastore It should be relatively straight-forward to develop other backends (MongoDB, etc) as long as the journal design is preserved. Pushing Commits --------------- Each push to a ticket is identified as a patchset revision. A patchset revision may add commits to the patchset (fast-forward) OR a patchset revision may rewrite history (rebase, squash, rebase+squash, or amend). Patchset authors should not be afraid to polish, revise, and rewrite their code before merging into the proposed branch. Gitblit will create one ref for each patchset. These refs are updated for fast-forward pushes or created for rewrites. They are formatted as `refs/tickets/{shard}/{id}/{patchset}`. The *shard* is the last two digits of the id. If the id < 10, prefix a 0. The *shard* is always two digits long. The shard's purpose is to ensure Gitblit doesn't exceed any filesystem directory limits for file creation. **Creating a Proposal Ticket** You may create a new change proposal ticket just by pushing a **single commit** to `refs/for/{branch}` where branch is the proposed integration branch OR `refs/for/new` or `refs/for/default` which both will use the default repository branch. git push origin HEAD:refs/for/new **Updating a Patchset** The safe way to update an existing patchset is to push to the patchset ref. git push origin HEAD:refs/heads/ticket/{id} This ensures you do not accidentally create a new patchset in the event that the patchset was updated after you last pulled. The not-so-safe way to update an existing patchset is to push using the magic ref. git push origin HEAD:refs/for/{id} This push ref will update an exisitng patchset OR create a new patchset if the update is non-fast-forward. **Rebasing, Squashing, Amending** Gitblit makes rebasing, squashing, and amending patchsets easy. Normally, pushing a non-fast-forward update would require rewind (RW+) repository permissions. Gitblit provides a magic ref which will allow ticket participants to rewrite a ticket patchset as long as the ticket is open. git push origin HEAD:refs/for/{id} Pushing changes to this ref allows the patchset authors to rebase, squash, or amend the patchset commits without requiring client-side use of the *--force* flag on push AND without requiring RW+ permission to the repository. Since each patchset is tracked with a ref it is easy to recover from accidental non-fast-forward updates. Features -------- - Ticket tracker with status changes and responsible assignments - Patchset revision scoring mechanism - Update/Rewrite patchset handling - Close-on-push detection - Server-side Merge button for simple merges - Comments with Markdown syntax support - Rich mail notifications - Voting - Mentions - Watch lists - Querying - Searches - Partial miletones support - Multiple backend options
10 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335
  1. /*
  2. * Copyright 2011 gitblit.com.
  3. *
  4. * Licensed under the Apache License, Version 2.0 (the "License");
  5. * you may not use this file except in compliance with the License.
  6. * You may obtain a copy of the License at
  7. *
  8. * http://www.apache.org/licenses/LICENSE-2.0
  9. *
  10. * Unless required by applicable law or agreed to in writing, software
  11. * distributed under the License is distributed on an "AS IS" BASIS,
  12. * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  13. * See the License for the specific language governing permissions and
  14. * limitations under the License.
  15. */
  16. package com.gitblit.wicket;
  17. import java.util.Date;
  18. import java.util.HashMap;
  19. import java.util.Locale;
  20. import java.util.Map;
  21. import java.util.TimeZone;
  22. import org.apache.wicket.Application;
  23. import org.apache.wicket.Request;
  24. import org.apache.wicket.Response;
  25. import org.apache.wicket.Session;
  26. import org.apache.wicket.markup.html.WebPage;
  27. import org.apache.wicket.protocol.http.WebApplication;
  28. import com.gitblit.IStoredSettings;
  29. import com.gitblit.Keys;
  30. import com.gitblit.manager.IAuthenticationManager;
  31. import com.gitblit.manager.IFederationManager;
  32. import com.gitblit.manager.IGitblit;
  33. import com.gitblit.manager.INotificationManager;
  34. import com.gitblit.manager.IPluginManager;
  35. import com.gitblit.manager.IProjectManager;
  36. import com.gitblit.manager.IRepositoryManager;
  37. import com.gitblit.manager.IRuntimeManager;
  38. import com.gitblit.manager.IUserManager;
  39. import com.gitblit.tickets.ITicketService;
  40. import com.gitblit.transport.ssh.IPublicKeyManager;
  41. import com.gitblit.wicket.pages.ActivityPage;
  42. import com.gitblit.wicket.pages.BlamePage;
  43. import com.gitblit.wicket.pages.BlobDiffPage;
  44. import com.gitblit.wicket.pages.BlobPage;
  45. import com.gitblit.wicket.pages.BranchesPage;
  46. import com.gitblit.wicket.pages.CommitDiffPage;
  47. import com.gitblit.wicket.pages.CommitPage;
  48. import com.gitblit.wicket.pages.ComparePage;
  49. import com.gitblit.wicket.pages.DocPage;
  50. import com.gitblit.wicket.pages.DocsPage;
  51. import com.gitblit.wicket.pages.EditTicketPage;
  52. import com.gitblit.wicket.pages.ExportTicketPage;
  53. import com.gitblit.wicket.pages.FederationRegistrationPage;
  54. import com.gitblit.wicket.pages.ForkPage;
  55. import com.gitblit.wicket.pages.ForksPage;
  56. import com.gitblit.wicket.pages.GitSearchPage;
  57. import com.gitblit.wicket.pages.HistoryPage;
  58. import com.gitblit.wicket.pages.LogPage;
  59. import com.gitblit.wicket.pages.LogoutPage;
  60. import com.gitblit.wicket.pages.LuceneSearchPage;
  61. import com.gitblit.wicket.pages.MetricsPage;
  62. import com.gitblit.wicket.pages.MyDashboardPage;
  63. import com.gitblit.wicket.pages.NewTicketPage;
  64. import com.gitblit.wicket.pages.OverviewPage;
  65. import com.gitblit.wicket.pages.PatchPage;
  66. import com.gitblit.wicket.pages.ProjectPage;
  67. import com.gitblit.wicket.pages.ProjectsPage;
  68. import com.gitblit.wicket.pages.RawPage;
  69. import com.gitblit.wicket.pages.ReflogPage;
  70. import com.gitblit.wicket.pages.RepositoriesPage;
  71. import com.gitblit.wicket.pages.ReviewProposalPage;
  72. import com.gitblit.wicket.pages.SummaryPage;
  73. import com.gitblit.wicket.pages.TagPage;
  74. import com.gitblit.wicket.pages.TagsPage;
  75. import com.gitblit.wicket.pages.TicketsPage;
  76. import com.gitblit.wicket.pages.TreePage;
  77. import com.gitblit.wicket.pages.UserPage;
  78. import com.gitblit.wicket.pages.UsersPage;
  79. public class GitBlitWebApp extends WebApplication {
  80. private final Class<? extends WebPage> homePageClass = MyDashboardPage.class;
  81. private final Map<String, CacheControl> cacheablePages = new HashMap<String, CacheControl>();
  82. private final IStoredSettings settings;
  83. private final IRuntimeManager runtimeManager;
  84. private final IPluginManager pluginManager;
  85. private final INotificationManager notificationManager;
  86. private final IUserManager userManager;
  87. private final IAuthenticationManager authenticationManager;
  88. private final IPublicKeyManager publicKeyManager;
  89. private final IRepositoryManager repositoryManager;
  90. private final IProjectManager projectManager;
  91. private final IFederationManager federationManager;
  92. private final IGitblit gitblit;
  93. public GitBlitWebApp(
  94. IRuntimeManager runtimeManager,
  95. IPluginManager pluginManager,
  96. INotificationManager notificationManager,
  97. IUserManager userManager,
  98. IAuthenticationManager authenticationManager,
  99. IPublicKeyManager publicKeyManager,
  100. IRepositoryManager repositoryManager,
  101. IProjectManager projectManager,
  102. IFederationManager federationManager,
  103. IGitblit gitblit) {
  104. super();
  105. this.settings = runtimeManager.getSettings();
  106. this.runtimeManager = runtimeManager;
  107. this.pluginManager = pluginManager;
  108. this.notificationManager = notificationManager;
  109. this.userManager = userManager;
  110. this.authenticationManager = authenticationManager;
  111. this.publicKeyManager = publicKeyManager;
  112. this.repositoryManager = repositoryManager;
  113. this.projectManager = projectManager;
  114. this.federationManager = federationManager;
  115. this.gitblit = gitblit;
  116. }
  117. @Override
  118. public void init() {
  119. super.init();
  120. // Setup page authorization mechanism
  121. boolean useAuthentication = settings.getBoolean(Keys.web.authenticateViewPages, false)
  122. || settings.getBoolean(Keys.web.authenticateAdminPages, false);
  123. if (useAuthentication) {
  124. AuthorizationStrategy authStrategy = new AuthorizationStrategy(settings, homePageClass);
  125. getSecuritySettings().setAuthorizationStrategy(authStrategy);
  126. getSecuritySettings().setUnauthorizedComponentInstantiationListener(authStrategy);
  127. }
  128. // Grab Browser info (like timezone, etc)
  129. if (settings.getBoolean(Keys.web.useClientTimezone, false)) {
  130. getRequestCycleSettings().setGatherExtendedBrowserInfo(true);
  131. }
  132. // configure the resource cache duration to 90 days for deployment
  133. if (!isDebugMode()) {
  134. getResourceSettings().setDefaultCacheDuration(90 * 86400);
  135. }
  136. // setup the standard gitweb-ish urls
  137. mount("/repositories", RepositoriesPage.class);
  138. mount("/overview", OverviewPage.class, "r", "h");
  139. mount("/summary", SummaryPage.class, "r");
  140. mount("/reflog", ReflogPage.class, "r", "h");
  141. mount("/commits", LogPage.class, "r", "h");
  142. mount("/log", LogPage.class, "r", "h");
  143. mount("/tags", TagsPage.class, "r");
  144. mount("/branches", BranchesPage.class, "r");
  145. mount("/commit", CommitPage.class, "r", "h");
  146. mount("/tag", TagPage.class, "r", "h");
  147. mount("/tree", TreePage.class, "r", "h", "f");
  148. mount("/blob", BlobPage.class, "r", "h", "f");
  149. mount("/raw", RawPage.class, "r", "h", "f");
  150. mount("/blobdiff", BlobDiffPage.class, "r", "h", "f");
  151. mount("/commitdiff", CommitDiffPage.class, "r", "h");
  152. mount("/compare", ComparePage.class, "r", "h");
  153. mount("/patch", PatchPage.class, "r", "h", "f");
  154. mount("/history", HistoryPage.class, "r", "h", "f");
  155. mount("/search", GitSearchPage.class);
  156. mount("/metrics", MetricsPage.class, "r");
  157. mount("/blame", BlamePage.class, "r", "h", "f");
  158. mount("/users", UsersPage.class);
  159. mount("/logout", LogoutPage.class);
  160. // setup ticket urls
  161. mount("/tickets", TicketsPage.class, "r", "h");
  162. mount("/tickets/new", NewTicketPage.class, "r");
  163. mount("/tickets/edit", EditTicketPage.class, "r", "h");
  164. mount("/tickets/export", ExportTicketPage.class, "r", "h");
  165. // setup the markup document urls
  166. mount("/docs", DocsPage.class, "r");
  167. mount("/doc", DocPage.class, "r", "h", "f");
  168. // federation urls
  169. mount("/proposal", ReviewProposalPage.class, "t");
  170. mount("/registration", FederationRegistrationPage.class, "u", "n");
  171. mount("/activity", ActivityPage.class, "r", "h");
  172. mount("/lucene", LuceneSearchPage.class);
  173. mount("/project", ProjectPage.class, "p");
  174. mount("/projects", ProjectsPage.class);
  175. mount("/user", UserPage.class, "user");
  176. mount("/forks", ForksPage.class, "r");
  177. mount("/fork", ForkPage.class, "r");
  178. getMarkupSettings().setDefaultMarkupEncoding("UTF-8");
  179. super.init();
  180. }
  181. private void mount(String location, Class<? extends WebPage> clazz, String... parameters) {
  182. if (parameters == null) {
  183. parameters = new String[] {};
  184. }
  185. if (!settings.getBoolean(Keys.web.mountParameters, true)) {
  186. parameters = new String[] {};
  187. }
  188. mount(new GitblitParamUrlCodingStrategy(settings, location, clazz, parameters));
  189. // map the mount point to the cache control definition
  190. if (clazz.isAnnotationPresent(CacheControl.class)) {
  191. CacheControl cacheControl = clazz.getAnnotation(CacheControl.class);
  192. cacheablePages.put(location.substring(1), cacheControl);
  193. }
  194. }
  195. @Override
  196. public Class<? extends WebPage> getHomePage() {
  197. return homePageClass;
  198. }
  199. public boolean isCacheablePage(String mountPoint) {
  200. return cacheablePages.containsKey(mountPoint);
  201. }
  202. public CacheControl getCacheControl(String mountPoint) {
  203. return cacheablePages.get(mountPoint);
  204. }
  205. @Override
  206. public final Session newSession(Request request, Response response) {
  207. GitBlitWebSession gitBlitWebSession = new GitBlitWebSession(request);
  208. Locale forcedLocale = runtime().getLocale();
  209. if (forcedLocale != null) {
  210. gitBlitWebSession.setLocale(forcedLocale);
  211. }
  212. return gitBlitWebSession;
  213. }
  214. public IStoredSettings settings() {
  215. return settings;
  216. }
  217. /**
  218. * Is Gitblit running in debug mode?
  219. *
  220. * @return true if Gitblit is running in debug mode
  221. */
  222. public boolean isDebugMode() {
  223. return runtimeManager.isDebugMode();
  224. }
  225. /*
  226. * These methods look strange... and they are... but they are the first
  227. * step towards modularization across multiple commits.
  228. */
  229. public Date getBootDate() {
  230. return runtimeManager.getBootDate();
  231. }
  232. public Date getLastActivityDate() {
  233. return repositoryManager.getLastActivityDate();
  234. }
  235. public IRuntimeManager runtime() {
  236. return runtimeManager;
  237. }
  238. public IPluginManager plugins() {
  239. return pluginManager;
  240. }
  241. public INotificationManager notifier() {
  242. return notificationManager;
  243. }
  244. public IUserManager users() {
  245. return userManager;
  246. }
  247. public IAuthenticationManager authentication() {
  248. return authenticationManager;
  249. }
  250. public IPublicKeyManager keys() {
  251. return publicKeyManager;
  252. }
  253. public IRepositoryManager repositories() {
  254. return repositoryManager;
  255. }
  256. public IProjectManager projects() {
  257. return projectManager;
  258. }
  259. public IFederationManager federation() {
  260. return federationManager;
  261. }
  262. public IGitblit gitblit() {
  263. return gitblit;
  264. }
  265. public ITicketService tickets() {
  266. return gitblit.getTicketService();
  267. }
  268. public TimeZone getTimezone() {
  269. return runtimeManager.getTimezone();
  270. }
  271. @Override
  272. public final String getConfigurationType() {
  273. if (runtimeManager.isDebugMode()) {
  274. return Application.DEVELOPMENT;
  275. }
  276. return Application.DEPLOYMENT;
  277. }
  278. public static GitBlitWebApp get() {
  279. return (GitBlitWebApp) WebApplication.get();
  280. }
  281. }