JIRA 4.0 : JIRA Architectural Overview
This page last changed on Jun 14, 2009 by rosie@atlassian.com.
JIRA OverviewThis page provides a very high level overview of JIRA's dependencies and the role each one plays in JIRA. This page makes references to external resources (websites, books) where one can find more information. Technical Introduction to JIRAJIRA is a web application written in Java. It is deployed as a standard Java WAR file into a java Servlet Container such as Tomcat. WebWorkAs JIRA is a web application, users interact with JIRA using a web browser. JIRA uses OpenSymphony's WebWork 1 to process web requests submitted by users. Please note that WebWork 1, not 2, is used. WebWork 1 is a MVC framework similar to Struts. Each request is handled by a WebWork action which usually uses other objects, such as utility and Manager classes to accomplish a task. JIRA uses JSP for the View layer. So most of HTML that is served to the user as the response to their web request is generated by a JSP. Therefore, to generate a response the WebWork action uses a JSP. Also see JIRA Webwork Actions. For more information on WebWork 1 please see its online documentation. SeraphAlmost all authentication in JIRA is performed through Seraph, Atlasian's open source web authentication framework. The goal of seraph is to provide a simple, extensible authentication system that we can use on any application server. Seraph is implemented as a servlet filter. Its sole job is, given a web request, to associate that request with a particular user. It supports several methods of authentication, including HTTP Basic Authentication, form-based authentication (ie. redirect to an internal or external login form), and looking up credentials already stored in the user's session (e.g. a cookie set by a SSO system). Seraph performs no user management itself. It merely checks the credentials of the incoming request, and delegates any user-management functions (looking up a user, checking a user's password is correct) to JIRA's user-management - OSUser (discussed later in this document). If you were looking to integrate JIRA with a Single Sign-On (SSO) solution, you would do so by writing a custom Seraph authenticator (and in fact, many customers have done so). Please note that by default JIRA is not shipped with any SSO integration, customers have to write a custom Authenticator themselves. Another very important function that Seraph performs in JIRA is to only allow users with Global Admin permission to access WebWork actions that allow the user to perform administration tasks. These WebWork actions are accessed by URLs starting with "/admin". For more information on JIRA's permission please see JIRA's documentation. For more information on how seraph works internally please see this page. OSUserOSUser is OpenSymphony's user and group management framework. OSUser provides the following functionality:
As mentioned previously, Seraph delegates to OSUser to authenticate the user (i.e. check whether the correct password has been entered when a user tries to login). OSUser uses the following tables in the database:
Note that userbase table only stores the numeric (arbitrary) id of the user, username, and a hashed password. OSUser uses PropertySet (covered in the next section) to store user's e-mail address, and full name. PropertySet is also used to store user preferences. In JIRA the preferences include things like:
OSUser also provides simple authentication against LDAP, which JIRA can utilise. Note, that only LDAP authentication is supported; the user records must still exist in JIRA's database. For more information on JIRA's LDAP autentication please see this document. For more information on OSUSer, please see its documentation. Note that we are hoping to migrate JIRA to Polis for user management so that full LDAP user and group management is supported. Confluence has already done so. PropertySetOpenSymphony's PropertySet is a framework that can store a set of properties (key/value pairs) against a particular "entity" with a unique id. An "entity" can be anything one wishes. For exmaple, OSUser uses PropertySet to store user's e-mail address, full name and preferences. Therefore, in case of OSUSer, the "entity" is a User. Each property has a key (which is always a java.lang.String) and a value, which can be:
Each property is always associated with one entity. As far as PropertySet is concerned an "entity" has an entity name, and a numeric id. As long as the same entity name/id combination is used to store the value and retrieve the value, everything will work. In JIRA PropertySet uses the following database tables:
Each of the records in property<type> tables also has an id column. The id is the same as the id of the propertyentry record for this property. As the property's key and value are split across 2 tables, to retrieve a property value, a join needs to be done, between propertyentry table and one of the property<type> tables. Which property<type> table to join with is determined by the value of the propertytype column in the propertyentry record. Here is an example of a full name stored for a user: PropertySet is used in JIRA:
For more information on PropertySet please see its documentation. Also see JIRA Database Schema. JIRA Utility and Manager ClassesA lot of business logic in JIRA is implemented in 100s of java classes. The classes can be simple utility classes or Manager Objects. Manager Objects in JIRA usually have one specific goal (or topic). For example com.atlassian.jira.project.version.VersionManager is used to work with project versions, i.e. create, update, delete and retrieve versions. Manager objects use a lot of external dependencies, most of which are open source, but some are developed by Atlassian and are usually shared between Atlassian products. The external dependencies developed by Atlassian are described in this list of product dependencies. |
![]() |
Document generated by Confluence on Oct 06, 2009 00:31 |