2 Replies Latest reply on Jan 11, 2007 12:13 PM by Toni Beckman

    Env entry & @Resource

    Toni Beckman Novice

      Hi,

      is it possible to use the @Resource annotation to inject deploy time configured properties into a field variable of a SLSB?

      Trying to inject the value into a SLSB does not work. The field of the SLSB remains NULL.

      Here the ejb-jar.xml which I place in "/ejb/META-INF/":


      -----------------------------------
      <ejb-jar>

      <enterprise-beans>

      <ejb-name>EmailBean</ejb-name>
      <session-type>Stateless</session-type>
      <env-entry-name>aea</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <envv-entry-value>archive@server.de</envv-entry-value>

      </enterprise-beans>

      <assembly-descriptor>
      <interceptor-binding>
      <ejb-name>*</ejb-name>
      <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
      </interceptor-binding>
      </assembly-descriptor>

      </ejb-jar>
      --------------------------------

      @Name("emailBean")
      @Stateless

      public class EmailBean implements EmailBeanInterface
      {
      @In(create = true)
      EntityManager entityManager;

      @Resource(mappedName="java:comp/env/aea")
      String archiveEmailAddress;
      ...
      }
      ------------------------------------------------------------

      Has anybody got this working with seam?

        • 1. Re: Env entry & @Resource
          Norman Richards Master

          envv-entry-value looks like a typo to me.

          Seam is not doing anything with that - it is purely the EJB3 container. If it isn't working right, you should check the EJB3 forums and/or open an EJB3 JIRA issue.

          Out of curiosity, what do you see as the advantages of trying to use this as opposed to using a configuration property in components.xml?

          • 2. Re: Env entry & @Resource
            Toni Beckman Novice

            Thxs. I corrected the typo, but it's still not working. I also can't see it in the JNDI Tree of the MX console so it seems to be a binding problem. It should appear there, right?

            Well, there is no real argument for using this over that. But I read the oreilly books and follow standards. So, I guess if there is a standard way of doing something, and I mean industry standard, I rather use it.

            But since seam and many other things are proprietary in the first place there is really no point in not using what you suggest. I guess it's just a prefence to choose standards over propiertary software.