Well, let's say that I want to use Spring, like a majority of the development community out there. And let's say I want to use embedded GlassFish as a container to say, lookup resources like DataSources, TransactionManager, as well as other objects that might be bound to JNDI at runtime. And let's just say that my java project is a JPA project consisting of entity beans and Dao classes that will be used for persistence. Now that JPA project might not contain any EJB's but might be consumed by another project that contains EJB's. But because I want to ensure the quality of my code and ensure that the objects function correctly I want to run unit tests on my JPA project. Seeing as I have a persistence.xml file defined in my JPA project for my EntityManager to use and manage my entities, one item that is needed is a DataSource from JNDI as well as say a TransactionManager, again from JNDI. So it would appear to me that I would need a container to provide me these resources, from JNDI. So it would seem to make sense to use a container that can:
a) be utilized from maven
b) provide the resources in JNDI that my project might need.
Because I am a big advocate of GlassFish and I took on the painful task of migrating our company's Application Server from JBoss to GlassFish, I thought that we might be able to utilize the Embedded GlassFish container to perform our unit tests during our build process, regardless if the project contained EJBs or simple POJO's in a Spring container. To me, this doesn't seem unreasonable, to use the GlassFish container to perform unit tests. Regardless if those tests contain EJB's or simple POJO's contained within a Spring container. Unless you are trying to tell me that Tomcat might be better suited to our needs and then I would begin to ask the question of why I took my company down the GlassFish path.
So, my issue still stands, I can get the container to load, I can define EJB's that are deployed to the container, I can access those EJB's via JNDI lookup within the global namespace, but I still do not know where the EntityManager resides, within JNDI, that will be utilized for my persistence.xml file. To me, this doesn't seem like an unreasonable request. If EJB's are deployed and the persistence.xml file is located and loaded, and my tables are created when the persistence unit is load, then it stands to reason that the EntityManager is available to the application and should be bound to JNDI. After all, when I change my POJO's to EJB's I get the EntityManager injected into them. So why can't someone simply tell me the path to the EntityManager in JNDI so I can continue with my development work?
[Message sent by forum member 'fericit_bostan']
http://forums.java.net/jive/thread.jspa?messageID=475383