Jobfilter is a simple Spring-based webapp for managing and filtering job vacancies and application. Vacancy information is obtained from an external data source - currently CSV files; however the implementation is designed to be extensible to other sources of vacancy information.

Vacancies are handled via a simple workflow: a vacancy begins life (having been loaded from the external data source) in a new state. An initial filtering is performed on all new vacancies whereby they are either accepted as being of potential interest or rejected. New vacancies which are accepted become pending . A pending vacancy can be edited repeatedly and, at each stage, have notes attached; it can also be rejected if, on closer inspection, it is deemed to be of no further interest. If a pending vacancy is of interest, an application can be made for the vacancy. Vacancy applications require a CV (Resume) and Jobfilter maintains a set of available CVs for this purpose. An application can be made by email (using an email address provided in the vacancy data) or via an external website (using a URL provided in the vacancy data). In the latter case, Jobfilter merely maintains a record of the vacancy application but leaves the application process to the external website.

Vacancies which are rejected (at either the new or pending stages) are maintained internally within the system for a period of time after the rejection. This allows the system to spot and remove duplicates of rejected vacancies which might appear in subsequent vacancy data loads. A timer within the Jobfilter application automatically removes rejected vacancies after a period of time (when it is assumed duplicates will no longer appear).

The data comprising a vacancy is divided into data specific to the vacancy itself, data pertaining to the agent who posted the vacancy and data about the agency to which that agent belongs. Jobfilter maintains a record of all agencies and their agents and provides the ability to edit this information. Additionally a record is maintained of CVs sent to each agency for reference in the event of a later application for a different vacancy posted by the same agency.


Jobfilter is implemented as a simple 3-tier web application. The web tier is implemented using Spring web MVC which communicates with a middle tier via a set of service interfaces whose implementations are dependency injected into the web tier using Spring. Spring is also used to provide transactional behaviour on the service interfaces. Service interface implementations communicate with the persistence tier via a set of Data Access Object (DAO) interfaces whose implementations are dependency injected into the middle tier using Spring. The following DAO implementations are provided:

  • Hibernate3 (included for completeness)
  • JDO2 (DataNucleus)
  • JPA (DataNucleus)

The Jobfilter implementation is spread across a number of projects as follows:

  • jobfilter-toplevel

    Project whose sole purpose is for invoking a Maven build of the entire application. This project does not provide any code nor does it provide any resultant artifact.

  • jobfilter-doc

    Project documentation - README's, build and deployment instructions etc.

  • jobfilter-common

    Provides domain classes, persistence layer and middle tier (business logic). Note that the jobfilter-common codebase includes the sources for all variants of the persistence layer (JDO, JPA, Hibernate3 etc.) - an appropriate implementation will be selected according to a property passed to the Maven build.

  • jobfilter-war

    Web front-end - servlets, JSPs, Spring MVC form controllers, web-related decorator classes etc. Also provides top-level Spring configuration of application, linking together web tier, business logic and DAOs.

Object Model

The Jobfilter object model is given in the UML class diagram below:

Jobfilter Class Diagram

The classes in the diagram correspond to those in package (in project jobfilter-common ). A description of the classes and their relationships follows:

  • Agency
  • An agency employing a number of agents and holding the registrations of a number of CVs.

  • Agent
  • An agent employed by an agency and who is handing a number of vacancies.

  • Vacancy
  • Abstract base class for a vacancy being handled by an agent.

  • NewVacancy
  • A vacancy in the new state. New vacancies have not undergone the initial filtering process.

  • PendingVacancy
  • A vacancy in the pending state. Pending vacancies have successfully passed the initial vacancy filtering process and may or may not be associated with a vacancy application. A series of notes may be attached to a pending vacancy, recording events during its lifecycle.

  • VacancyNote
  • A note associated with a pending vacancy. Vacancy notes are timestamped and contain a textual description of some event during the lifecycle of its associated vacancy - e.g. "Called agent to check on progress of application - still awaiting response from client."

  • RejectedVacancy
  • A vacancy in the rejected state. Rejected vacancies are new or pending vacancies which have ultimately been determined to be of no further interest. Rejected vacancies do not appear in the user interface but are retained by the system for a short time to help prevent the uploading of future, duplicate vacancies.

  • CV
  • A Curriculum Vitae (Resume) held by the system. The set of available CVs is presented to the user upon making an application for a vacancy. A CV object contains a binary image of the original CV file uploaded from filestore and a reference to an entity reflecting the type of the contents of the binary image (e.g. "Word document"). Any given CV may be registered with any number of agencies - note that, in the CV domain class, the relationship from a CV to a CV registration is actually represented by a map of CVRegistration keyed by the agency with which the CV is registered rather than a simple list or set.

  • CVContentType
  • The type of the content of a CV binary held by a CV object. CV content types are static data , having a fixed set of values (currently "PDF" and "Word"). These are created in the database when the application starts up for the first time.

  • CVRegistration
  • The registration of a given CV with a given agency. A CV registration can be used as the basis of any number of vacancy applications - i.e. upon registering a CV with an agency, it is possible to use that CV to apply for any number of vacancies advertised by that agency.

  • VacancyApplication
  • An application for a (pending) vacancy using a given CV registered with a given agency (i.e. a CV registration entity).

Database model

The tables of the Jobfilter database model (into which the Object Model is persisted) are described below. Note that, for brevity, this description omits the majority of the value fields of the various tables and, instead, concentrates on the various primary and foreign key fields.

  • agency
    • id - primary key

  • agent
    • id - primary key
    • agency_id - id of agency to which agent belongs

  • vacancy
    • id - primary key
    • agent_id - id of agent posting vacancy
    • subtype - discriminator field indicating vacancy subtype

  • vacancy_note
    • id - primary key
    • vacancy_id - id of (pending) vacancy to which note applies

  • cv
    • id - primary key
    • content_type_id - id of CV content type
    • content - BLOB field containing CV file binary image

  • cv_content_type
    • id - primary key

  • cv_registration
    • agency_id - id of agency with which CV has been registered
    • cv_id - id of registered CV

  • vacancy_application
    • id - primary key
    • agency_id - id of agency posting vacancy being applied for
    • cv_id - id of CV used for application
    • vacancy_id - id of (pending) vacancy being applied for