[
https://issues.apache.org/jira/browse/DELTASPIKE-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455779#comment-15455779
]
Romain Manni-Bucau commented on DELTASPIKE-1200:
------------------------------------------------
we already have a cache per classloader for BM so we should surely align the
config with that (sounds like we are back to the "how do we cache in DS" topic
which is some years old now)
> Deltaspike unusable in OSGi
> ---------------------------
>
> Key: DELTASPIKE-1200
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1200
> Project: DeltaSpike
> Issue Type: Bug
> Affects Versions: 1.4.2
> Environment: OSGi, Pax-CDI
> Reporter: Guillaume Nodet
> Priority: Blocker
>
> Deltaspike is now quite unusable in modular environments, in particular OSGi
> due to static fields that are not supposed to be shared.
> This is particularly true for
> {{org.apache.deltaspike.core.api.config.base.CoreBaseConfig}} inner
> interfaces which causes lots of problems. In my scenario,
> {{deltaspike-core-api}} is loaded on itself as a CDI application, which cause
> the {{BeanManagerIntegration.BeanManagerIntegration.DELEGATE_LOOKUP}} field
> to be initialized, but this initialization fails because no config provider
> can be found (the {{deltaspike-core-impl}} jar is not available).
> Later on, when a real application is loaded, nothing works because the class
> has failed initialization and thus delta pike becomes completely unusable.
> Even if I can make the initialization work in my test by changing the order
> of the bundles and making sure the first time the classes are loaded, a
> config provider is available, I think this means that Deltaspike can't be
> shared at all, because those configuration bits are supposed to change from
> one CDI app to another.
> This seems to be all caused by
> https://github.com/apache/deltaspike/commit/25b2b8cc0c955a28743f9a84925c8e410f0d298d
> and DELTASPIKE-892.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
