[
https://issues.apache.org/jira/browse/DELTASPIKE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerhard Petracek updated DELTASPIKE-769:
----------------------------------------
Summary: add @Priority dyn. to deltaspike interceptors to avoid the manual
config (was: add @Priority dyn. to interceptors to avoid the manual config)
> add @Priority dyn. to deltaspike interceptors to avoid the manual config
> ------------------------------------------------------------------------
>
> Key: DELTASPIKE-769
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-769
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Gerhard Petracek
> Assignee: Gerhard Petracek
> Fix For: 1.1.1
>
>
> owb doesn't restrict interceptors to the bda which hosts the config ->
> interceptors provided by deltaspike are active per default for the whole
> application. weld users have to add all of our interceptors to the beans.xml
> to use them. since cdi 1.1 global enablement is also supported by weld once
> @Priority gets used.
> we can add it dyn. in case @Priority is on the classpath -> the usage of ds
> gets simpler for weld users and doesn't look that fragmented.
> currently weld has a bug which adds an interceptor twice if it is enabled via
> beans.xml as well as @Priority - therefore we could e.g. detect multiple
> invocations (for the same method) in project-stage development and unit-test
> (-> additional benefit for users of our test-control module) or check the
> content of beans.xml in case of the same project-stages (during
> bootstrapping). that would also mean that we can't use our own interceptors
> internally (since they are enabled for owb 1.1.x/1.2.x users via beans.xml).
> however, currently we aren't doing that anyway, but we have to check it
> during bootstrapping to avoid side-effects with features added later on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
