You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stanbol.apache.org by "Rupert Westenthaler (JIRA)" <ji...@apache.org> on 2013/03/26 08:41:15 UTC

[jira] [Created] (STANBOL-996) Seperate OSGI Services and Components for the Entityhub

Rupert Westenthaler created STANBOL-996:
-------------------------------------------

             Summary: Seperate OSGI Services and Components for the Entityhub
                 Key: STANBOL-996
                 URL: https://issues.apache.org/jira/browse/STANBOL-996
             Project: Stanbol
          Issue Type: Bug
          Components: Entityhub
    Affects Versions: entityhub-0.11.0
            Reporter: Rupert Westenthaler
            Assignee: Rupert Westenthaler


Currently most Entityhub components are both OSGI services and components (meaning that they have both the @Service and @Component annotation).

Affected:

 * ReferencedSite
 * Cache
 * SolrYard
 * ClerezzaYard

Not Affected:

 * ManagedSite: This component uses already the described model

Why to separate @Component and @Service implementations
================================================

A detailed description of the design can be found in [1].

The main reason for adopting this model for the Entityhub is not to provide its services outside of OSGI, but to solve the problem of registered services with missing dependencies (e.g. A SolrYard that is still missing the configured SolrServer).

The new model will allow to 

* check in the activate method of the Component if the user provided configuration is valid
* init and open serviceTracker for the referenced services
* mark the component as activated

but only as soon as all tracked services do become available the Service would be instantiated and registered with the OSGI environment. 

With this model Entityhub services (e.g. the RESTful API for a ReferencedSite) would only become available if the site is ready to use. With the current architecture this is the case as soon as the activate method of the component completes. Because of this Users do get Exceptions like (example taken from [2])

    java.lang.IllegalStateException: Unable to initialize the Cache with Yard netzmuehleIndex! 
    This is usually caused by Errors while reading the Cache Configuration from the Yard.
        at org.apache.stanbol.entityhub.core.site.CacheImpl.getCacheYard(CacheImpl.java:214)
    [..]
    Caused by: org.apache.stanbol.entityhub.servicesapi.yard.YardException: TheSolrIndex 
    'netzmuehle' for SolrYard 'netzmuehle Index' is currently not active!
        at org.apache.stanbol.entityhub.yard.solr.impl.SolrYard.getServer(SolrYard.java:512)
   [..]

Backward Compatibility
==================

The new design will require to add new '{service}Component' classes (e.g. SolrYardComponent, ReferencedSiteComponent). Why those will take the same configurations as the current {service}s OSGI would - by default - assume the configuration files to be named after the Class name. This would mean that current configuration files would no longer be considered by the new '{service}Component's.

To avoid this and provide full backward compatibility the 'name' parameter of the new  '{service}Component's need to be set to the 'name' used of the old {service} classes.
 

[1] http://markmail.org/thread/yw6l5pnk6djovcjy
[2] http://markmail.org/message/7etfzzhicsuh26m4

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira