7:32 a.m.
Summary: When I configure the ear-deployer with "isolated=true" to have scoped
class loading for each EAR, the session context is not injected (through @Resource) in my
stateless session bean. When I switch isolated class loading off, the session context is
injected. I package a more recent Hibernate version in the EAR. (so, the configuration of
"isolated" does have an effect on the hibernate version used.)
More elaborate version:
I use JBoss 4.2.3.GA, running on Sun Java "1.6.0_14", on Linux amd64. The JBoss
version is the version compiled for JDK5, but running on JDK6, with some libraries copied
from the "client" dir to the "lib/endorsed" dir as mentioned in the
release notes.
We want to standardize on a specific Hibernate version, independently of the Hibernate
version that comes with JBoss. For this reason, we build our ear with the Hibernate
libraries included. We use the following maven dependencies for Hibernate.
<dependency>
| <groupId>org.hibernate</groupId>
| <artifactId>hibernate-validator</artifactId>
| <version>3.0.0.ga</version>
| </dependency>
| <dependency>
| <groupId>org.hibernate</groupId>
| <artifactId>hibernate-search</artifactId>
| <version>3.0.0.GA</version>
| <exclusions>
| <exclusion>
| <groupId>org.hibernate</groupId>
| <artifactId>ejb3-persistence</artifactId>
| </exclusion>
| </exclusions>
| </dependency>
| <dependency>
| <groupId>org.slf4j</groupId>
| <artifactId>slf4j-api</artifactId>
| <version>1.5.6</version>
| </dependency>
| <dependency>
| <groupId>org.slf4j</groupId>
| <artifactId>slf4j-log4j12</artifactId>
| <version>1.5.6</version>
| </dependency>
|
We also configured Hibernate to use "cglib" instead of "javassist".
(We got VerifyErrors because of final methods when we used "javassist".) This is
configured in the file deploy/ejb3.deployer/META-INF/persistence.properties.
hibernate.bytecode.provider=cglib
To make sure that "our" version of the Hibernate libraries gets loaded, we
configure the ear-deployer and set the isolated property on "true". This, as far
as I understand it, means that when our application wants to load a class, the class
loader will first search the EAR for the required class, and if it is not found in there,
it will search the class in the libraries that come with the application server. It also
means that classes loaded by EAR1 cannot be seen by EAR2. This is the behaviour that we
want, independently of the Hibernate issue.
The framework code that we use (and have written), is available on ppwcode. The
implementation of the session bean where I have the problem, is a subclass of the
following abstract class JpaStatelessCrudDao. This is a generic class that implements CRUD
operations on any entity (PersistentBean). For the implementation of security, we
implemented a couple of annotations. These annotations are placed on the entity class and
define which JAAS roles can create, update and delete entities of that type. In a subclass
of JpaStatelessCrudDao, you need to implement the following abstract method.
protected abstract boolean isCallerInRole(String role);
We use a subclass of JpaStatelessCrudDao that is a stateless session bean. In that
context, the implementation of "isCallerInRole" is as follows.
@Override
| protected boolean isCallerInRole(String role) {
| return getSessionContext().isCallerInRole(role);
| }
The session context is injected, and the relevant code is the following.
public final SessionContext getSessionContext() {
| return $sessionContext;
| }
|
| public final void setSessionContext(SessionContext sessionContext) {
| $sessionContext = sessionContext;
| }
|
| @Resource
| private SessionContext $sessionContext;
When I run this code on JBoss 4.2.3.GA and call methods on the session bean (subclass of
JpaStatelessCrudDao), I get a NullPointerException because the session context is null.
The stacktrace looks as the following:
javax.ejb.EJBException: java.lang.NullPointerException
| at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:63)
| at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
| at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
| at
org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
| at
org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:81)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:72)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
| at $Proxy126.createPersistentBean(Unknown Source)
| 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 org.directwebremoting.impl.ExecuteAjaxFilter.doFilter(ExecuteAjaxFilter.java:34)
| at org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428)
| at org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:431)
| at org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:283)
| at org.directwebremoting.servlet.PlainCallHandler.handle(PlainCallHandler.java:52)
| at org.directwebremoting.servlet.UrlProcessor.handle(UrlProcessor.java:101)
| at org.directwebremoting.servlet.DwrServlet.doPost(DwrServlet.java:146)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
| at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
| at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at
org.ppwcode.vernacular.l10n_III.web.HttpRequestLocaleFilter.doRequestLocaleFilter(HttpRequestLocaleFilter.java:110)
| at
org.ppwcode.vernacular.l10n_III.web.HttpRequestLocaleFilter.doFilter(HttpRequestLocaleFilter.java:71)
| at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
| at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
| at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
| at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
| at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
| at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: java.lang.NullPointerException
| at
xxxxx.businesslogic.jpa.JpaStatelessCrudDao.isCallerInRole(JpaStatelessCrudDao.java:105)
| at
org.ppwcode.vernacular.persistence_III.dao.jpa.JpaStatelessCrudDao.callerInAtLeastOneOfRoles(JpaStatelessCrudDao.java:705)
| at
org.ppwcode.vernacular.persistence_III.dao.jpa.JpaStatelessCrudDao.isCreateAllowed(JpaStatelessCrudDao.java:637)
| at
org.ppwcode.vernacular.persistence_III.dao.jpa.JpaStatelessCrudDao.createPersistentBean(JpaStatelessCrudDao.java:382)
| 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 org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
| at
org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
| at
org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at
org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
|
What happens here is the following. We have an EJB3 backend that runs in an EAR on the
JBoss server. We also have a frontend running on the same JBoss server that is built with
Dojo and DWR. I try to create an entity through the frontend.
When we switch the isolated property in the ear-deployer back to "false", the
session context is injected and the application behaves as intended.
Is this a bug, or are we doing something wrong?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239741#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...