[
https://issues.apache.org/jira/browse/DELTASPIKE-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455714#comment-15455714
]
Mark Struberg commented on DELTASPIKE-1200:
-------------------------------------------
Hi Guillaume!
I don't think that DELTASPIKE-892 can be blamed for it. It's essentially a user
problem which is the same for every shared resource and does not only affect
OSGi.
As an example: you have an @ApplicationScoped MailService and if you have a
private String senderEmail in this class and only resolve this for the very
first user which uses your MailService, then you will get wrong results for
every other user.
But that's not a problem of CDI. That's just totally wrong usage.
Same for TypedResolver.cacheFor, etc. If somebody uses this in a scenario where
you might be invoked from many different scenarios, then you might get wrong
results. But that's not a problem of TypedResolver imo.
This sounds familiar to the https://issues.jboss.org/browse/CDI-129 where I
asked whether @ApplicationScoped is per-EAR or per-webapp.
> 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)
