[jira] [Closed] (DELTASPIKE-680) Lazy init should not rely on BeanManagerProvider

["Thomas Andraschko (JIRA)" <ji...@apache.org>]

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

Thomas Andraschko closed DELTASPIKE-680.
----------------------------------------
    Resolution: Done

Should already be implemted, i also refactor this alot during ~2 years ago.

> Lazy init should not rely on BeanManagerProvider
> ------------------------------------------------
>
>                 Key: DELTASPIKE-680
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-680
>             Project: DeltaSpike
>          Issue Type: Improvement
>          Components: Data-Module
>    Affects Versions: 1.0.1
>            Reporter: Harald Wellmann
>            Assignee: Harald Wellmann
>            Priority: Major
>
> Trying to work with DeltaSpike Data in OSGi (with on-the-fly OSGification, see DELTASPIKE-660), I found that things break when the TCCL is not set to the classloader of the current repository.
> This is caused by lazy initialization of {{RepositoryComponent}} using {{BeanManagerProvider}}.
> Now the current strategies of {{BeanManagerProvider}} to locate the "current" {{BeanManager}} do not work in OSGi where each bundle may have its own BeanManager and there is no obvious interpretation of "current", and the TCCL is not by default set to anything useful for this problem.
> However, in the context of DeltaSpike Data, is it easy to avoid the {{BeanManagerProvider}} even with lazy initialization. The correct {{BeanManager}} is known when a {{RepositoryComponent}} is instantiated, so its sufficient to keep a reference to this {{BeanManager}} to perform lazy initialization.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)