Skip to main content

TransactionRequiredException where I do not expect it--pilot error? bug?

18 replies [Last post]
ljnelson
Offline
Joined: 2003-08-04

I have put Java EE applications together for around 10 years and haven't seen this issue before. I hope it's some new version of pilot error.

I have a Vaadin (www.vaadin.com) application. A Vaadin application begins with a servlet, and typically you @Inject an Application object into the servlet. The Application object is marked as @SessionScoped. Further details are here: http://vaadin.com/wiki/-/wiki/Main/Creating%20JEE6%20Vaadin%20Applications (see option 2).

Inside that Application class, I've @Injected an Instance, where DAO is a local business interface implemented by several of my SLSBs. I've gotten all this working.

For the last several days, I've had my head down coding up UI logic and have finally arrived at the point where my forms and whatnot are ready to invoke business methods on a DAO.

I get my hands on an implementation of the DAO interface, as @Injected through the Instance field, and when I call a method here I get a TransactionRequiredException. The SLSB in question has no XML descriptor or extra annotations on it, so of course it should be designated as TRANSACTION_REQUIRED by default.

What simplistic error am I committing? Naively, this smells like CDI somehow losing the fact that the DAO being injected is really an SLSB under the covers--it's like it's "forgetting" to wire up the injected bean as an SLSB, and is instead wiring it up as a POJO.

Thanks,
Laird

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pmuir
Offline
Joined: 2007-03-30

Guys, please make sure you report the issue about GF not picking up the EJBs. Looking at Laird's stack trace, this is almost certainly the case.

Harald, apologies for the memory issues - we've spent a lot of time in Weld 1.1 clearing these all up, and are aiming for zero leaks, and a reduction by at least 2 orders of magnitude of memory used by Weld for the 1.1 series.

And thanks for sticking with these technologies and reporting issues!

ljnelson
Offline
Joined: 2003-08-04
szczyp

Hi. This stack trace rang a bell. Please take a look here: https://glassfish.dev.java.net/issues/show_bug.cgi?id=11888, and at my last comment about the workaround.
Basically, for me (in embedded) the problem was when there was a CDI jar that was not an EJB-jar. Once I made the CDI jar an EJB-jar (dummy EJB added) it all suddenly started to work.
I am not sure whether it is the problem you are experiencing, though.

ljnelson
Offline
Joined: 2003-08-04

Looks like issue 11888 might be one of the issues I'm running into. Oddly enough, if so, I'm not even using CDI to trigger it as near as I can tell.

Then there's the separate issue of CDI not recognizing an EJB as an EJB.

Thanks for the tip. I'll try this (latest) workaround and see what I get. You're basically suggesting to turn every bean archive into an EJB jar, yes? Would you also suggest moving them around in the ear file so that they're declared or inferred to be EJB modules?

Best,
Laird

szczyp

Yes, I turned every single CDI module (one that has beans.xml) to an EJB by means of including the ejb-jar.xml and a dummy EJB. The dummy EJB didn't have any javax.ejb specific annotations / interfaces, I declared it as an EJB in ejb-jar.xml, so as not to introduce dependencies to the modules. This worked well for me in the embedded mode, I haven't tested that in a standalone EAR application, as I have had enought headaches with the embedded use and it took me, literally, weeks to set our environment correctly. I tested this and it works on 3.1 builds 09 and 10.

The bomb is that today after reading one of your posts it occurred to me that there are newer builds, and I tried to upgrade to build 12 and our tests no longer work (neither do they work in build 11): the JDBC data source defined in domain.xml cannot be looked up. But that's a new story that I noticed just before COB today.

To moan a little bit to give a vent to my tremendous frustration, I have issued 10-15 bugs with workarounds during the whole process of configuring the environment, with reproducible and simplest test cases, and yet, the bugs are unconfirmed, just forwarded to someone who hasn't even commented on them ever since. So, to summarize my experiences: 3.0.1 is completely unusable (apart from toy contrived examples that they can show on seminars and tutorials), 3.1 is under heavy development but each new build introduces new problems (it has been like this for me from build 01). As of now, I deem Java EE 6 completely immature, unstable and unusable. And we are supposed to ship in 4 months, whereas we have been struggling with this for the last 3. I say Java EE 6 in general as I tested JBoss 6 a bit (no comments on this one) and there is really nothing else.

Now, I suppose owe you your 100 bucks for this short psychiatric session. I don't want to offend anyone, but I just had to air this as I am seriously starting to worry about my mental condition.

ljnelson
Offline
Joined: 2003-08-04

No money needed. I've pretty much hitched my career to my bet that 3.1 will be decently functional by the end of the year. The Glassfish folks know I love them dearly :-) but I must say it's looking less and less likely. The only comfort is that JBoss is even worse.

In general, I will stay with Java EE 6 for the JPA 2.0 implementations, which are just now becoming usable. Validation is nice and almost usable (though it's hard to see exactly how and where you're supposed to catch and investigate any ConstraintViolationExceptions). I'm looking warily at backing off of all of its other features.

I agree with you that the 3.0 line is unusable.

To be fair, I don't envy the one (singular!) person whose Herculean job it is to take Weld and shoehorn it into an EJB container so that it works. That's tough sledding. It is way too much for one person. I can't tell what the staffing levels are like at Oracle these days, but it sure looks to me like Glassfish is currently developed by about four people (hi, Tim! Hi, Sahoo! Hi, Siva! Hi...um....) :-\ (At least that sure is the public-facing perspective, from this here loyal customer's point of view.) All together now: Thank you, Larry!

To tie this back to the original thread, I am carefully pulling out all my CDI work that I've done over the last month and a half or so, since (projecting from the time it's taken 11888 to reach its non-functional state at the moment (which had better be way better than its [i]prior[/i] non-functional state)) it will be at least October before this very, very difficult subsystem is integrated fully.

To try to be fair here as well, it looks like POJO injection works more or less OK. But when you start trying to follow Gavin's advice to use @Inject wherever you can in preference to @EJB/@Resource, well...not so much.

Lastly, to any Glassfish people watching/listening: [b]11888 is the tip of the iceberg.[/b] The only reason 11888 has bitten me is because it was as a result of my [i]workaround[/i] to yet [i]another[/i] CDI bug where CDI is not aware (as the spec mandates it should be) of EJB beans as EJB beans. CDI needs, during its discovery process inside Glassfish, to recognize when an implementation is found for an interface that it might have to be proxied by the EJB infrastructure. Currently that doesn't happen.

Here's your venting fee back.

Best,
Laird

hwellmann
Offline
Joined: 2008-08-16

There are two more or less separate issues in this thread:

1) CDI not recognizing EJBs in certain cases
2) the overall instability of Glassfish v3 and the risk for all projects trying to build on this technology

May I suggest that we continue the general discussion 2) in the thread about Glassfish Stability I opened a while ago:

http://forums.java.net/jive/thread.jspa?messageID=477190

I share your general concerns, and my hope is that if we collect all this user feedback under a more visible heading it might have some impact on Oracle after a while. Ok, I may be naive...

Coming back to the more specific discussion in this thread, I fully agree to the statement that Glassfish 3.x is not ready for production.

However, which one of a given subset of releases or promoted builds is more usable or less buggy than another does vary with your usage patterns.

For me, 3.0 was seriously broken, but 3.0.1 is just about usable, now that I've found a workaround for the Hibernate/Weld/javasisst memory leak that was driving us mad. At any rate, I feel safer using 3.0.1 than 3.1-b12 which produces a whole lot of new warning messages when I run my app - I just don't know (and currently don't have the time to find out) if this is due to hidden bugs in my app or to regressions in Glassfish.

Regarding CDI, I do agree that working with it feels like walking on thin ice. On the other hand, the 5 % of CDI features we do use currently seem to work without problems on 3.0.1:

- No @EJB/@Resource injection
- Only @Inject injections
- Single WAR deployment (with a bunch of JARs in WEB-INF/lib)
- The WAR and all JARs with EJBs have a bean.xml
- No stateful or remote EJBs
- Stateless EJBs mostly with no-interface local view
- No CDI scopes
- Hand-crafted CDI injection using BeanManager (required for Wicket)

Regards,

Harald

ljnelson
Offline
Joined: 2003-08-04

One minor point: I've found that "only @Injecting injections" doesn't even work properly in the 3.1 line (one of the issues detailed in this thread). Specifically, if I do this, the EJB machinery is bypassed as near as I can tell, and the resulting object is simply a POJO.

Best,
Laird

pmuir
Offline
Joined: 2007-03-30

Please report the NPE in https://jira.jboss.org/jira/browse/WELD - Weld should at least give you a nicer error message!

ljnelson
Offline
Joined: 2003-08-04

> Is it possible that you have multiple EJB
> implementing the same business interface, CDI is
> confused as to which one to pick?

Oh, and just to be clear: CDI isn't confused--it goes ahead and finds all DAO implementations and adds them to the set that is iterated over by Instance. It is true that if I were to call the Instance's #get() method, an exception would be thrown, as I'd expect.

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04

To be clear, this is a javax.persistence.TransactionRequired exception, thrown by the EntityManager that has, in turn, been injected into a @PersistenceContext-annotated field in the SLSB in question.

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04

The stack trace also seems to back up my assumption: in between the Vaadin event handler and the invocation of the EntityManager, there does not appear to be any Glassfish-added proxies or the other usual fingerprints left behind by an EJB implementation. You'll note that the EntityManager invocation is preceded by what looks like a POJO invocation of my stateless session bean (rather than an invocation on a proxy supplied by Glassfish):

[code]
com.vaadin.event.ListenerMethod$MethodException
Cause: javax.persistence.TransactionRequiredException
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:507)
at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:161)
at com.vaadin.ui.AbstractComponent.fireEvent(AbstractComponent.java:1154)
at com.vaadin.ui.Button.fireClick(Button.java:367)
at com.vaadin.ui.Button.changeVariables(Button.java:189)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1090)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:590)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:265)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:482)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1518)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:651)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:321)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:222)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:166)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:637)
Caused by: javax.persistence.TransactionRequiredException
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.doTxRequiredCheck(EntityManagerWrapper.java:153)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.doTransactionScopedTxCheck(EntityManagerWrapper.java:135)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.merge(EntityManagerWrapper.java:270)
at com.foobar.dao.ejb.AbstractDAO.update(AbstractDAO.java:132)
at com.foobar.lead.vaadin.BeanPanel.commit(BeanPanel.java:178)
at com.foobar.lead.vaadin.BeanPanel$SaveListener.buttonClick(BeanPanel.java:213)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:487)
... 34 more
[/code]

cf126330
Offline
Joined: 2005-03-29

Have you tried lookup or @EJB to obtain DAO SLSB ejb-ref? Just to see if we can narrow it down to CDI @Inject issue.

Is it possible that you have multiple EJB implementing the same business interface, CDI is confused as to which one to pick?

ljnelson
Offline
Joined: 2003-08-04

> Have you tried lookup or @EJB to obtain DAO SLSB
> ejb-ref?

Working on that now.

> Is it possible that you have multiple EJB
> implementing the same business interface, CDI is
> confused as to which one to pick?

It is more than possible: it is absolutely so, and deliberately so. Instance is also an Iterable, so I am using Instance to provide me a list of all auto-discovered session beans in my application. According to the Weld guys, this is totally legal and encouraged.

To put it another way, my Instance variable's #isAmbiguous() returns true, and its #isUnsatisifed() returns false, both as I'd expect.

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04

Lovely. It gets better and better! :-D

I moved some things around in my code so that the DAO in this one particular case is not found in the Instance iterable, but deliberately injected into the Application class with an @EJB marker.

So, again:
Servlet injects Instance
Application in this case is @SessionScoped
Application injects @EJB private DAO dao

I wire up a button in my application so that dao is called.

Now I get a NullPointerException from somewhere inside Weld:

[code]
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:448)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2491)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1884)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:189)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:84)
at $Proxy134.getFactory(Unknown Source) <-- This is a business method on my EJB.
at com.foobar.lead.web.LEADApplication.findFactory(LEADApplication.java:593)
at com.foobar.lead.web.LEADApplication.createCreatePersonWindow(LEADApplication.java:543)
at com.foobar.lead.web.LEADApplication.showCreatePersonWindow(LEADApplication.java:527)
at com.foobar.lead.web.LEADApplication$2.buttonClick(LEADApplication.java:487)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:487)
at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:161)
at com.vaadin.ui.AbstractComponent.fireEvent(AbstractComponent.java:1154)
at com.vaadin.ui.Button.fireClick(Button.java:367)
at com.vaadin.ui.Button.changeVariables(Button.java:189)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1090)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:590)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:265)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:482)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1518)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:651)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:321)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:222)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:166)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:637)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:720)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:200)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:443)
... 48 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:528)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:90)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:718)
... 50 more
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1138)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:134)
at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:145)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:122)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1625)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:469)
... 52 more
[/code]

The next step is just to stick @EJB in the servlet and bypass CDI altogether. (A promising technology that doesn't quiiiite work yet with Glassfish.)

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04

OK, this is even worse. I believe this is a fairly critical bug in basic @EJB injection. I'm using 3.1 build 11.

I've taken Vaadin out of the picture entirely, as well as (almost) CDI (details in a moment).

In my servlet, I do this:

@EJB
private PersonManager pm;

(PersonManager is one of the local interfaces that my PersonManagerBean implements.)

Then in a method called by service(), I assert that this pm is non-null, and call a method on it just to make sure it was initialized properly.

This results in a NullPointerException.

Again, no CDI annotations were harmed in the making of this experiment. :-) I'm just using @EJB.

Here is the stack:
[code]
javax.ejb.EJBException: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:448)
at com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2491)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1884)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:189)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:84)
at $Proxy134.getFactory(Unknown Source)
at com.foobar.lead.web.VaadinServlet.getNewApplication(VaadinServlet.java:63) <-- This is where I simply do: pm.someMethod()
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.createApplication(AbstractApplicationServlet.java:946)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.findApplicationInstance(AbstractApplicationServlet.java:774)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:437)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1518)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:651)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:321)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:222)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:166)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:637)
Caused by: javax.ejb.EJBException: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:720)
at com.sun.ejb.containers.util.pool.NonBlockingPool.getObject(NonBlockingPool.java:200)
at com.sun.ejb.containers.StatelessSessionContainer._getContext(StatelessSessionContainer.java:443)
... 35 more
Caused by: javax.ejb.CreateException: Could not create stateless EJB
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:528)
at com.sun.ejb.containers.StatelessSessionContainer.access$000(StatelessSessionContainer.java:90)
at com.sun.ejb.containers.StatelessSessionContainer$SessionContextFactory.create(StatelessSessionContainer.java:718)
... 37 more
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1138)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:134)
at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:145)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:122)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1625)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:469)
... 39 more
[/code]

Hope this helps. This strikes me as an amazingly severe bug.

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04

To sum up: I see two huge issues here.

The first is enormous. It appears that an @EJB reference in a servlet simply does not work properly. This may have to do with the somewhat coincidental fact that the EJB implementation's jar file is marked as a CDI bean archive--maybe something about CDI getting silently involved here is causing the NullPointerException.

The second is that for whatever reason @Instance does not notice that the beans that implement X may very well be stateless session beans. It [i]finds[/i] them OK, but does not recognize that the control flow should go through the Glassfish EJB infrastructure. Consequently, when you call a method on such instances, you call it like you're calling a POJO.

Best,
Laird

ljnelson
Offline
Joined: 2003-08-04

The issues are both present in 3.1 build 12 as well.

Best,
Laird