sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SLING-12) Move NodeType management from JcrContentHelper (sling-content-jcr) to AbstractSlingRepository (sling-jackrabbit-api)
Date Fri, 21 Sep 2007 12:30:51 GMT

     [ https://issues.apache.org/jira/browse/SLING-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Felix Meschberger updated SLING-12:
-----------------------------------

    Fix Version/s: 2.0.0

> Move NodeType management from JcrContentHelper (sling-content-jcr) to AbstractSlingRepository
(sling-jackrabbit-api)
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: SLING-12
>                 URL: https://issues.apache.org/jira/browse/SLING-12
>             Project: Sling
>          Issue Type: Improvement
>          Components: Content, Repository
>    Affects Versions: 2.0.0
>            Reporter: Felix Meschberger
>            Assignee: Carsten Ziegeler
>             Fix For: 2.0.0
>
>
> Currently, the sling-content-jcr bundle has a ContentManagerFactory implementation (the
JcrContentHelper, used to access Sling ContentManager instances), which listens for bundles
being registered and registers node types registered in the bundles and loads initial content
stored in those bundles. Additionally, this class cares to setup the Sling ContentManager
instances used to access the OCM functionality.
> While working on the sling-event bundle, we discovered a race condition with node type
registration and repository use. To overcome this race condition, we propose to move the node
type registration part from the ContentManagerFactory implementation to the AbstractSlingRepository
class in the sling-jackrabbit-api bundle. This class is the base class for services registered
to provide the repository. As such, this class has contact to the repository before the service
is registered or made available to the users of the repository.
> Some background information on the race condition: The JcrContentHelper is implemented
as an OSGi Component and requires a repository and as such will only be activated when the
repository is available. The AbstractRepositoryEventHandler in the sling-event bundle also
requires a repository and is also implemented as an OSGi component. When now both components
are waiting for a repository to become available, the AbstractRepositoryEventHandler may be
activated before the JcrContentHelper is activated and therefore, the node types required
by the AbstractRepositoryEventHandler are not available yet as the JcrContentHandler was not
able yet to register them ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message