[Installation, Configuration & DEPLOYMENT] - Re: Error while deploying a Visual JSF on JBoss 5.1.0 GA
by CeylonSoft
Hi Wolfgang,
Here is the contents of WEB-INF/lib:
Directory of F:\tmp\calendar\WEB-INF\lib
06/24/2009 08:42 AM .
06/24/2009 08:42 AM ..
06/23/2009 09:24 PM 52,191 appbase.jar
06/23/2009 09:24 PM 116,021 commons-beanutils.jar
06/23/2009 09:24 PM 165,640 commons-collections.jar
06/23/2009 09:24 PM 106,929 commons-digester.jar
06/23/2009 09:24 PM 21,890 commons-fileupload-1.0.jar
06/23/2009 09:24 PM 30,914 commons-logging.jar
06/23/2009 09:24 PM 242,452 dataprovider.jar
06/23/2009 09:24 PM 30,171 errorhandler.jar
06/23/2009 09:24 PM 37,275 json-2.jar
06/23/2009 09:24 PM 20,512 jstl.jar
06/23/2009 09:24 PM 173,394 sqlx.jar
06/23/2009 09:24 PM 388,851 standard.jar
06/23/2009 09:24 PM 2,478,333 webui-jsf-suntheme.jar
06/23/2009 09:24 PM 3,529,565 webui-jsf.jar
14 File(s) 7,394,138 bytes
2 Dir(s) 1,499,037,237,248 bytes free
F:\tmp\calendar\WEB-INF\lib>
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239748#4239748
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239748
17 years
[Microcontainer] - Deployers Ordering
by richard.opalka＠jboss.com
I have some troubles with deployers ordering if multiple deployers
provide many inputs. So I'm trying to understand how deployers
ordering works internally.
I'd expect the following test to fail:
---
// copy paste from DeployerFlowUnitTestCase
public void testTransitionOrdering() throws Exception
{
DeployerClient main = createMainDeployer();
TestFlowDeployer deployer1 = new TestFlowDeployer("A");
deployer1.setInputs("3");
deployer1.setOutputs("4");
addDeployer(main, deployer1);
TestFlowDeployer deployer2 = new TestFlowDeployer("B");
deployer2.setInputs("1");
deployer2.setOutputs("2");
addDeployer(main, deployer2);
TestFlowDeployer deployer3 = new TestFlowDeployer("C");
deployer3.setInputs("2");
deployer3.setOutputs("3");
addDeployer(main, deployer3);
Deployment deployment = createSimpleDeployment("TransitionOrdering");
main.addDeployment(deployment);
main.process();
assertEquals(3, deployer1.getDeployOrder());
assertEquals(1, deployer2.getDeployOrder());
assertEquals(2, deployer3.getDeployOrder());
assertEquals(-1, deployer1.getUndeployOrder());
assertEquals(-1, deployer2.getUndeployOrder());
assertEquals(-1, deployer3.getUndeployOrder());
main.removeDeployment(deployment);
main.process();
assertEquals(3, deployer1.getDeployOrder());
assertEquals(1, deployer2.getDeployOrder());
assertEquals(2, deployer3.getDeployOrder());
assertEquals(4, deployer1.getUndeployOrder());
assertEquals(6, deployer2.getUndeployOrder());
assertEquals(5, deployer3.getUndeployOrder());
main.addDeployment(deployment);
main.process();
assertEquals(9, deployer1.getDeployOrder());
assertEquals(7, deployer2.getDeployOrder());
assertEquals(8, deployer3.getDeployOrder());
assertEquals(4, deployer1.getUndeployOrder());
assertEquals(6, deployer2.getUndeployOrder());
assertEquals(5, deployer3.getUndeployOrder());
}
---
I'd expect this test to fail because there's no deployer with "1" output?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239744#4239744
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239744
17 years
[EJB 3.0] - SessionContext not injected when using scoped class loaders
by rubenvdg
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
17 years