NPE in TransactionScopedEntityManager

[alesj]

I get this NPE while running JBossAS_testsuite_Seam:

Caused by: java.lang.NullPointerException
 at org.jboss.jpa.tx.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityM
anager.java:254)
 at org.jboss.jpa.tx.TransactionScopedEntityManager.getDelegate(TransactionScopedEntityManage
r.java:91)
 at org.jboss.seam.persistence.EntityManagerProxy.getDelegate(EntityManagerProxy.java:97)
 at org.hibernate.search.jpa.impl.FullTextEntityManagerImpl.getDelegate(FullTextEntityManager
Impl.java:154)

C:\projects\jboss5\trunk\testsuite>build one-test -Dtest=org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase
while running 'run -c profileservice'.
You build profileservice config by runnning 'build profileservice-config' in testsuite. :-)

[wolfc]

It would appear that the xpcResolver isn't injected into the PersistenceUnitDeployment.

[alesj]

"wolfc" wrote:
It would appear that the xpcResolver isn't injected into the PersistenceUnitDeployment.

Who's fault is this?

[alrubinger]

Perhaps you need this change in "profileservice" config?

http://fisheye.jboss.org/browse/JBossAS/trunk/ejb3/src/resources/META-INF/jpa-deployers-jboss-beans.xml?r1=76365&r2=80452

S,
ALR

[alesj]

"ALRubinger" wrote:
Perhaps you need this change in "profileservice" config?

Could be.
But this is your job to provide it. ;-)
Me == know nothing about EJB3.
Me == wanna run Seam apps in JBoss5. ;-)

[alrubinger]

Ah, but EJB3 Team doesn't know about the profileservice / Seam tests.

No regressions in EJB3 TestSuite + AS TestSuite + TCK == Valid Commit

That said, I'll take a look at the configs, lazy. ;)

S,
ALR

[alrubinger]

That's not it; "profileservice" config has:

<bean name="XPCResolver" class="org.jboss.ejb3.stateful.EJB3XPCResolver"/>

...as expected in deployers/ejb3.deployer/META-INF/jpa-deployers-jboss-beans.xml.

The issue is that @Inject is not getting called on setXPCResolver() of PersistenceUnitDeployment before the SeamListener (ServletContext) does its initialization. From the stacktrace when assertions are enabled:

Contexts.startup(ScopeType) line: 278
ServletLifecycle.endInitialization() line: 112
Initialization.init() line: 727
SeamListener.contextInitialized(ServletContextEvent) line: 34
StandardContext.listenerStart() line: 3910

S,
ALR

[alrubinger]

Some more context, then onto Seam Team for the answers:

PersistenceUnitDeployment.getXPCResolver() line: 208
TransactionScopedEntityManager.getEntityManager() line: 253
TransactionScopedEntityManager.getDelegate() line: 91
EntityManagerProxy.getDelegate() line: 97
FullTextEntityManagerImpl.getDelegate() line: 154
FullTextEntityManagerProxy(EntityManagerProxy).getDelegate() line: 97
IndexerAction.getFullTextSession() line: 65
IndexerAction.indexAllClasses(Class...) line: 71
IndexerAction.index() line: 44

Bringing us to NPE.

IndexerAction is a backing bean w/ @Stateful, and in @Create does this call to "index()". These EM Proxies were not supplied by EJB3.

We'll apply MC Team rules here. Give us a failing test case showing we're doing something wrong, and we'll fix it. ;)

S,
ALR

[alesj]

"ALRubinger" wrote:
Give us a failing test case showing we're doing something wrong, and we'll fix it. ;)

What's wrong with this?

"alesj" wrote:
C:\projects\jboss5\trunk\testsuite>build one-test -Dtest=org.jboss.test.deployers.seam.test.SeamDvdExampleUnitTestCase
while running 'run -c profileservice'.
You build profileservice config by runnning 'build profileservice-config' in testsuite. :-)

[alrubinger]

"alesj" wrote:
What's wrong with this?

I just gave 3 posts explaining it. :)

The EM proxies are not what we supplied from jpa-deployers.

S,
ALR

[alrubinger]

I'm seeing this as well in ejb30-persistence.

So now it becomes my problem.

S,
ALR

[alrubinger]

This NPE was introduced sometime inbetween revisions 80506 and 80510, I suspect MC upgrades?

@see after the EJB3 and jpa-deployers upgrade all is fine:

http://jboss.hudson.alrubinger.com/job/EJB3_Integration_TestSuite_AS_TRUNK/34/

And testing locally I see r80506 passes the regressing tests.

S,
ALR

[alrubinger]

And to again highlight the real cause:

"ALRubinger" wrote:
The issue is that @Inject is not getting called on setXPCResolver() of PersistenceUnitDeployment

To find out why not is to find the answer. Volley back to Ales. :)

S,
ALR

[alesj]

"ALRubinger" wrote:
The issue is that @Inject is not getting called on setXPCResolver() of PersistenceUnitDeployment

With the following design

 AbstractBeanMetaData beanMetaData = new AbstractBeanMetaData(name, PersistenceUnitDeployment.class.getName());
 BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(beanMetaData);
 builder.setConstructorValue(pu);
 addDependencies(builder, metaData);

 unit.addAttachment(BeanMetaData.class, builder.getBeanMetaData());

I see a couple of possible issues:
1) somebody else is also putting some BMD under BMD.class.getName attachment -- hence overlapping/'overridding' our PU
2) there might be zero / multiple matching XPCResolvers -- or do we chech somewhere that this PU is in Installed state?
3) how do we know this PU is gonna be handled by MC before that EJB -- where is the explicit dependency?

[alesj]

And this is not good:

 @Inject
 public void setXPCResolver(XPCResolver xpcResolver)
 {
 assert xpcResolver != null : "xpcResolver is null";
 this.xpcResolver = xpcResolver;
 }

As MC nullifies properties on uninstall. ;-)