Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[udig-devel] [jira] Created: (UDIG-1634) Break ICatalog up into ISearch and IRepository and check interface boundaries 
Break ICatalog up into ISearch and IRepository and check interface boundaries
-----------------------------------------------------------------------------

                 Key: UDIG-1634
                 URL: http://jira.codehaus.org/browse/UDIG-1634
             Project: uDIG
          Issue Type: Improvement
          Components: catalog, metadata and search, framework
    Affects Versions: UDIG 1.2.0
            Reporter: Jody Garnett
            Priority: Minor


This is strictly a framework improvement for developers working on the codebase or on their own plugins.

The current ICatalog interface has been developed hand in glove with ICatalogImpl; and you can start to see the cracks where new functionality was added (like temporary layers) that are specifically targeted at the "local" catalog and not applicable to the general purpose concept of a searching for geospatial services and resources.

So the idea is to split up:
- ISearch - strictly focused on searching
- IRepository - allows management of geospatial data and serivces (ie you can *add* and *remove*)

This leaves us with the following breakdown:
- ISearch
- IRepository
- ICatalog - backwards compatibility

While we are at it here is what CatalogPlugin now publishes for others to use:
- ISearch[] getCatalogs();
- IRepository getLocal();
- ICatalog getLocalCatalog();
- ServiceFactory - used to "create" Services that may be added to the local catalog

The other thing to note is that IService.dispose() must be called on every service created by the ServiceFactory; unless you "add" it to the local catalog.

Checking the interface boundaries have turned up a couple of issues:
- The difficult thing is that the local catalog will not duplicate entries that are already there; and indeed the service you added will not be the one used! So add now returns the service "as registered" and will dispose the service that was passed in (since you handed it over to the local catalog for safe keeping it is its responsibility to dispose of it)
- Code that adds stuff to the catalog has been failing to dispose all of the services produced by ServiceFactory (sigh); added a utility method that will help clean that up

Indeed the dance of:
# create a service with your parameters
# look up the ID for your service in the catalog and see if it is there
#* add your service to the catalog and use it
#* use the service that was there; and dispose of the one you created

Is so common and inconsistently written that I have added it to IRespository; it is documented to use the default ServiceFactory (although I suspect that this will be the default service factory for the catalog over time).
- IRespository.acquire( connectionParams );

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Back to the top