Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Date: Wed, 16 Sep 2015 09:52:45 +0000 (UTC)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: dev@aries.apache.org
Message-ID: <JIRA.12864514.1442397111000.353425.1442397165892@Atlassian.JIRA>
In-Reply-To: <JIRA.12864514.1442397111000@Atlassian.JIRA>
References: <JIRA.12864514.1442397111000@Atlassian.JIRA>
 <JIRA.12864514.1442397111597@arcas>
Subject: [jira] [Created] (ARIES-1405) Make sure bundle goes into
 graceperiod if services needed for JPA are not present
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Christian Schneider created ARIES-1405:
------------------------------------------

             Summary: Make sure bundle goes into graceperiod if services needed for JPA are not present
                 Key: ARIES-1405
                 URL: https://issues.apache.org/jira/browse/ARIES-1405
             Project: Aries
          Issue Type: Improvement
          Components: JPA
    Affects Versions: jpa-2.1.0
            Reporter: Christian Schneider
            Assignee: Christian Schneider
             Fix For: jpa-2.2.0


Currently Coordinator as well as EntityManager services are injected using a manually created service proxy. 
The problem with this is that we can not stop blueprint from starting up the user context this way. So the jpa enabled beans start even if their prerequisites are not yet present.

This can lead to calls blocking at runtime until the service timeout. The error reporting is also bad as you only know something went wrong after the first call and the timeout.

So the idea is to use correct blueprint metadata for the service refs. This makes blueprint go into graceperiod until the services are present. The diag command will then also show what is missing.

The current approach with the Beanprocessor does not support this approach. Se we need to switch to a ComponentDefinitionRegistryProcessor as recommended by Guillaume Nodet.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)