[jira] [Commented] (DELTASPIKE-1337) optional ClassFilter spi

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DELTASPIKE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445708#comment-16445708 ] 

ASF subversion and git services commented on DELTASPIKE-1337:
-------------------------------------------------------------

Commit b7808929786eee130e9a724390ff148644d0b127 in deltaspike's branch refs/heads/master from [~gpetracek]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=b780892 ]

DELTASPIKE-1337 optional ClassFilter


> optional ClassFilter spi
> ------------------------
>
>                 Key: DELTASPIKE-1337
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1337
>             Project: DeltaSpike
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.8.1
>            Reporter: Gerhard Petracek
>            Assignee: Gerhard Petracek
>            Priority: Major
>             Fix For: 1.8.2
>
>
> in several cases it's needed to get rid of beans and/or pre-defined beans.
>  that's possible with @Exclude, @Vetoed, @Typed(), scan-tag and ProcessAnnotatedType#veto.
>  only #veto supports really dynamic cases - esp. in cases you don't have the class/es in question under your control (or diff. teams have diff. requirements).
> a simple (but optional) ClassFilter spi allows:
>  * full control (like with #veto - just simpler)
>  * the concept of overruling based on config-ordinals
>  * to get rid of special behaviors defined for alternative-beans (see e.g. observers in alternative-beans)
>  * to use the concept itself for different features/use-cases
> (e.g. a class-filter per test-class via @TestControl to support more isolated tests)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)