[JBoss JIRA] (AS7-6815) Jboss7.1.1 EJB2 Entity Finder Return NULL attribute
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6815?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-6815:
-------------------------------------
Is this reproducible on EAP 6.1.0.Alpha1?
> Jboss7.1.1 EJB2 Entity Finder Return NULL attribute
> ---------------------------------------------------
>
> Key: AS7-6815
> URL: https://issues.jboss.org/browse/AS7-6815
> Project: Application Server 7
> Issue Type: Task
> Components: Application Client
> Affects Versions: 7.1.1.Final
> Environment: Windows 7, JDK1.6 , Jboss7.1.1
> Reporter: yan chiou tua
> Assignee: Stuart Douglas
> Labels: EJB2, Entity, Finder, Jboss7.1.1, NULL, Return, attribute
>
> Hi,
> I am migrating EJB2 project to Jboss7.1.1 from Jboss4.2.2 and encounter below error. Thanks and appreciated if any help or quick feedback as this is an *urgent* project migration for me. Previuosly this EJB2 project is running no problem on Jboss4.2.2 and Jboss6 (i have try on Jboss6 before go to Jboss7) which I able to get the value from entity finder.
> I have attached errors message and my code snippet as below:-
> 15:06:19,139 ERROR [org.jboss.ejb3.invocation] (http-LOCALHOST-127.0.0.1-8088-1) JBAS014134: EJB Invocation failed on component UserLogging for method public abstract com.xxx.adminData.userLogin.model.UserLoggingModel *com.xxx.adminData.userLogin.ejb.UserLogging.getModel()*: javax.ejb.EJBTransactionRolledbackException
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:139) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:204) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:306) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$2.processInvocation(EjbExceptionTransformingInterceptorFactories.java:89) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanPrimaryKeyInterceptor.processInvocation(EntityBeanPrimaryKeyInterceptor.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at com.xxx.adminData.userLogin.ejb.UserLogging$$$view320.getModel(Unknown Source) [eportal.jar:]
> at com.xxx.adminData.userLogin.controller.SessionControllerEJB.addUserLogging(SessionControllerEJB.java:71) [eportal.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_03]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_03]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_03]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_03]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:202) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:306) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$2.processInvocation(EjbExceptionTransformingInterceptorFactories.java:89) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at com.xxx.adminData.userLogin.controller.SessionController$$$view324.addUserLogging(Unknown Source) [eportal.jar:]
> at com.xxx.adminData.userLogin.controller.UserLoginControllerEJB.login(UserLoginControllerEJB.java:158) [eportal.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_03]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_03]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_03]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_03]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$2.processInvocation(EjbExceptionTransformingInterceptorFactories.java:89) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
> at com.xxx.adminData.userLogin.controller.UserLoginController$$$view341.login(Unknown Source) [eportal.jar:]
> at com.xxx.adminApp.web.login.LoginHelper.login(LoginHelper.java:157) [eportal.jar:]
> at org.apache.jsp.WEB_002dINF.jsp.common.loginAction_jsp._jspService(loginAction_jsp.java:80)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:253)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:840)
> at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:622)
> at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:560)
> at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:488)
> at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238) [org.springframework.web.servlet-3.0.5.RELEASE.jar:3.0.5.RELEASE]
> at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250) [org.springframework.web.servlet-3.0.5.RELEASE.jar:3.0.5.RELEASE]
> at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047) [org.springframework.web.servlet-3.0.5.RELEASE.jar:3.0.5.RELEASE]
> at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817) [org.springframework.web.servlet-3.0.5.RELEASE.jar:3.0.5.RELEASE]
> at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719) [org.springframework.web.servlet-3.0.5.RELEASE.jar:3.0.5.RELEASE]
> at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644) [org.springframework.web.servlet-3.0.5.RELEASE.jar:3.0.5.RELEASE]
> at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560) [org.springframework.web.servlet-3.0.5.RELEASE.jar:3.0.5.RELEASE]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:840)
> at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:622)
> at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:560)
> at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:488)
> at com.xxx.adminApp.web.URLRequestFilter.doFilter(URLRequestFilter.java:255) [eportal.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at com.xxx.adminApp.web.CompressionFilter.doFilter(CompressionFilter.java:248) [eportal.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at com.xxx.adminApp.web.XSSFilter.doFilter(XSSFilter.java:52) [eportal.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:67)
> at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:48)
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_03]
> *Caused by: java.lang.NullPointerException*
> at org.jboss.as.ejb3.component.entity.entitycache.ReferenceCountingEntityCache$CacheEntry.access$000(ReferenceCountingEntityCache.java:146) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.component.entity.entitycache.ReferenceCountingEntityCache.get(ReferenceCountingEntityCache.java:70) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:61) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:202) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 160 more
> +standalone-full-ha.xml on data source configuration part+
> <datasource jndi-name="java:/xxDS" pool-name="xxDS" enabled="true" use-java-context="true">
> ...
> </datasource>
> <driver name="sqlserver" module="com.microsoft.sqlserver">
> <driver-class>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver-class>
> <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
> </driver>
> +ejb-jar.xml+
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:ejb="http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1">
> <enterprise-beans>
> <session>
> <description>Session Controller</description>
> <ejb-name>SessionController</ejb-name>
> <local-home>com.xxx.adminData.userLogin.controller.SessionControllerHome</local-home>
> <local>com.xxx.adminData.userLogin.controller.SessionController</local>
> <ejb-class>com.xxx.adminData.userLogin.controller.SessionControllerEJB</ejb-class>
> <session-type>Stateless</session-type>
> <transaction-type>Container</transaction-type>
> <ejb-local-ref>
> <ejb-ref-name>adminData/ejb/UserLogging</ejb-ref-name>
> <ejb-ref-type>Entity</ejb-ref-type>
> <local-home>com.xxx.adminData.userLogin.ejb.UserLoggingHome</local-home>
> <local>com.xxx.adminData.userLogin.ejb.UserLogging</local>
> <ejb-link>UserLogging</ejb-link>
> </ejb-local-ref>
> </session>
> <entity>
> <description>User Logging</description>
> <ejb-name>UserLogging</ejb-name>
> <local-home>com.xxx.adminData.userLogin.ejb.UserLoggingHome</local-home>
> <local>com.xxx.adminData.userLogin.ejb.UserLogging</local>
> <ejb-class>com.xxx.adminData.userLogin.ejb.UserLoggingEJB</ejb-class>
> <persistence-type>Container</persistence-type>
> <prim-key-class>com.xxx.adminData.userLogin.ejb.UserLoggingPK</prim-key-class>
> <reentrant>true</reentrant>
> <cmp-version>2.x</cmp-version>
> <abstract-schema-name>USER_LOGGING</abstract-schema-name>
> <cmp-field>
> <field-name>loggingId</field-name>
> </cmp-field>
> <cmp-field>
> <field-name>userId</field-name>
> </cmp-field>
> <cmp-field>
> <field-name>organizationId</field-name>
> </cmp-field>
> <cmp-field>
> <field-name>loginTimeStamp</field-name>
> </cmp-field>
> <cmp-field>
> <field-name>logoutTimeStamp</field-name>
> </cmp-field>
> <cmp-field>
> <field-name>systemTypeId</field-name>
> </cmp-field>
> <cmp-field>
> <field-name>systemId</field-name>
> </cmp-field>
> <query>
> <query-method>
> <method-name>findCurrentUserLogin</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </query-method>
> <ejb-ql>select OBJECT(e) from USER_LOGGING e where e.userId = ?1 and e.logoutTimeStamp = e.loginTimeStamp</ejb-ql>
> </query>
> </entity>
> </enterprise-beans>
> </ejb-jar>
> +jbosscmp-jdbc.xml+
> <?xml version="1.0" encoding="UTF-8"?>
> <jbosscmp-jdbc>
> <defaults>
> <datasource>java:/xxDS</datasource>
> </defaults>
> <enterprise-beans>
> <entity>
> <ejb-name>UserLogging</ejb-name>
> <table-name>USER_LOGGING</table-name>
> <create-table>false</create-table>
> <remove-table>false</remove-table>
> <cmp-field>
> <field-name>loggingId</field-name>
> <column-name>loggingId</column-name>
> <jdbc-type>VARCHAR</jdbc-type>
> <sql-type>VARCHAR(35)</sql-type>
> </cmp-field>
> <cmp-field>
> <field-name>userId</field-name>
> <column-name>userId</column-name>
> <jdbc-type>VARCHAR</jdbc-type>
> <sql-type>VARCHAR(20)</sql-type>
> </cmp-field>
> <cmp-field>
> <field-name>organizationId</field-name>
> <column-name>organizationId</column-name>
> <jdbc-type>VARCHAR</jdbc-type>
> <sql-type>VARCHAR(26)</sql-type>
> </cmp-field>
> <cmp-field>
> <field-name>loginTimeStamp</field-name>
> <column-name>loginTimeStamp</column-name>
> </cmp-field>
> <cmp-field>
> <field-name>logoutTimeStamp</field-name>
> <column-name>logoutTimeStamp</column-name>
> </cmp-field>
> <cmp-field>
> <field-name>systemTypeId</field-name>
> <column-name>systemTypeId</column-name>
> </cmp-field>
> <cmp-field>
> <field-name>systemId</field-name>
> <column-name>systemId</column-name>
> </cmp-field>
> </entity>
> </enterprise-beans>
> </jbosscmp-jdbc>
> +SessionControllerEJB.java+
> public String addUserLogging(UserLoginModel model){
> InitialContext initial = new InitialContext();
> UserLoggingHome userLoggingHome = (UserLoggingHome) PortableRemoteObject.narrow(initial.lookup("java:app/xxx/UserLogging!com.xxx.adminData.userLogin.ejb.UserLoggingHome"),
> UserLoggingHome.class);
> UserLogging userlogging = *userLoggingHome.findCurrentUserLogin(model.getUserId())*;
> }
> +UserLogging.java+
> public interface UserLogging extends EJBLocalObject {
> public UserLoggingModel getModel();
> public String getLoggingId();
> public void setLoggingId(String loggingId);
> ...
> }
> +UserLoggingHome.java+
> public interface UserLoggingHome extends EJBLocalHome {
> public UserLogging findCurrentUserLogin(String user) throws FinderException;
> ...
> }
> +UserLoggingEJB.java+
> public abstract class UserLoggingEJB implements EntityBean {
> private EntityContext ctx;
> public String loggingId;
> public String userId;
> public String organizationId;
> public Timestamp loginTimeStamp;
> public Timestamp logoutTimeStamp;
> public long systemTypeId;
> public long systemId;
> public abstract String getLoggingId();
> public abstract void setLoggingId(String loggingId);
> public UserLoggingModel getModel() {
> UserLoggingModel userLoggingModel = new UserLoggingModel(getLoggingId(), getUserId(), getOrganizationId(), getLoginTimeStamp(),
> getLogoutTimeStamp());
> return userLoggingModel;
> }
> ...
> }
> Thanks in advanced!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (AS7-6818) Allow socket-binding-group-refType to override default-interface
by Todd Trimmer (JIRA)
[ https://issues.jboss.org/browse/AS7-6818?page=com.atlassian.jira.plugin.s... ]
Todd Trimmer updated AS7-6818:
------------------------------
Description:
I want all the host controllers in my domain to use the same socket-binding-group. However, each host controller can have multiple servers, each with its own IP, but each IP still reuses the same port number (yet still a unique IP+port combo). The problem is that the socket-binding-group-refType will not let me override the @default-interface value from the referent socket-binding-group. I am forced to create a second, equally verbose, socket-binding-group exactly like the first group in every way, except for the @default-interface. I wish to avoid this. My particular scenario cannot rely on @port-offset because my hardware load-balancer needs all nodes in the same pool to use the same ports.
Under my proposal, the host.xml could thus more easily be written like this:
...
<interfaces>
<interface name="public">
<inet-address value="10.10.10.1" />
</interface>
<interface name="public-two">
<inet-address value="10.10.10.2" />
</interface>
</interfaces>
...
<servers>
<server name="server-one" group="prod-server-group" auto-start="true">
<jvm name="jvm6g" />
</server>
<server name="server-two" group="prod-server-group" auto-start="false">
<jvm name="jvm2g" />
<socket-binding-group ref="standard-sockets" default-interface="public-two" />
</server>
</servers>
...
This alleviates the burden of having to define a second socket-binding-group in domain.xml and maintaining the same set of socket-binding definitions in two places.
was:
I want all the host controllers in my domain to use the same socket-binding-group. However, each host controller can have multiple servers, each with its own IP, but each IP still reuses the same port number (yet still a unique IP+port combo). The problem is that the socket-binding-group-refType will not let me override the @default-interface value from the referent socket-binding-group. I am forced to create a second, equally verbose, socket-binding-group exactly like the first group in every way, except for the @default-interface. I wish to avoid this. My particular scenario cannot rely on @port-offset because my hardware load-balancer needs all nodes in the same pool to use the same ports.
This could be easily solved if the socket-binding-group-refType could have a @default-interface attribute to override the socket-binding-group[@default-interface] it references.
The host.xml could thus look like this:
...
<interfaces>
<interface name="public">
<inet-address value="10.10.10.1" />
</interface>
<interface name="public-two">
<inet-address value="10.10.10.2" />
</interface>
</interfaces>
...
<servers>
<server name="server-one" group="prod-server-group" auto-start="true">
<jvm name="jvm6g" />
</server>
<server name="server-two" group="@prod-server-group" auto-start="false">
<jvm name="jvm2g" />
<socket-binding-group ref="standard-sockets" default-interface="public-two" />
</server>
</servers>
...
This alleviates the burden of having to define a second socket-binding-group in domain.xml and maintaining the same set of socket-binding definitions in two places.
> Allow socket-binding-group-refType to override default-interface
> ----------------------------------------------------------------
>
> Key: AS7-6818
> URL: https://issues.jboss.org/browse/AS7-6818
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 7.1.1.Final
> Reporter: Todd Trimmer
> Assignee: Brian Stansberry
> Priority: Optional
> Labels: configuration, domain, host-controller
>
> I want all the host controllers in my domain to use the same socket-binding-group. However, each host controller can have multiple servers, each with its own IP, but each IP still reuses the same port number (yet still a unique IP+port combo). The problem is that the socket-binding-group-refType will not let me override the @default-interface value from the referent socket-binding-group. I am forced to create a second, equally verbose, socket-binding-group exactly like the first group in every way, except for the @default-interface. I wish to avoid this. My particular scenario cannot rely on @port-offset because my hardware load-balancer needs all nodes in the same pool to use the same ports.
> Under my proposal, the host.xml could thus more easily be written like this:
> ...
> <interfaces>
> <interface name="public">
> <inet-address value="10.10.10.1" />
> </interface>
> <interface name="public-two">
> <inet-address value="10.10.10.2" />
> </interface>
> </interfaces>
> ...
> <servers>
> <server name="server-one" group="prod-server-group" auto-start="true">
> <jvm name="jvm6g" />
> </server>
> <server name="server-two" group="prod-server-group" auto-start="false">
> <jvm name="jvm2g" />
> <socket-binding-group ref="standard-sockets" default-interface="public-two" />
> </server>
> </servers>
> ...
> This alleviates the burden of having to define a second socket-binding-group in domain.xml and maintaining the same set of socket-binding definitions in two places.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (AS7-6818) Allow socket-binding-group-refType to override default-interface
by Todd Trimmer (JIRA)
Todd Trimmer created AS7-6818:
---------------------------------
Summary: Allow socket-binding-group-refType to override default-interface
Key: AS7-6818
URL: https://issues.jboss.org/browse/AS7-6818
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 7.1.1.Final
Reporter: Todd Trimmer
Assignee: Brian Stansberry
Priority: Optional
I want all the host controllers in my domain to use the same socket-binding-group. However, each host controller can have multiple servers, each with its own IP, but each IP still reuses the same port number (yet still a unique IP+port combo). The problem is that the socket-binding-group-refType will not let me override the @default-interface value from the referent socket-binding-group. I am forced to create a second, equally verbose, socket-binding-group exactly like the first group in every way, except for the @default-interface. I wish to avoid this. My particular scenario cannot rely on @port-offset because my hardware load-balancer needs all nodes in the same pool to use the same ports.
This could be easily solved if the socket-binding-group-refType could have a @default-interface attribute to override the socket-binding-group[@default-interface] it references.
The host.xml could thus look like this:
...
<interfaces>
<interface name="public">
<inet-address value="10.10.10.1" />
</interface>
<interface name="public-two">
<inet-address value="10.10.10.2" />
</interface>
</interfaces>
...
<servers>
<server name="server-one" group="prod-server-group" auto-start="true">
<jvm name="jvm6g" />
</server>
<server name="server-two" group="@prod-server-group" auto-start="false">
<jvm name="jvm2g" />
<socket-binding-group ref="standard-sockets" default-interface="public-two" />
</server>
</servers>
...
This alleviates the burden of having to define a second socket-binding-group in domain.xml and maintaining the same set of socket-binding definitions in two places.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (AS7-6761) Deployment replace causes invalid state in DUP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6761?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6761:
----------------------------------------------
Stuart Douglas <sdouglas(a)redhat.com> made a comment on [bug 924562|https://bugzilla.redhat.com/show_bug.cgi?id=924562]
This is resolved for non-OSGi deployments. I think we should resolve this issue and create a new one for the OSGi problems, as the OSGi issue is not so much caused by dependency changes but rather by explicit start/stop operations on the bundle.
> Deployment replace causes invalid state in DUP
> ----------------------------------------------
>
> Key: AS7-6761
> URL: https://issues.jboss.org/browse/AS7-6761
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Attachments: v200.jar, v201.jar, webapp-v200.war
>
>
> Webapp A depends on deployment B. Replacing B causes NPE in JPAInterceptorProcessor
> {code}
> 12:52:05,712 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:52:05,889 INFO [org.jboss.as.server] (XNIO-1 task-8) JBAS018559: Deployed "v200.jar" (runtime-name : "v200.jar")
> 12:52:37,207 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "webapp-v200.war" (runtime-name: "webapp-v200.war")
> 12:52:37,349 INFO [org.jboss.web] (ServerService Thread Pool -- 52) JBAS018210: Register web context: /webapp-v200
> 12:52:37,436 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "webapp-v200.war" (runtime-name : "webapp-v200.war")
> 12:53:20,252 INFO [org.jboss.web] (ServerService Thread Pool -- 57) JBAS018224: Unregister web context: /webapp-v200
> 12:53:20,272 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment v200.jar (runtime-name: v200.jar) in 25ms
> 12:53:20,274 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:53:20,293 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of deployment "webapp-v200.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> {code}
> What might be happening here is that replacing B causes ModuleB to go down. Phase FIRST_MODULE_USE of A depends on ModuleB, which causes a call to undeploy() on the DUPs for A. When ModuleB becomes available again, deploy() is called on the DUPs for A again. Possibly because of the cleanup phase, necessary state is lost and we see a NPE.
> AFAICS, this is a variation of the feature request that DUPs support multiple calls to deploy/undeploy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBRULES-2238) Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2238?page=com.atlassian.jira.plug... ]
Geoffrey De Smet resolved JBRULES-2238.
---------------------------------------
Fix Version/s: 6.0.0.Alpha1
(was: FUTURE)
Resolution: Done
Could reproduce performance loss with a recent version of drools
> Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBRULES-2238
> URL: https://issues.jboss.org/browse/JBRULES-2238
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: drools-core (expert)
> Affects Versions: 5.0.1.FINAL
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Fix For: 6.0.0.Alpha1
>
>
> The current accumulate implementation has a severe performance loss in the drools-solver context.
> Edson said that this issue could be the culprit.
> However, for this to be implemented the true modify feature should first be implemented.
> See the discussion "Why is this DRL twice as slow?" on the dev user list.
> From IRC:
> <ge0ffrey> more and more of my experiments show the poisones nature of accumulate for drools-solver. Probably because they are backwards chained (as I understand it?). Of course accummulate is great for many use cases, just not drools-solver.
> <ge0ffrey> The problem is, I have no way to workaround them. I need the sum of my logically inserted objects.
> <etirelli> ge0ffrey: no, accumulate are implemented as forward chain as usual
> <etirelli> the problem is that a left-input retraction on an accumulate node will throw away any result and a leftinput assert will recalculate everything from scratch
> <ge0ffrey> What do you mean by "must fully recalculate"?
> <etirelli> mean from scratch
> <ge0ffrey> Why does it do that?
> <etirelli> remember that modify = retract+assert
> <ge0ffrey> And right-input retractions won't recalculate everything from scratch?
> <etirelli> no... right input are incremental
> <ge0ffrey> would making leftinput assert incremental too be possible?
> <etirelli> ge0ffrey: the only way to do left-input incremental is with a feature called "true modify"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (AS7-6778) Configure EJB3/MDB with an individual thread pool for each EJB.
by Weixing Sun (JIRA)
[ https://issues.jboss.org/browse/AS7-6778?page=com.atlassian.jira.plugin.s... ]
Weixing Sun commented on AS7-6778:
----------------------------------
Thanks for your comments, David! it sounds strange to know JBoss is showing JBossThread.run() instead of the real logical code in my profiling tools(visualvm). Then, would you please let me know how I can see what's happening after the run() method called?
> Configure EJB3/MDB with an individual thread pool for each EJB.
> ---------------------------------------------------------------
>
> Key: AS7-6778
> URL: https://issues.jboss.org/browse/AS7-6778
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Jeremy Whiting
> Assignee: jaikiran pai
>
> For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application.
> For example
> PoolA - EJB Dog
> PoolB - EJB Cat
> To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBRULES-3657) Eval bytecode not correctly generated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3657?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on JBRULES-3657:
--------------------------------------------------
Radovan Synek <rsynek(a)redhat.com> made a comment on [bug 860698|https://bugzilla.redhat.com/show_bug.cgi?id=860698]
Verified on 5.3.1.BRMS roll-up #1
> Eval bytecode not correctly generated
> -------------------------------------
>
> Key: JBRULES-3657
> URL: https://issues.jboss.org/browse/JBRULES-3657
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.3.1.Final
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 5.3.2.Final
>
>
> When a declaration does a double dereferencing, with the value of the method returned by the second dereferencing being a primitive type, the bytecode of the eval class using it is not correctly generated and causes, when instanced, an Exception like the following:
> Exception in thread "main" java.lang.VerifyError: (class: gov/ssa/asa/rules/Rule_vhrGroupingByLocationEval0Invoker, method: evaluate signature: (Lorg/drools/spi/Tuple;[Lorg/drools/rule/Declaration;Lorg/drools/WorkingMemory;Ljava/lang/Object;)Z) Expecting to find integer on stack
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
> at java.lang.Class.getConstructor0(Class.java:2699)
> at java.lang.Class.newInstance0(Class.java:326)
> at java.lang.Class.newInstance(Class.java:308)
> at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:413)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (JBRULES-3657) Eval bytecode not correctly generated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3657?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on JBRULES-3657:
--------------------------------------------------
Radovan Synek <rsynek(a)redhat.com> changed the Status of [bug 860698|https://bugzilla.redhat.com/show_bug.cgi?id=860698] from ON_QA to VERIFIED
> Eval bytecode not correctly generated
> -------------------------------------
>
> Key: JBRULES-3657
> URL: https://issues.jboss.org/browse/JBRULES-3657
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.3.1.Final
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 5.3.2.Final
>
>
> When a declaration does a double dereferencing, with the value of the method returned by the second dereferencing being a primitive type, the bytecode of the eval class using it is not correctly generated and causes, when instanced, an Exception like the following:
> Exception in thread "main" java.lang.VerifyError: (class: gov/ssa/asa/rules/Rule_vhrGroupingByLocationEval0Invoker, method: evaluate signature: (Lorg/drools/spi/Tuple;[Lorg/drools/rule/Declaration;Lorg/drools/WorkingMemory;Ljava/lang/Object;)Z) Expecting to find integer on stack
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
> at java.lang.Class.getConstructor0(Class.java:2699)
> at java.lang.Class.newInstance0(Class.java:326)
> at java.lang.Class.newInstance(Class.java:308)
> at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:413)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (AS7-6778) Configure EJB3/MDB with an individual thread pool for each EJB.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6778?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-6778:
----------------------------------
The reason you see 90% of CPU cycles being spent in JBossThread.run() is that nearly all of our threads are JBossThreads, thus all work that the server does will ultimately show up as being in this method one way or another. It is not indicative of a problem - indeed if you saw 0% usage in JBossThread.run(), it would mean that the server isn't doing anything at all.
> Configure EJB3/MDB with an individual thread pool for each EJB.
> ---------------------------------------------------------------
>
> Key: AS7-6778
> URL: https://issues.jboss.org/browse/AS7-6778
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Jeremy Whiting
> Assignee: jaikiran pai
>
> For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application.
> For example
> PoolA - EJB Dog
> PoolB - EJB Cat
> To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (AS7-5884) CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5884?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5884:
----------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 901159|https://bugzilla.redhat.com/show_bug.cgi?id=901159] from ON_QA to VERIFIED
> CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5884
> URL: https://issues.jboss.org/browse/AS7-5884
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Kabir Khan
> Priority: Critical
> Labels: deployers, domain, eap, jboss
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> If a deployment in a domain is the same file, deployed with different names to different server-groups, it become the same SHA1.
> In that case the stored content will not be updated and the <deployments> section become a new entry which is used by the second server group.
> But if one of the deployments will be undeployed or updated the content is complete removed but the second deployment entry is still available.
> The second deployment can be used as long as there is a action to it (e.g. restart).
> In that case a FATAL error is thrown:
> [Host Controller] 11:43:36,493 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "prod.ear")]) - failure description: "JBAS010876: No deployment content with hash 0807c2c28e5feebb8dfb905788e53b104ecb89fc is available in the deployment content repository for deployment 'prod.ear'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> [Host Controller] 11:43:36,496 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months