This post provides some preliminary ideas on the consequences of moving TDS to use OSGI or JigSaw.
Assumptions:
- OSGI and Jigsaw will be sufficiently similar so that this proposal with work with either with some tweeks.
- Initial target is Thredds server
- We will want to dynamically load at least the following kinds of things on the server.
- OSPs (e.g. netcdf4, grib, etc)
- RAFs (e.g. S3 and HDFS)
- Services (e.g. DAP4) I will refer to these all generically as "bundles" (OSGI terminology)
The loading process could be either:
- lazy - load only when actually requested
- eager- load at startup to provide a specifically configured TDS starting with a skeleton TDS.
For the eager case, we can assume that some config file (e.g. ThreddsConfig.xml) contains the information needed to dynamically extend the tds to make various bundles available.
For the lazy case, it must be possible to create a "signal" that some bundle is needed and must be preloaded. I can see two obvious ways to do this.
- Stubs -- we provide stub classes for all the bundles so that calling the stub API the first time causes the bundle to be loaded and then used from then on.
- Explicit -- any user of a bundle must explicitly invoke some code to load the required bundle.
My current inclination is to use the eager approach since it is simpler and still allows us to keep a small footprint .war file.
Another question is: where are the bundles stored? I assume they are not kept in the .war file since that would defeat one of the purposes of using dynamic loading. I presume there would be some default repository(s) plus a configurable set of additional repositories from which bundles can be pulled. It may be that NEXUS is usable for this purpose.
A note on IOSPs. Currently the IOSP to use is determined by calling a method that looks at a RAF wrapping a file. This method decides if itcan process that associated file. If we were to use lazy loading, it is probable that for IOSP's we would need to divide the IOSP into two parts: one for testing applicability and one for processing. This is an argument for using eager loading.
