#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # CRITICAL NOTE: THIS DSA SHOULD BE INSTALLED IN A TOMCAT RUNNING # UNDER JAVA 1.5. RUNNING IT UNDER JAVA 1.4 MAY RESULT IN OVERFLOW # FAILURES WHEN TRYING TO RETURN LARGE RESULT SETS DUE TO # LIMITATIONS IN JAVA 1.4. #!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! #################################################################### ### ### Default configuration file for DSA/catalog servers ### #################################################################### # # By default, this file is installed in your DSA/catalog webapp's # WEB-INF/classes directory, and is called "default.properties". # By editing this file, you can configure the system properties for # your DSA/catalog installation. # # However, if you customise this file, we recommend KEEPING A # BACKUP COPY OF IT SOMEWHERE OUTSIDE OF THE DSA/catalog WEBAPP. # If you don't do this, your configuration information WILL BE LOST # if the webapp is undeployed or upgraded. # # Alternatively, if you are familiar with tomcat, you can move the # properties file outside the webapp, and use a tomcat environment # property to specify where the properties file can be found; simply # set the property 'astrogrid.config.filename' for the installed # webapp to the fully-qualified location of the properties file # (and be sure the file is in a location that is readable by tomcat). # You can read more about this on the "Configuring your DSA/catalog" # page in your installed DSA/catalog webapp. # # # IMPORTANT NOTE ON DSA/catalog installation. # ------------------------------------------- # Note that your DSA/catalog should be installed (or accessible, e.g. # via using httpd request forwarding) on either port 80 or port 8080 # for full Virtual Observatory interoperability. # # # Notes on the format of this file: # --------------------------------- # # Comments in this file are preceded by the '#' character. # # Sample or disabled properties are preceded by the '!' character. # # Values which need to be replaced by a suitable local datum are # enclosed in curly brackets, e.g. {replace_me} # # # There are a number of properties to be configured, and as far as # possible they are grouped together in logical collections. # # This file is intended to be self-documenting; if you have # suggestions for clarifications or enhancements, please send # them to astrogrid_dsa@star.le.ac.uk. # #################################################################### # ================================================================== # CRITICAL SETTINGS # ================= # # All the properties in this file are important, but these two are # particularly critical for the operation of DSA/catalog self-tests. # # # ---------- # This property sets the URL on which your DSA/catalog can be accessed. # This URL MUST BE GLOBALLY VISIBLE as it will be used to tell the # Virtual Observatory how to reach your DSA/catalog; a localhost # address WILL NOT work. Uncomment the property below and configure # it with the appropriate values. # Example: # datacenter.url=http://host.dept.uni.ac.uk:8080/astrogrid-dsa-catalog # ---------- # WORKSHOP: CHANGE THIS! datacenter.url=http://{your_full_host_address}:{your_port_number}/{path_to_your_webapp}/ # ---------- # This property sets the location of the "metadoc file" for your data. # This file contains an XML description of the format of your data # (tables and column descriptions, with additional information about # IVOA UCDs etc). # ---------- # # We recommend CONFIGURING THIS SETTING LAST. If you first configure # access to your database (described below), and restart the DSA/catalog # webapp or tomcat, then you can use the "admin/GenerateMetaDoc" page in # this DSA/catalog's web interface to create a skeleton metadoc file # for your data, by visiting this address (customised with your local # installation details): # # http://{your_full_host_address}:{your_port_number}/{path_to_your_webapp}/admin/generateMetaDoc # # Note that at this point, some of the DSA/catalog self-tests will be # failing because an inconsistent metadoc file is in use; you can ignore # this failure temporarily. # The skeleton metadoc file you have thus created will require some # manual enhancement, as described in this DSA/catalog installation's # "Configuring your DSA/catalog" web interface pages: # # http://{your_full_host_adddress}:{your_port_number}/{path_to_your_webapp}/configure.jsp # # Once you have edited the metadoc file, put it somewhere outside the # installed webapp and then make sure you supply a fully-qualified path # to it in the property below, and that it has file permissions allowing # tomcat to read it. # WORKSHOP: CHANGE THIS! datacenter.metadoc.file={/full/path/to/your.metadoc.xml} # ================================================================== # DATABASE CONNECTION SETTINGS # ============================ # # Properties involved in connecting to the dataset in the RDBMS. # # The DSA/catalog architecture is "pluggable", i.e. "plugin" modules # can be written to handle local data connection requirements without # revision to the core DSA/catalog engine. # # Two standard plugins are currently supplied, which should hopefully # be adequate for most users. # # For testing purposes, a test plugin with classname # 'org.astrogrid.tableserver.test.SampleStarsPlugin' is supplied; # this creates and accesses a small test database using the HSQLDB java # database that is included in the DSA/catalog installation. # # For access to your own RDBMS data, a JDBC plugin is supplied # with classname 'org.astrogrid.tableserver.jdbc.JdbcPlugin', to # allow the DSA/catalog to connect to your database via the JDBC # architecture. # (NB This plugin requires that your RDBMS vendor supplies a JDBC driver # for the RDBMS; as far as we know, all the major vendors do this). # If your RDBMS doesn't support JDBC, you will need to provide a # customised plugin; you may wish to contact astrogrid_dsa@star.le.ac.uk # for some advice with this. # # ------------------------------------------------------------------ # A JDBC plugin for real RDBMS access # ---------------------------------- # # We hope that this JDBC plugin should work for most common RDBMS systems. # # Note that you will also need to copy the JDBC jar for your RDBMS # into your DSA/catalog webapp's WEB-INF/lib directory (remember to # restart the webapp after doing so, to be sure the jar is in the # webapp's classpath). # ---------- # This property tells the DSA to use the JDBC Plugin # ---------- datacenter.querier.plugin=org.astrogrid.tableserver.jdbc.JdbcPlugin # ---------- # This property tells the plugin whether the RDBMS expects trigonometric # function arguments in radians or not (set to "false" if RDBMS trig # functions use degrees). # ---------- db.trigfuncs.in.radians=true # ---------- # This property tells the JDBC plugin whether to disable "autocommit" when # communicating with the RDBMS via JDBC. # By default this property is true, which is the correct setting for most # systems. # You may need to uncomment this if you have problems communicating with # a Sybase RDBMS. !datacenter.plugin.jdbc.disableautocommit=false # ---------- # These properties tell the DSA what username and password to use for JDBC # access to the RDBMS (this user account obviously needs to exist/be # configured within your RDBMS). # IT IS STRONGLY ADVISED THAT THE JDBC USER ACCOUNT BE READ-ONLY - so # the JDBC username should have no permission to modify the database. # ---------- datacenter.plugin.jdbc.user=workshop datacenter.plugin.jdbc.password=qwerty # ---------- # These properties tell the JDBC infrastructure how to connect to the # RDBMS. Insert the details of your JDBC driver class and connection URL # (you can base this on one of the templates below if using one of the # specified RDBMS systems, and/or refer to the JDBC section of your RDBMS # documentation.) # ---------- # - - - - - - - # Template JDBC driver/URL properties for MySQL 4.1.16 # Likely to work with other versions of MySQL too # datacenter.plugin.jdbc.drivers=com.mysql.jdbc.Driver datacenter.plugin.jdbc.url=jdbc:mysql://beacon4.star.le.ac.uk:8080/first # ---------- # Settings for SQL translation. # The JDBC plugin by default uses an XSLT-based mechanism to produce # suitable SQL queries from incoming ADQL/XML queries. We need to # specify which XSLT stylesheet the RDBMS should use. # The following stylesheets ship with the DSA; choose the one most # appropriate to your RDBMS. If your DSA fails its SQL syntax tests, # you will need to provide a customised stylesheet that produces the # correct SQL. # ---------- # For MySQL 4.1.16 # (likely to work with other versions of MySQL too) # (This is a good one to try if your RDBMS is not one of the ones listed). datacenter.sqlmaker.xslt=MYSQL-4.1.16.xsl # ================================================================== # RESOURCE RESTRICTION SETTINGS # ============================= # # These properties allow you to set crude usage limitations to avoid # overloading or large-scale data-mining of your DSA/catalog, if you wish. # Limits number of rows that can be returned by any single query # (equivalent to using SQL "TOP" or "LIMIT"). # NB A value of 0 indicates no limit. datacenter.max.return=50000 # These properties limit the number of queries to be processed simultaneously. # # For asynchronous queries, queries in excess of the limit will be queued # until one or more of the active queries completes). # # For synchronous queries (e.g. traditional conesearch), queries in excess of # the limit will be rejected with a "Try again later" message (there is no # point queueing them, as the synchronous client will likely time out waiting # for them to be run. # # Having two separate properties (to replace the old "datacenter.max.queries" # property) allows administrators to decide which kind of jobs to prefer. # It may be better to allow more synchronous queriers and fewer asynchronous # ones, since over-the-limit asynchronous queries will still get run eventually, # whereas over-the-limit synchronous queries will actively fail. datacenter.max.sync.queries=15 datacenter.max.async.queries=15 # This properties sets the maximum "age" of a completed job in the # in-memory job history, in days. Job histories for jobs older than this # will be deleted to conserve memory. datacenter.flush.interval=7 # Limits run-time for each query. # NB A value of 0 indicates no limit # # Note that setting this value to some finite time will NOT cause # the SQL query running on the actual RDBMS to be terminated; it # will just kill off the datacenter's monitoring and results # delivery for any query has been running for more than the # specified time. datacenter.sql.timeout=0 # ================================================================== # SELF-TEST SETTINGS # ================== # The DSA/catalog server has a suite of self-tests designed to # check that ADQL/XML queries are being translated into SQL compatible # with your back-end RDBMS. # # The self-test infrastructure uses a series of templated ADQL/XML # queries; it plugs a real table name and real column names into # the templates in order to produce SQL that will actually run against # your data in your RDBMS. # # The properties below tell the self-test infrastructure the names of # the table and columns to use in populating the templated queries. # # The columns chosen should be some kind of floating-point number; # RA and DEC are ideal if they exist in your database. # If your data has no floating-point columns, you can try integer # columns instead; however, some syntax self-tests may fail if your # RDBMS is picky about automatic type promotions. # # !! IMPORTANT NOTE: The DSA metadoc file allows catalog, table and # column names to be described in both an ID attribute and a Name # tag. The ID attribute reflects the SYSTEM NAME and should always be # set to the catalog/table/column name as it appears in the RDBMS; # the Name tag reflects the PUBLICATION NAME and can optionally be set # to # something more user-friendly. (See the webapp's embedded # documentation for more about system and publication names). # # The self-test settings below should use SYSTEM NAMES (i.e. the values # in the metadoc's ID attributes), representing the real RDBMS names # for tables and columns. # datacenter.self-test.table=catalogue datacenter.self-test.column1=POS_EQ_RA datacenter.self-test.column2=POS_EQ_DEC # ================================================================== # GENERAL QUERY SETTINGS # ====================== # When an incoming ADQL query doesn't specify the table to which it # should be applied (which is undesirable, but is legal ADQL 1.0), # the table defined by the 'default.table' property is used to choose # the table to apply the query to. # # If you only have one table in your dataset, or one major table, # it makes sense to set the 'default.table' property to the name # of this table. # # If you leave the property unset or blank, ADQL queries that do not # specify the target table will be rejected. # Set to the Name (publication name - contents of the Name tag) of a # table in your metadoc, or leave blank/unset !default.table={a_table_name_in_your_metadoc} # VOTable output uses Unified Content Descriptors to describe the # nature of different columns in the data. This property specifies # version of the UCD specification to use. # Allowed values here are '1' (for UCD v.1) or '1+' (for UCD v.1+). # # UCD v.1 is now deprecated. However, some services do not yet # deal with UCD v.1+, so we recommend leaving this property set to # v.1 for the time being. # # In particular, if you are enabling the conesearch interface # (see below), PLEASE USE UCD v.1 for now as the conesearch standard # requires it. # # PLEASE POPULATE YOUR METADOC FILE USING BOTH VERSIONS OF THE UCD # STANDARD, FOR FUTURE UPGRADEABILITY. datacenter.ucd.version=1 # ================================================================== # CONE-SEARCH INTERFACE SETTINGS # ============================== # The DSA/catalog server provides an IVOA "cone-search" interface. # This simple interface accepts a Right Ascension, Declination and # search radius in decimal degrees. You can configure one or more # tables in your catalogue(s) by putting the appropriate entries # in your metadoc file. # # Supplying a conesearch interface to your data probably only makes sense # if that data is contains at least one table with RA and Dec coordinates # for each row. # If you don't want to provide a conesearch interface at all, or wish # to disable it temporarily without changing your metadoc configuration, # set this property to false. # # datacenter.implements.conesearch=true # # Limit the maximum search radius allowed for conesearches. # The limit is specified in decimal degrees; a limit of "0" means no limit. # For example, "conesearch.radius.limit=1.0" will cause conesearches # with a radius of >1.0 decimal degrees to be rejected. conesearch.radius.limit=0 # ================================================================== # VIRTUAL OBSERVATORY SETTINGS # ============================ # To be useful as part of the Virtual Observatory, this DSA/catalog # server needs to publish some information about itself. # These properties are used to describe the DSA/catalog's interfaces # and data so that it can be discovered and utilised by Virtual # Observatory tools and their human users. # ---------- # These two properties are aimed at human readers - change them # to reflect your own installation details. # ---------- datacenter.name=Example DSA for FIRST Survey Catalogue datacenter.description=This is a demonstration DSA/catalog installation. It accesses the FIRST Survey dataset running in MySQL.} # ---------- # The following settings are for configuring "VOResources", which are XML # descriptions of the DSA/catalog server, its interfaces and data, # intended to be stored in VO-compliant "registries" of such descriptions. # # These settings are very important, as together they comprise a unique # identifier for this resource in the Virtual Observatory. # The Authority ID is a unique identifier for your organisational unit, # e.g. star.le.ac.uk); see # http://wiki.astrogrid.org/bin/view/Deploy/InstallationNotesAuthorityID # for more about authority IDs. # The Resource Key is a unique identifier for this particular resource, # e.g. USNOB_DSA. Your Authority ID must manage no other resources with # this name; the Authority ID / Resource Key pair must be globally unique. # Consult your Registry administrator for advice about what Authority ID # you should use. datacenter.authorityId=dca.workshop # WORKSHOP: CHANGE THIS! # Replace 'YOUR_NAME' below with your name e.g. Kona_Andrews_DSA datacenter.resourceKey=YOUR_NAME_DSA # These settings provide helpful information to human users of the VO. # ------------------- # Settings for the publisher of the data (DSA owner) datacenter.publisher=EuroVO DCA Workshop # WORKSHOP: Change these two datacenter.contact.name=Your name datacenter.contact.email=Your email address # Settings for the creator of the data (who produced it originally) # The datacenter.data.creator.logo attribute may be left blank (in # which case it will default to an Astrogrid logo). datacenter.data.creator.name=Robert H. Becker, David J. Helfand, Richard L. White, Michael D. Gregg, Sally A. Laurent-Muehleisen datacenter.data.creator.logo= # This setting points to the "reference URL" for your DSA/catalog # installation. If left blank, this setting will default to the # same value as the datacenter.url property. # If there is an independent web page that describes this DSA/catalog # installation, or the data it wraps, you can set this property to # point to that web page instead. # (e.g. "datacenter.reference.url=http://myplace.org/mydata.html") datacenter.reference.url=http://sundog.stsci.edu/first/catalogs/readme.html # ---------- # Choose which version(s) of the VOResources standard to use for # registering this DSA/catalog installation. # Use a value of "enabled" to enable the specified version, and # a value of "disabled" to disable it. # FOR THE TIME BEING, v1.0 IS NOT SUPPORTED AND NEEDS TO BE DISABLED. datacenter.resource.register.v0_10=enabled datacenter.resource.register.v1_0=disabled # ================================================================== # REGISTRY SERVICES # ================= # # This DSA/catalog installation needs to register its own resources in # the same "Publishing registry" that publishes the installation's # Authority ID registration (see Authority ID discussion above). # # Additionally, this installation will sometimes need to search a VO # "Querying registry" in order to resolve VOSpace addresses (such as # destination IVORNs where it should put query results). # # This is the "publishing registry" used when this DSA/catalog needs to # register its resources. It must be the same registry where the DSA/catalog's # Authority ID is registered. (Note that the admin endpoint uses the # RegistryUpdate interface of this registry.) org.astrogrid.registry.admin.endpoint=http://beacon3.star.le.ac.uk:8080/astrogrid-registry/services/RegistryUpdate # This is the "querying registry" used to resolve VOSpace addresses. # It should be reasonably high performance and/or close by, but it doesn't # have to belong to your organisation or manage your Authority ID. # (Note that the query endpoint uses the RegistryQuery interface of this # registry.) org.astrogrid.registry.query.endpoint=http://beacon3.star.le.ac.uk:8080/astrogrid-registry/services/RegistryQuery # This is the alternative querying registry, used if the main querying # registry is unavailable. # WORKSHOP NOTE: This should usually be a different registry from the # one specified in the org.astrogrid.registry.query.endpoint property org.astrogrid.registry.query.altendpoint=http://beacon3.star.le.ac.uk:8080/astrogrid-registry/services/RegistryQuery # ================================================================== # MISC. OTHER PROPERTIES # ====================== # # Enable http-chunking support for large file transfers (to avoid # buffer overflow errors). # YOU SHOULD *NOT* NEED TO DISABLE THIS PROPERTY, BUT NOTE THAT # HTTP-CHUNKING WILL ONLY WORK IN JAVA 1.5! # YOU SHOULD RUN THIS DSA/catalog IN JAVA 1.5 (NOT 1.4). org.astrogrid.filestore.chunked.send=enabled # DON'T CHANGE OR REMOVE THIS ONE! It's a required property. cea.component.manager.class=org.astrogrid.dataservice.service.cea.DatacenterCEAComponentManager # ---------- # These set whether CEA tasks should be stored in memory or on disk, # and if so, where. The default is in memory, so you only need to # uncomment/configure these properties if you want the CEA interface # to store jobs to disk. # ---------- !cea.persistence.backend=file !cea.filestore.basedir=/tmp/ (defaults to container's default directory)