{"id":1729,"date":"2012-02-13T14:42:29","date_gmt":"2012-02-13T14:42:29","guid":{"rendered":"http:\/\/salientsoft.co.uk\/?p=1729"},"modified":"2012-02-13T14:46:44","modified_gmt":"2012-02-13T14:46:44","slug":"cdiweld-fails-to-inject-a-reference-with-nested-parameterised-types","status":"publish","type":"post","link":"https:\/\/salientsoft.co.uk\/?p=1729","title":{"rendered":"CDI\/Weld fails to inject a reference with nested parameterised types"},"content":{"rendered":"

Weld 1.0 was failing with \u201cWELD-001408 Injection point has unsatisfied dependencies\u201d when nested parameterised types were present.<\/p>\n

The referenced bean was correctly present and annotated.<\/p>\n

I found that I could work around the problem by simplifying\/removing some of the generics. This allowed the beans to inject, but also gave warnings about the use of raw types. For example:-<\/p>\n

\n

\/\/Original code
    private @Inject TableCtrl<TreeNodePath<TaxonomyNode>, RowMetadata> selectionTable;<\/p>\n

\/\/was replaced with the following
    private @Inject TableCtrl<TreeNodePath, RowMetadata> selectionTable;<\/p>\n<\/blockquote>\n

Attempts to use a CDI extension to find out more about what was happening did not reveal any more insight. This post<\/strong><\/a> discusses Weld performance and debugging and refers to a Stack Overflow post on the subject.<\/p>\n

My solution to the problem (which I have also logged on Mantis) is  as follows :-<\/p>\n

    \n
  1. Injecting the bean into a raw type does not suffer from the problem.<\/li>\n
  2. I therefore inject into a temporary raw type, and cast that to the correct type.<\/li>\n
  3. Wrapping this in a method annotated with @Inject neatly solves the problem, as the method can take the raw types as arguments, and cast to the correctly parameterised fields in the method.<\/li>\n
  4. As all this is done in a method, warnings can be suppressed for the method. This is a tidy solution, as the method only has this specific purpose, and no other warnings in the class are incorrectly suppressed.<\/li>\n
  5. This is far better than the original workaround which involved hacking the generics back to non nested parameterised types throughout – this meant hacking a number of classes. The current solution entirely isolates the issue and allows the desired generics to be correctly used everywhere.<\/li>\n<\/ol>\n

    An example of the correct generic declarations and the method used follows :-<\/p>\n

    \n

    public abstract class TreeBrowser<N extends TreeNode<T>, T extends Tree<N>, P extends TreeNodePath<N>>
                                implements Serializable, BreadcrumbCtrlEvent<N> {
    …
        private CrumbComparator<N> crumbComparator;
        private BreadcrumbCtrl<N> breadcrumb;   
        private TableCtrl<N, RowMetadata> treeNodeTable;
        private TableCtrl<P, RowMetadataStatusMap> trayTable;
    …
        @Inject
        @SuppressWarnings({"rawtypes", "unchecked"})
        void injectWeldUnsatisfiedGenericBeans(CrumbComparator crumbComparator, BreadcrumbCtrl breadcrumb,
                               TableCtrl treeNodeTable, TableCtrl trayTable) {
            this.crumbComparator = crumbComparator;
            this.breadcrumb = breadcrumb;
            this.treeNodeTable = treeNodeTable;
            this.trayTable = trayTable;
        }<\/p>\n<\/blockquote>\n

     <\/p>\n

    This solved the problem. <\/p>\n","protected":false},"excerpt":{"rendered":"

    Weld 1.0 was failing with \u201cWELD-001408 Injection point has unsatisfied dependencies\u201d when nested parameterised types were present. The referenced bean was correctly present and annotated. I found that I could work around the problem by simplifying\/removing some of the generics. This allowed the beans to inject, but also gave warnings about the use of raw […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[150],"tags":[13,110,40,16,111],"_links":{"self":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/1729"}],"collection":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1729"}],"version-history":[{"count":3,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/1729\/revisions"}],"predecessor-version":[{"id":1732,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=\/wp\/v2\/posts\/1729\/revisions\/1732"}],"wp:attachment":[{"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/salientsoft.co.uk\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}