Changes between Version 13 and Version 14 of VirtualCollectionRegistry

Timestamp:

08/26/14 07:40:45 (10 years ago)

Author:

Twan Goosen

Comment:

more info on PID providers

VirtualCollectionRegistry

@@ -9 +9 @@
  A virtual collection (VC) is a collection that is the result of browsing or searching repositories rather than being the result of construction and first-time publication by an organisation. Another characterisation is that the resources in a VC are already available in other collections, and the VC can be considered a derived collection. Nevertheless these VCs may need to be citable for future use and should therefore be able to be registered in a register, the VCR.
 
-The Virtual Collection Registry (VCR) is an online registry that provides a RESTful web service (REST service) as well as a web based graphical user interface for the creation, publication, management and retrieval of virtual collections. Published collections are made available as CMDI records over OAI-PMH.
+The Virtual Collection Registry (VCR) is an online registry that provides a RESTful web service (REST service) as well as a web based graphical user interface for the creation, publication, management and retrieval of virtual collections. Published collections are made available as CMDI records over OAI-PMH, and get assigned a persistent identifier by means of the [[EPIC|EPIC service]].
 
 These components are available at the following locations '''(currently referencing the alpha deployment!)''':
@@ -60 +60 @@
 The ''!DataStore'' is primarily used in the '''service''' implemented by the ''!VirtualCollectionRegistry'' class, which provides high level CRUD methods, using the ''!VirtualCollection'' model class for the representation of individual collections. It also calls the configured PID service to register and link a '''persistent identifier''' upon publication of a collection. These methods are used by the REST service, OAI provider and Wicket application classes to access and manipulate the stored collections.
 
-The '''Spring framework''' is used to define '''beans''' for singleton service objects, which are injected into various components throughout the application. The [source:/VirtualCollectionRegistry/trunk/VirtualCollectionRegistry/src/main/webapp/WEB-INF/applicationContext.xml applicationContext.xml] file bootstraps the bean definition, while most beans are discovered en constructed by means of 'component scanning'. For example, a singleton bean for ''!DataStore'' exists because it is annotated ''@Repository''. The instance is made available in the ''!VirtualCollectionRegistry'' and ''Application'' (for the Wicket UI) instances because both are managed by Spring too (annotated with ''@Service'' and ''@Component'' respectively) and contain a ''!DataStore'' field annotated with ''@Autowired''.
+The '''Spring framework''' is used to define '''beans''' for singleton service objects, which are injected into various components throughout the application. The [source:/VirtualCollectionRegistry/trunk/VirtualCollectionRegistry/src/main/webapp/WEB-INF/applicationContext.xml applicationContext.xml] file bootstraps the bean definition, while most beans are discovered en constructed by means of 'component scanning'. For example, a singleton bean for ''!DataStore'' exists because it is annotated ''@Repository''. The instance is made available in the ''!VirtualCollectionRegistry'' and ''Application'' (for the Wicket UI) instances because both are managed by Spring too (annotated with ''@Service'' and ''@Component'' respectively) and contain a ''!DataStore'' field annotated with ''@Autowired''. 
+In addition, some beans are defined in configuration classes (annotated with ''@Configuration''), by methods annoted ''@Bean''. Note that all beans are singleton by default - so called 'prototype beans' are not used in the VCR.
+
+There are a number of application context '''profiles''', the activity of which determine which beans get instantiated by Spring. The context parameter ''spring.profiles.active'' can be used to activate one or more profiles. The profiles are defined by means of the ''@Profile'' annotation. At the moment one profile exists for each PID provider implementation; for example, the ''vcr.pid.epic'' profile activates the ''EPICPersistentIdentifierProvider'' implementation and the ''EPICPersistentIdentifierConfiguration'' configuration. It is technically valid to activate multiple profiles but in this case this will lead to a clash of service implementations. See deployment information for more details on using profiles to select the PID provider for a VCR instance after deployment.
 
 A number of core services for marshalling, validation, etcetera can be found in ''eu.clarin.cmdi.virtualcollectionregistry.service'' package (generally interfaces with implementations in the .impl subpackage).