[
https://issues.apache.org/jira/browse/DELTASPIKE-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16014720#comment-16014720
]
ASF subversion and git services commented on DELTASPIKE-1256:
-------------------------------------------------------------
Commit 84f956f6663c3604af0f0d07d2cfb2b8d857eafd in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=84f956f ]
DELTASPIKE-1256 remove local ProjectStage cache from ConfigResolver
After profiling and doing some performance tests it became clear that
the performance impact is really low. Probably because JIT optimises it anyway.
By going to ProjectStageProducer every time we can more easily invalidate a
ProjectStage at runtime.
This is especially important for unit testing scenarios.
> CdiTestRunner ProjectStage setting doesn't work on Config
> ---------------------------------------------------------
>
> Key: DELTASPIKE-1256
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1256
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 1.7.2
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 1.8.0
>
>
> If you try to use different ProjectStages with CdiTestRunner, then only the
> first one gets used for ConfigResolver.
> So this ends up with ProjectStage.Production most of the times.
> The reason is that the current ProjectStage gets 'cached' inside
> ConfigResolver.
> We should do some performance tests to check whether we can get rid of that.
> Because the ProjectStageProducer already uses a cache anyway. So the JIT
> might level out this method call after a few seconds.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
