9 Replies Latest reply on Dec 1, 2008 10:32 AM by wolfc

ejb3 user transaction and serlvets

adrian.brock Dec 1, 2008 8:40 AM

Why are servlets using the ejb3 user transaction?

2008-12-01 14:31:44,494 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jpa-test].[TestServlet]] (http-localhost%2F127.0.0.1-8080-2) Servlet.se
rvice() for servlet TestServlet threw exception
java.lang.NullPointerException
 at org.jboss.ejb3.tx.EJB3UserTransactionProvider.userTransactionStarted(EJB3UserTransactionProvider.java:65)
 at org.jboss.ejb3.tx.UserTransactionImpl.begin(UserTransactionImpl.java:74)
 at org.jboss.test.jpa.servlet.TestServlet.doGet(TestServlet.java:59)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)

And why do you assume the user transaction will be configured with a registry
of listeners? The NPE is just sloppy.

1. Re: ejb3 user transaction and serlvets

wolfc Dec 1, 2008 9:18 AM (in response to adrian.brock)

As for the 1st: I don't know.

As for the NPE: it means bad configuration, there is an assertion in EJB3UserTransactionProvider.

I still have the open question of when the EJB?UserTransactionProvider is populated. Until then the NPE is by design.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112397
Actions
2. Re: ejb3 user transaction and serlvets

adrian.brock Dec 1, 2008 9:27 AM (in response to adrian.brock)

"wolfc" wrote:

I still have the open question of when the EJB?UserTransactionProvider is populated. Until then the NPE is by design.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112397

It's populated when it's populated, which could be never if there are no listeners configured.
So the NPE is wrong.
Actions

3. Re: ejb3 user transaction and serlvets

adrian.brock Dec 1, 2008 9:38 AM (in response to adrian.brock)

"wolfc" wrote:
As for the 1st: I don't know.

Its the injection stuff. This is what I get


 @Resource
 private UserTransaction ut;

 System.out.println("@Resource=" + ut);
 System.out.println("java:/comp/UserTransaction=" + ctx.lookup("java:/comp/UserTransaction"));
 System.out.println("UserTransaction=" + ctx.lookup("UserTransaction"));

15:35:44,779 INFO [STDOUT] @Resource=org.jboss.ejb3.tx.UserTransactionImpl@a556cf
15:35:44,780 INFO [STDOUT] java:/comp/UserTransaction=org.jboss.tm.usertx.client.ServerVMClientUserTransaction@1b8b91f
15:35:44,780 INFO [STDOUT] UserTransaction=org.jboss.tm.usertx.client.ServerVMClientUserTransaction@1b8b91f

So the resource injection is not injecting java:comp/UserTransaction like it should
be doing.

4. Re: ejb3 user transaction and serlvets

wolfc Dec 1, 2008 9:43 AM (in response to adrian.brock)

Yup, the injection of UserTransaction is a bug. It should always happen by lookup into JNDI.

"adrian@jboss.org" wrote:
It's populated when it's populated, which could be never if there are no listeners configured.
So the NPE is wrong.

That's ludicrous, the UserTransactionRegistry should always be regardless of listeners. The UserTransactionRegistry itself has the check for an empty listener list. So configuration error.
Actions
5. Re: ejb3 user transaction and serlvets

adrian.brock Dec 1, 2008 9:54 AM (in response to adrian.brock)

"wolfc" wrote:

That's ludicrous, the UserTransactionRegistry should always be regardless of listeners. The UserTransactionRegistry itself has the check for an empty listener list. So configuration error.

The empty check is there because otherwise you create an empty iterator for no purpose.

Its always been the case that you might not configure any listeners. Look at the old code
which is still there. All I've done is moved the registration to one place instead of the listener
(the CCM) having to know about all implementations.

In particular I want to make jca and jta optional in the web-profile
so you can't assume these things will be configured.
Or they may get configured "on-demand" later.
Actions
6. Re: ejb3 user transaction and serlvets

wolfc Dec 1, 2008 10:05 AM (in response to adrian.brock)

The ejb3 logic shouldn't contain the determination whether this function is available or not.
If we continue that logic than everybody who wants some service needs to have optional checks. Now we install 1 dummy service containing no logic.
That's why I want the EJB3UserTransactionProvider depend on UserTransactionRegistry.
Actions
7. Re: ejb3 user transaction and serlvets

adrian.brock Dec 1, 2008 10:12 AM (in response to adrian.brock)
"wolfc" wrote:
The ejb3 logic shouldn't contain the determination whether this function is available or not.
If we continue that logic than everybody who wants some service needs to have optional checks. Now we install 1 dummy service containing no logic.
That's why I want the EJB3UserTransactionProvider depend on UserTransactionRegistry.

You're not listening. If you do that then its very hard to make the transactional
stuff optional or on-demand. Your way requires everything to be installed at
the start which isn't what we want further down the road for jboss5.

Things should only be created if they are actually needed/used.

e.g. No outbound connection factories means no CCM means no listeners on user transactions.

There should be no dummy/mock anything.
All if you to do is write:
if (blah != null)

like any normal programmer does around optional/configurable behaviour.
Actions
8. Re: ejb3 user transaction and serlvets

adrian.brock Dec 1, 2008 10:21 AM (in response to adrian.brock)

"wolfc" wrote:
Yup, the injection of UserTransaction is a bug. It should always happen by lookup into JNDI.

https://jira.jboss.org/jira/browse/JBAS-6265
Actions
9. Re: ejb3 user transaction and serlvets

wolfc Dec 1, 2008 10:32 AM (in response to adrian.brock)

If it's configured on-demand it should still be injected. So no NPE.

As for the optional part, I still say that it's not ejb3's call to say that lazy transaction enlistment is done or not. Ejb3 defers to the UserTransactionRegistry for that.
We're not talking about the CCM being there or not. Installing a CCM should be optional. (Although I removed the optional function from EJBContainer (maybe not the smartest move. ;-) ). There was a null check there (as it should be for optional functions.))

The UserTransactionRegistry must be there, not optional, not on-demand (because of static usage).
Actions

Go to original post