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#4239741
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239741
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
