[
https://issues.apache.org/jira/browse/DELTASPIKE-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455771#comment-15455771
]
Guillaume Nodet commented on DELTASPIKE-1200:
---------------------------------------------
Well, maybe I misunderstood the code before DELTASPIKE-892, but now, the field
is a static Boolean, so the value which comes from deltaspike configuration
bits will always be the same, even when used in different CDI containers (i.e.
the classes are shared).
Before the change, it seems to me that the value was retrieved at runtime and
not cached, so that each CDI container using deltaspike would correctly get the
value corresponding to its configuration.
Maybe this is related to CDI-129, but in the case of OSGi, we do not share
instances across CDI containers, so each one get its own bean instances,
irrespective of the fact that the classes are shared or not. In our case, the
classes are shared and we run into the problem I explain with the configuration
also being shared.
For TypedResolver, I'm not sure this can lead to problems. My understanding is
that the configuration is not cached and is retrieved per classloader, so they
can be used in multiple applications at the same time. This was also the case
for DELEGATE_LOOKUP when it was using TypedConfig I think.
> 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)
