On Jul 17, 2010, at 5:57 AM, Billy Vandory wrote:
>
> Hi David, thanks again for your reply. Reading over my emails I can see how
> it could be cryptic, as I assume everyone knows everything about what I am
> doing :)
>
> We are using JPA with hibernate as the provider on geronimo. We want the
> EntityManager injected directly in the DAO via spring, but it seems the
> container will not do that, it will only inject inside an EE component, so
> we want Spring to handle the injection. This is something that spring
> offers, the ability to use the @PersistenceContext in any object
> (apparently). However using the @PersistenceContext annotation in the DAO
> results in:
>
> Caused by: javax.naming.NotContextException: jdbc/walmart0192
>
> So then I decided to see if we could inject the entity manager into our EJB
> using @PersistenceContext without spring as a test, and that worked fine.
> The next test was to see if we could use a JNDI lookup on the dbpool, in the
> EJB directly, and that failed, and then we tried using @Resource in the EJB
> and that failed as well. This was the motivation for doing a lookup inside
> the EJB using JNDI - just a test.
>
> This takes me right up to my last msg.
>
> On your advise I added the dependency to my dbpool in my geronimo dd, and
> added the following to ejb-jar.xml
>
> <ejb-name>CategoryEJB</ejb-name>
>
> <business-remote>com.wakapeek.common.bean.RemoteCategory</business-remote>
> <ejb-class>com.wakapeek.ejb.CategoryEJB</ejb-class>
> <session-type>Stateless</session-type>
> <transaction-type>Container</transaction-type>
>
> <resource-ref>
> <res-ref-name>jdbc/testmydb</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <res-auth>Container</res-auth>
> <res-sharing-scope>Shareable</res-sharing-scope>
> </resource-ref>
>
>
> Well that worked! The @Resource injection and JNDI lookup in the EJB now
> locate the datasource just great!
>
> I then took all that lookup / resource stuff out of the EJB and reverted to
> our earlier config, where the Entity Manager is to be injected into the DAO
> via the @PersistenceContext annotation and it fails with the Caused by:
> javax.naming.NotContextException: jdbc/walmart0192
>
> (I'm using different db's. Sometimes it's testmydb, the other ones are dev
> db's.)
>
> As to the flow of this thing, it's as follows:
>
> This is just a backend EJB layer. No web server, no servlets, no web.xml,
> etc. Just EJB and JPA on geronimo bundled and deployed as an ear file
>
> So now what is happening is, in a standalone test we lookup a stateless EJB
> and invoke a method - A service object is injected into the EJB via spring,
> then the DAO is injected into the service object and the entity manager is
> (supposed to be) injected into the DAO via the @PersistenceContext
> annotation. This is where it generates the stack trace throwing a
> NotContextException.
>
> In the EJB, this is the method we invoke:
>
> @Override
> public CategoryDTO getCategoriesTree() {
> // test jndi lookup from this ejb (THIS NOW WORKS !!)
> try {
> InitialContext ctx = new InitialContext();
> DataSource ds = (DataSource)
> ctx.lookup("java:jdbc/testmydb");
Really? it shouldn't: this should work:
DataSource ds = (DataSource)
ctx.lookup("java:comp/env/jdbc/testmydb");
> Connection con = ds.getConnection();
> }
> catch (Exception e) {
> logger.error(e);
> }
>
> // call the service layer
> return categoryService.getCategoriesTree();
> }
>
>
> The CategoryService object has the DAO injected via spring. This service
> object is marked as a spring @Service
>
> public void setCategoryDao(CategoryDao dao) {
> this.categoryDao = dao;
> }
>
> And the DAO has the EntityManager injected via spring. The DAO is marked as
> @Transactional
>
> @Required
> @PersistenceContext(name = "wakapeek-jpa")
> public void setEntityManager(EntityManager entityManager) {
> this.em = entityManager;
> }
>
> and again, the same problem: Caused by: javax.naming.NotContextException:
> jdbc/walmart0192
>
> So Im not sure why this all works but Spring can't handle it.
Can you show the spring configuration for the PU? Does it reuse the same
persistence.xml as geronimo finds? I think that for spring you need to specify
jndi names for the jta-datasource and non-jta-datasource and for geronimo you
definitely can't. So you may need to turn off the jpa deployer in geronimo
before deploying your ear to avoid conflicts. I also don't know what triggers
spring to actually try to get the datasource from jndi. If it's done in a
thread called from your ejb, then, if you keep the stuff so the jndi lookup
works in the ejb, you can use the same jndi name in the configuration for
spring, (the name I think should be "java:comp/env/jdbc/testmydb") If it's
called in some other thread you'll have to use the jca: name that doesn't seem
to work yet.
The jca name should be printed out in the log... so please check that you are
using the one that is printed, maybe some configuration changed and so did the
name.
thanks
david jencks
>
> I'm going to cross post this into the Spring forum now, as it's behaving
> correctly in the EJB. Thanks very much for all your help and having the
> patience to sift through my messages. If I ever find the solution, I will
> definately put up a faq somewhere on dbpool + spring + geronimo + jpa. It's
> been interesting configuring geronimo with hibernate. If you have any
> thoughts, I'd love to hear them! :)
>
> - billworth vandory
> --
> View this message in context:
> http://apache-geronimo.328035.n3.nabble.com/Geronimo-2-2-Spring-Hibernate-and-a-Geronimo-managed-DB-Pool-with-XA-driver-tp874759p974846.html
> Sent from the Users mailing list archive at Nabble.com.
