[
https://issues.apache.org/jira/browse/STANBOL-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Adamou updated STANBOL-467:
--------------------------------------
Description:
To setup a scope, you have to:
1. get the ONManager
2. get the OntologyScopeFactory from the ONManager and use it to create the
ontology scope
3. setUp() the scope
4. get the ScopeRegistry from the ONManager and use it to register the scope
and activate it.
There is no point in having "unregistered" scopes, since their memory
occupation is the same, so step 4 should be merged with Step 2. The developer
or administrator should only be concerned with (de-)activating the scope.
At the same time, since the ONManager would become the scope registry, there is
no need to delegate creation to a separate factory object, since its current
implementation is not even an OSGi service component. This would reduce Step 2.
Solution: have ONManagerImpl implement the ScopeRegistry and
OntologyScopeFactory interfaces as well. It could even be renamed to
ScopeManager, in pair with the existing SessionManager.
It could also argued whether the setUp()/tearDown() method pair for
OntologyScope is still useful.
Note that the API currently in place should only be *deprecated*, not removed
yet, as there are already applications using it.
was:
To setup a scope, you have to:
1. get the ONManager
2. get the OntologyScopeFactory from the ONManager and use it to create the
ontology scope
3. setUp() the scope
4. get the ScopeRegistry from the ONManager and use it to register the scope
and activate it.
There is no point in having "unregistered" scopes, since their memory
occupation is the same, so step 4 should be merged with Step 2. The developer
or administrator should only be concerned with (de-)activating the scope.
At the same time, since the ONManager would become the scope registry, there is
no need to delegate creation to a separate factory object, since its current
implementation is not even an OSGi service component.
Solution: have ONManagerImpl implement the ScopeRegistry and
OntologyScopeFactory interfaces as well. It could even be renamed to
ScopeManager, in pair with the existing SessionManager.
It could also argued whether the setUp()/tearDown() method pair for
OntologyScope is still useful.
Note that the API currently in place should only be *deprecated*, not removed
yet, as there are already applications using it.
> Unify ONManager, ScopeRegistry and OntologyScopeFactory implementations
> -----------------------------------------------------------------------
>
> Key: STANBOL-467
> URL: https://issues.apache.org/jira/browse/STANBOL-467
> Project: Stanbol
> Issue Type: Improvement
> Components: Ontology Manager
> Reporter: Alessandro Adamou
> Priority: Minor
> Labels: refactoring
>
> To setup a scope, you have to:
> 1. get the ONManager
> 2. get the OntologyScopeFactory from the ONManager and use it to create the
> ontology scope
> 3. setUp() the scope
> 4. get the ScopeRegistry from the ONManager and use it to register the scope
> and activate it.
> There is no point in having "unregistered" scopes, since their memory
> occupation is the same, so step 4 should be merged with Step 2. The developer
> or administrator should only be concerned with (de-)activating the scope.
> At the same time, since the ONManager would become the scope registry, there
> is no need to delegate creation to a separate factory object, since its
> current implementation is not even an OSGi service component. This would
> reduce Step 2.
> Solution: have ONManagerImpl implement the ScopeRegistry and
> OntologyScopeFactory interfaces as well. It could even be renamed to
> ScopeManager, in pair with the existing SessionManager.
> It could also argued whether the setUp()/tearDown() method pair for
> OntologyScope is still useful.
> Note that the API currently in place should only be *deprecated*, not removed
> yet, as there are already applications using it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
