deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Wellmann <hwellmann...@gmail.com>
Subject Re: Data Module Repository across OSGi bundles?
Date Sun, 06 Sep 2015 12:52:10 GMT
DeltaSpike Data uses CDI.current() (at least indirectly) to determine the
BeanManager to use. Pax CDI creates a BeanManager per bean bundle. The
meaning of "current BeanManager" is not well-defined in this multi-module
setup, neither in the CDI 1.2 spec nor in  the OSGi CDI draft (RFC 193).

Pax CDI uses a proxy for each @OsgiServiceProvider bean to set the
"current" BeanManager for the bean bundle containing this bean. This is the
use case that should work and is covered by Pax CDI integration tests. If
the entry point of the call stack into your repository bundle is not an
@OsgiServiceProvider, the proxy cannot do its work, which will cause the
exception you've seen.

Regards,
Harald

2015-09-03 21:27 GMT+02:00 Gary Hodgson <gary.s.hodgson@gmail.com>:

> Hi
>
> Has anyone had any experience using repositories, from the data module,
> within OSGi bundles? in particular between bundles?
>
> I have got an example working within a bundle using Pax CDI, but am having
> trouble making it available from another bundle.  In fact, even when I call
> a service which uses a repository, i.e. not injecting the repository
> directly, I am getting the following exception: "IllegalStateException:
> Unable to find BeanManager. Please ensure that you configured the CDI
> implementation of your choice properly."
>
> I fear that the deltaspike proxy mechanism isn't playing nicely with OSGis
> classloading restrictions which is why the BeanManager is not being found,
> but I would have thought that repository would be contained within the
> context of the bundle together with the service.
>
> I realise this question is a bit vague, but if anyone can respond I will
> happily give more information as is required.
>
> Best regards,
> Gary
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message