CDI @Inject Named bean in another named bean

Asked

Viewed 1,130 times

6

I am using jsf 2.2. I have 2 @Named

     @Named(value = "menuMB")
     @ViewScoped
     public class MenuMB implements Serializable{

     }

     @Named(value = "produtoGeralMB")
     @ViewScoped
     public class ProdutoGeralMB  implements Serializable{
       @Inject
       private MenuMB menuMB;
     }

Within the produtoGeralMB I have a method that changes a property of the menuMB, however on the jsf page if I use in an inputText #{menuMB.minhaPropriedade}, after ajax there is no change, if use #{produtoMB.menuMB.minhaPropriedade} works.

I noticed that the CDI works with proxy for the injected object. There is something to which on the page I use #{menuMB.minhaPropriedade} and not #{produtoMB.menuMB.minhaPropriedade}? Why does this happen if there is only one instance of menuMB in remembrance?

1 answer

2

Use the annotation javax.faces.view.ViewScoped JSF 2.2 instead of the traditional javax.faces.bean.ViewScoped and everything will work correctly.

In fact, it is recommended to discontinue the use of all annotations in the package javax.faces.bean (which was the default in JSF 2.0):

OF API:

The Annotations in this package may be deprecated in a Future version of this Specification because they Duplicate Functionality provided by other Specifications included in Javaee. When possible, the corresponding Annotations from the appropriate Java EE Specification should be used in preference to These Annotations. In this case, the corresponding Annotation is javax.faces.view.ViewScoped. The Functionality of this corresponding Annotation is identical to this one, but it is implemented as a CDI custom Scope.

Which can be freely translated into:

The annotations in this package can be deprecated in a future version of this specification because they duplicate features provided by other specifications included in Java EE. Where possible the corresponding annotations of the Java EE specification should be used in preference to these annotations. In this case, the corresponding annotation is javax.faces.view.ViewScoped. The functionality of this corresponding annotation is identical to this, but it is implemented as a custom CDI scope.

Reference: JSF SPEC PUBLIC 1087

  • I’m already using javax.faces.view.Viewscoped

  • Maybe it’s a bug in your implementation (or in the combination of environment components). Try to get the bean directly from context to see if it is properly populated: context.getApplication().evaluateExpressionGet(context, "#{menuMB}", MenuMB.class);. Your problem also looks a lot like this one (in English). It may be worth trying to change the javax.faces.STATE_SAVING_METHOD for server

  • Finally. If nothing else goes right, shoot Myfaces + CODI (I don’t know what its implementation but I’ve hit similar bugs in Mojarra and I’m quite satisfied with Myfaces).

  • javax.faces.STATE_SAVING_METHOD was already on server. I also tried parcial_state_saving false but could not be used with Richfaces4. When I get into the context menuMB is populated. I also believe it is something of the implementation, I am trying to use the latest version of everything, richfaces4 + glassfish4 + jsf 2.2.5. I’m going to do a test with CODI. Thank you for your attention!

  • Glassfish 4 comes with Mojarra, switch to Myfaces + CODI which is sure it will (I have an application doing something similar in Jetty). At least you have the work-Around now (recover directly from the context).

Browser other questions tagged

You are not signed in. Login or sign up in order to post.