https://issues.jboss.org/browse/WFLY-5208 seems to be related and mention that we can't fix the NPE and if we did fix it, there would be other errors, caused by "deployment is being torn down while the app is still processing requests".
On 07/07/2016 01:27 PM, Scott Marlow wrote:
https://lists.jboss.org/mailman/listinfo/wildfly-dev
On 07/07/2016 01:13 PM, James Perkins wrote:
I think you need to look at why the cache is null. In
the org.jboss.as.ejb3.component.stateful.StatefulSessionComponent it's
only null if the start of the component hasn't been invoked or the done
method was invoked.
From the call stack, we must of called "done" already, as the cache
would of been used previously during the test (implying that it was
non-null previously).
[1]
https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9#file-gistfile1-txt-L41
_______________________________________________
On Thu, Jul 7, 2016 at 9:23 AM, Scott Marlow <smarlow@redhat.com
<mailto:smarlow@redhat.com>> wrote:
Often when running a NoSQL unit test, I'm seeing a NPE in
org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.isRemoved(). I
understand that we should never allow a NullPointerException to be
thrown, however, does anyone know what the correct course of action
should be? Ensuring that ejbComponent.getCache() never returns null
could be one approach. Or perhaps callers to ejbComponent.getCache()
should check for null being returned. Could there be a missing
application dependency on the cache?
StatefulSessionObjectReferenceImpl currently contains:
@Override
public boolean isRemoved() {
if (!removed) {
return !ejbComponent.getCache().contains(id);
}
return true;
}
Thanks,
Scott
[1] https://gist.github.com/scottmarlow/9f9822e9d4609850d49099c3c5234ed9
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
wildfly-dev mailing list
wildfly-dev@lists.jboss.org