4 Replies Latest reply on Jul 18, 2014 6:54 AM by Sven Panko

    Property injection works for EJBs, but not for regular CDI beans

    Sven Panko Newbie

      Hi all,

       

      I have the following scenario: I created an EAR that contains multiple EJB jars. Those jars contain EJBs as well as CDI managed beans. I configured Wildfly's deployment subsystem to strictly isolate the subdeployments (as mentioned in https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly).

       

      I want to use DeltaSpike (currently 1.0.0) to inject some properties into my beans and this has worked fine in all cases until I activated the subdeployment isolation. I now face an interesting situation:

      * a class that is annotated with @Singleton (and is hence an EJB) gets properties injected

      * if I remove that annotation and replace it with @ApplicationScoped (so it is no longer an EJB, right?) the properties are no longer injected - nothing else is changed than changing the annotation

       

      My question is: does Wildfly treat the injection process differently for EJBs and CDI managed beans? Or do I miss something else?

       

      Thanks in advance

      Sven

        • 1. Re: Property injection works for EJBs, but not for regular CDI beans
          Sven Panko Newbie

          Ok, I have a short update - if I remove the annotations completely, property injection works again. So the problem seems to be the @ApplicationScoped annotation.

          • 2. Re: Property injection works for EJBs, but not for regular CDI beans
            Bradley Snyder Newbie

            What are you doing with beans.xml? Is it included, and if so what values of "version" and "bean-discovery-mode" are you using? It seems like it might not be treating the CDI bean correctly. Also, can you show the code for the bean that you're swapping the annotations on?

            • 3. Re: Re: Property injection works for EJBs, but not for regular CDI beans
              Sven Panko Newbie

              I'm doing nothing special with beans.xml, it's a file that is basically empty:

               

              <?xml version="1.0" encoding="UTF-8"?>
              <beans>
              </beans>
              

               

              And here is one of the beans that causes this problem:

               

              @ApplicationScoped
              public class TextProvider
              {
                  private final Logger logger = LoggerFactory.getLogger(getClass());
              
                  private ResourceBundle resourceBundle;
              
                  @Inject
                  @ConfigProperty(name="i18n.language")
                  private String language;
              
                  @PostConstruct
                  void setupResourceBundle()
                  {
                      logger.info("language = {}", language);
              
                      resourceBundle = ResourceBundle.getBundle(Messages.class.getName(), new Locale(language));
                  }
              
                  public String getText(String key)
                  {
                      return resourceBundle.getString(key);
                  }
              
              }
              

               

              In the case shown above, language will always be null. If I remove @ApplicationScoped (and thus make the bean a dependent bean), the property gets injected. If I apply @Singleton (and thus "promote" the bean to an EJB), the property also gets injected.

              • 4. Re: Property injection works for EJBs, but not for regular CDI beans
                Sven Panko Newbie

                Ok, I solved the riddle why things are happening. I am basically hit by this problem: http://rmannibucau.wordpress.com/2012/12/11/ensure-some-applicationscoped-beans-are-eagerly-initialized-with-javaee/

                 

                In short: my Camel Routes are triggered using a Thread ContextClassLoader (TCCL) from bundle A, the beans that serve as the processors inside the route are (partially) from bundle B. Due to the "lazy" initialisation of my processors the resolution of the properties uses the TCCL from A when it tries to initialise the processors from B. That's why they cannot be found, because the property file from A does (obviously) not contain the properties for bundle B.

                 

                In the dependent pseudo-scope case the component that triggered an "eager" initialization was a bean that was annotated @Singleton @Startup. Likewise, promoting the beans to an EJB also triggered an eager init.

                 

                I now have to find a way to either eagerly initialize my CDI beans or I have to "promote" all of them to EJBs :/

                1 of 1 people found this helpful