opencadc / caom2sandbox Goto Github PK

and automate insert/update of tap_schema content

see storage-inventory/luskan for example (InitAction)

The sc2repo.properties config file has a really old format that is very inconsistent with the (improved) practices we adopted in storage inventory (specifically thinking of baldur and raven where one creates an “entry” and then a set of properties for it on separate lines.

I don’t think it would be much work to implement a new config style like
ca.nrc.cadc.caom2.repo.entry = FOO
FOO.basePublisherID = ??
FOO.readOnlyGroup = ??
FOO.readWriteGroup = ??
FOO.operatorGroup = ??
FOO.staffGroup = ??
FOO.proposalGroup = true

Technically, only basePublisherID and readWriteGroup are required for a functional repo service.

In the sc2repo impl, there is only one database and we currently have only one maintained SQLGenerator impl, so the other config items are not really configurable separately (the pool and database are in the context.xml and confdigurable props go into catalina.properties).

scheduled background action to create materialised views, eg once at startup and then every X hours

Several services (sc2links, sc2meta, sc2soda) have hard coded dependencies on other sc2 services via ServiceConfig.properties file inside the war file. Instead, such config should be found in ~/config/{service}.properties at startup, for example:

sc2meta.properties with something like:

ca.nrc.cadc.sc2meta.tapService = ivo://cadc.nrc.ca/sc2tap

Good practice: parse config in an InitAction and store stuff in JNDI

The current service uses CaomRepoConfig from caom2-repo-server and that class tries an InitDatabase once it picks the right config item (pool) -- eg at the start of a user request or when a caller invokes the /availability endpoint.

After refactoring the config (see issue #46), this will be easy enough to add and failure should make the service inoperable (code and database version not compatible).

see minoc for an example InitAction

Several services (sc2links, sc2meta, sc2soda) have hard coded dependencies on other sc2 services via ServiceConfig.properties file inside the war file. Instead, such config should be found in ~/config/{service}.properties at startup, for example:

sc2links.properties with something like:

ca.nrc.cadc.sc2links.tapService = ivo://cadc.nrc.ca/sc2tap
ca.nrc.cadc.sc2links.sodaService = ivo://cadc.nrc.ca/sc2soda

Good practice: parse config in an InitAction and store stuff in JNDI

Several services (sc2links, sc2meta, sc2soda) have hard coded dependencies on other sc2 services via ServiceConfig.properties file inside the war file. Instead, such config should be found in ~/config/{service}.properties at startup, for example:

sc2soda.properties with something like:

ca.nrc.cadc.sc2links.tapService = ivo://cadc.nrc.ca/sc2tap
ca.nrc.cadc.sc2links.sodaService = ivo://cadc.nrc.ca/sc2soda

Good practice: parse config in an InitAction and store stuff in JNDI