[jira] [Commented] (DELTASPIKE-599) CDI 1.1 friendly ViewConfig discovery

["Gerhard Petracek (JIRA)" <ji...@apache.org>]

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

Gerhard Petracek commented on DELTASPIKE-599:
---------------------------------------------

we could add a manual config to @ViewConfigRoot -> the scanned result gets dropped and we add the classes manually (as you said via Class#getDeclaredClasses). that could lead to wrong usages ~easily -> we have to thing about it carefully.
in any case we can't do anything which is just based on the outermost interface, because the following config is valid as well:

{code}
interface Pages
{
    //custom meta-data
    interface Area1 extends ViewConfig {}

    @Folder
    //custom meta-data
    interface Area2 {}
}
{code}

> CDI 1.1 friendly ViewConfig discovery
> -------------------------------------
>
>                 Key: DELTASPIKE-599
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-599
>             Project: DeltaSpike
>          Issue Type: Improvement
>          Components: JSF-Module
>    Affects Versions: 0.7
>            Reporter: Richard DiCroce
>            Priority: Minor
>
> CDI 1.1 introduced the "annotated" bean discovery mode. In this mode, ProcessAnnotatedType observers in CDI extensions are only called for classes that have CDI scope annotations. This is inconvenient for ViewConfigs, as it requires that every class (page) must be annotated with @Dependent:
> {code}
> public interface Pages extends ViewConfig {
> 	@Dependent
> 	class Index implements Pages {}
> 	
> 	@Secured({AuthenticatedDecisionVoter.class, PermissionDecisionVoter.class})
> 	interface SecuredByRoleAttribute extends Pages {
> 		@Dependent
> 		class TestPage implements SecuredByRoleAttribute {}
> 	}
> 	
> 	@Secured(AuthenticatedDecisionVoter.class)
> 	interface NoAuthorization extends Pages {
> 		@Dependent
> 		class TestPage implements NoAuthorization {}
> 	}
> 	
> }
> {code}
> Another workaround would be to make a base class that is marked @Dependent and have all of the pages extend that class, but that's not really any better in terms of the amount of boilerplate.
> It would be nice if there were another way to discover ViewConfig classes. One idea: the application provides a producer method/field with some qualifier that provides the outer-most ViewConfig interface (Pages.class in the above example). Then DS injects Instance<Class<? extends ViewConfig>> and uses Class.getDeclaredClasses() to walk the tree.



--
This message was sent by Atlassian JIRA
(v6.2#6252)