2 Replies Latest reply on Sep 26, 2005 12:13 PM by J-C jc

    How to specify PersistentContext unitName without hardcoding

    J-C jc Apprentice

      I have written a Stateless session bean that is used to perform persist some objects into a DB. In that bean I get the EntityManeger using annotation:

      @PersistenceContext(unitName = "db1")
       private EntityManager manager;


      I'd like to use the same bean to persist the same classes in another DB. Consequently, I can not hardcoded the unitName for the EntityManager.

      I'd like to be able to specify the name of the PersistentContext without using JNDI. Is it possible to do that with annotations ?

        • 1. Re: How to specify PersistentContext unitName without hardco
          Bill Burke Master

          You don't want to hardcode the unit name but you want to use an annotation and don't want to use JNDI? That is a contradiction. The spec doesn't yet have XML injection for persistence contexts, is that what you want?

          You can use the same entity bean class with different persistence units by creating 2 different pars and have the perisstence.xml reference its classes explicityly with the jar-file or class elements.

          • 2. Re: How to specify PersistentContext unitName without hardco
            J-C jc Apprentice

            Maybe I have not been very clear.

            I have an application written using EJB2 and JDO2. I try to migrate that to EJB3. In my previous release, I had a session bean. One of its method was used to persist some objetcs in a database. The name of the DB was provided as parameter. Consequently, in this method I used a service locator to get a PersistenceManager for the specified DB).

            In EJB3, Using the annotation make the code often easier to read, that's why I just asking if there is a way to set dynamically the unit name. But you are right 2 differents .par may solve my problem.
            Another solution I have tried is to provide the EntiyManager as parameter to my Session bean (since it is always invoke from another Session bean), but I do not like this solution.