[
https://issues.apache.org/jira/browse/DELTASPIKE-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455450#comment-15455450
]
Guillaume Nodet commented on DELTASPIKE-1200:
---------------------------------------------
Yes, Harald has stopped working on pax-cdi for quite some time now. I've been
working on pax-cdi recently and found this issue while trying to fix the
integration tests we have.
Basically, in OSGi, you can't assume a class will be part of a single CDI
application. All deltaspike classes will be shared, but bean instances will
not. This mean that the changes made by DELTASPIKE-892 cause everything to
fall apart in OSGi because the configuration becomes shared.
The problem I have is caused by
{{CoreBaseConfig.BeanManagerDelegation.DELEGATE_LOOKUP}} which was changed from
{{TypedConfig<Boolean>}} to a simple {{Boolean}}. So instead of having
{{ConfigResolver.getPropertyValue}} called at runtime (within a given
application), there's now a single call and the value is stored in the field.
But I think the problem is not specific to OSGi. I suppose the same would
happen if the deltaspike jars would be deployed in a JEE server as server
libraries so that they are shared across applications. In general, static
variables must be used with care if you want to work in a modular environment.
> 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)
