[JBoss JIRA] (WFLY-4386) EJB annotations ignored if classes are packaged as JBOSS modules
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/WFLY-4386?page=com.atlassian.jira.plugin.... ]
Tihomir Meščić commented on WFLY-4386:
--------------------------------------
Thanks for the quick response, I will try that.
I must say that this is VERY counter-intuitive. The class is completely the same, and yet the behaviour is different, depending on how you package your app.
> EJB annotations ignored if classes are packaged as JBOSS modules
> ----------------------------------------------------------------
>
> Key: WFLY-4386
> URL: https://issues.jboss.org/browse/WFLY-4386
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, EJB
> Affects Versions: JBoss AS7 7.1.1.Final
> Reporter: Tihomir Meščić
> Assignee: David Lloyd
>
> I have an EJB that writes something to the DB and I have a custom checked exception that is marked as @javax.ejb.ApplicationException(rollback=true), which means that when the exception is thrown, transaction should be rollbacked.
> {code:title=Test.java.java|borderStyle=solid}
> @ApplicationException(rollback=true)
> public class MyException extends Exception {
> {code}
>
> This exception is packaged in a separate JAR.
>
> When this JAR is included in the lib/ folder of the EAR with my EJB, everything works as expected (when the EJB throws MyException, the transaction is rollbacked).
> However, when this JAR is deployed as a JBOSS module (so, in jboss_folder/modules/... folder), and the EAR declares a dependency on this module (MANIFEST.MF -> Dependencies: ....) , then the transaction is NOT rollbacked. So the EJB container ignores the annotation.
>
> One workaround (that I don't really like) is to specify that this is an application exception in the jboss-ejb3.xml (then, the transaction will be rollbacked).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFLY-4363) Class (own class) not found Exception during trial of getting of StepExecutions with own classes in PersistentUserData
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4363?page=com.atlassian.jira.plugin.... ]
Cheng Fang resolved WFLY-4363.
------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> Class (own class) not found Exception during trial of getting of StepExecutions with own classes in PersistentUserData
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4363
> URL: https://issues.jboss.org/browse/WFLY-4363
> Project: WildFly
> Issue Type: Bug
> Components: Batch, EJB
> Affects Versions: 8.2.0.Final
> Environment: JRE 7, Maven build
> Reporter: Serg Jackbean
> Assignee: Cheng Fang
> Fix For: 9.0.0.Beta1
>
>
> Exception Class (own class that is saved as Serialisable in PersistentUserData) not Found (in JBeret?) disappears in some in some minutes after some calls of EJB with Batch Jobs according some sequence after new start of server.
> (there was exception -class not found for own class for checkpointInfo also)
> Log:
> 09:55:22,252 ERROR [org.jboss.as.ejb3.invocation] (default task-3) JBAS014134: EJB Invocation failed on component BatchRuntimeService for method public test.Job test.BatchRuntimeService.getJobStepExecutions(java.lang.String,int) throws test.ServiceException: javax.ejb.EJBException: javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at test.BatchRuntimeService$$$view4.getJobStepExecutions(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at test.BatchRuntimeService$Proxy$_$$_Weld$EnterpriseProxy$.getJobStepExecutions(Unknown Source) [classes:]
> at test.web.rest.JobTimerResource.listJobExecutions(JobTimerResource.java:122) [classes:]
> at test.web.rest.JobTimerResource$Proxy$_$$_WeldClientProxy.listJobExecutions(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.10.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.10.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
> at org.jberet.repository.JdbcRepository.selectStepExecutions(JdbcRepository.java:651) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.getStepExecutions(JdbcRepository.java:256) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.getStepExecutions(JobOperatorImpl.java:263) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at test.BatchRuntimeService.getJobStepExecutions(BatchRuntimeService.java:153) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.NonPooledEJBComponentInstanceAssociatingInterceptor.processInvocation(NonPooledEJBComponentInstanceAssociatingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
> ... 85 more
> Caused by: java.lang.ClassNotFoundException: test.JobBatchResult from [Module "org.jberet.jberet-core:main" from local module loader @675dd521 (finder: local module finder @41539e8b (roots: C:\server\wildfly-8.2.0.Final\modules,C:\server\wildfly-8.2.0.Final\modules\system\layers\base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_45]
> at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:625) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) [rt.jar:1.7.0_45]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_45]
> at org.jberet.util.BatchUtil.bytesToSerializableObject(BatchUtil.java:111) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.createStepExecutionsFromResultSet(JdbcRepository.java:746) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.selectStepExecutions(JdbcRepository.java:649) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 123 more
> 09:55:22,265 ERROR [test.web.rest.ExceptionHttpStatusResolver] (default task-3) javax.batch.operations.BatchRuntimeException: JBERET000626: Failed to run SELECT * FROM STEP_EXECUTION WHERE JOBEXECUTIONID=? ORDER BY STEPEXECUTIONID
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (DROOLS-707) NullPointer when changing order of the rules
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-707?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-707:
------------------------------------
The DRLs in your last test cases are now correctly recognized as invalid (due to the duplicate declarations) as a side effect of the implementation of this new feature https://issues.jboss.org/browse/DROOLS-727
> NullPointer when changing order of the rules
> --------------------------------------------
>
> Key: DROOLS-707
> URL: https://issues.jboss.org/browse/DROOLS-707
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
> Reporter: Francesco Peloi
> Assignee: Mario Fusco
> Fix For: 6.2.0.Final
>
>
> Hi there,
> we are having some serious issues with some rules, they are throwing a NullPointerException and we don't understand why. I have tried to narrow down the problem to the smallest rule possible, now this rule doesn't really make much sense put like this but the real rule is more complex with more constraints. At the end the result is the same: a NPE.
> I have tried it with many Drools versions from 5.x to latest 6.3.0-SNAPSHOT.
> I tested this in isolation with the minimum amount of code possible, and attached it as well if someone wants to try it quickly.
> Note that if line 2 of the when:
> $a : Integer()
> is moved as first line, the rule runs ok.
> Please find the reproducer here: https://groups.google.com/forum/#!topic/drools-usage/-oNqu3l4cqE
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFLY-4386) EJB annotations ignored if classes are packaged as JBOSS modules
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFLY-4386?page=com.atlassian.jira.plugin.... ]
Jan Martiska commented on WFLY-4386:
------------------------------------
You need to include an annotation index in the module's jar (http://javahowto.blogspot.cz/2012/08/how-to-run-jboss-jandex.html) AND explicitly specify in the application's MANIFEST.MF that it should import the annotations, like this
{noformat}
Dependencies: your.module.name annotations, other.module.name
{noformat}
Otherwise the application won't see them.
> EJB annotations ignored if classes are packaged as JBOSS modules
> ----------------------------------------------------------------
>
> Key: WFLY-4386
> URL: https://issues.jboss.org/browse/WFLY-4386
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, EJB
> Affects Versions: JBoss AS7 7.1.1.Final
> Reporter: Tihomir Meščić
> Assignee: David Lloyd
>
> I have an EJB that writes something to the DB and I have a custom checked exception that is marked as @javax.ejb.ApplicationException(rollback=true), which means that when the exception is thrown, transaction should be rollbacked.
> {code:title=Test.java.java|borderStyle=solid}
> @ApplicationException(rollback=true)
> public class MyException extends Exception {
> {code}
>
> This exception is packaged in a separate JAR.
>
> When this JAR is included in the lib/ folder of the EAR with my EJB, everything works as expected (when the EJB throws MyException, the transaction is rollbacked).
> However, when this JAR is deployed as a JBOSS module (so, in jboss_folder/modules/... folder), and the EAR declares a dependency on this module (MANIFEST.MF -> Dependencies: ....) , then the transaction is NOT rollbacked. So the EJB container ignores the annotation.
>
> One workaround (that I don't really like) is to specify that this is an application exception in the jboss-ejb3.xml (then, the transaction will be rollbacked).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFCORE-230) Failure by ProcessController to launch a server vm is not logged
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-230?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-230:
-----------------------------------------
The HC should log it. The server cannot, because the problem is that the start of the server process failed.
> Failure by ProcessController to launch a server vm is not logged
> ----------------------------------------------------------------
>
> Key: WFCORE-230
> URL: https://issues.jboss.org/browse/WFCORE-230
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha11
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.CR1
>
>
> In a domain configuration, if a server is associated with an incorrectly configurated jvm java-home (e.g. domain.xml -> server-groups -> jvm), it will fail silently (no error shown in logs). For example:
> ```
> <server-group name="mySrvrGrp" profile="full">
> <jvm name="my-default" java-home="/usr/java/wrongPath">
> <heap size="1024m" max-size="4096m"/>
> <permgen size="256m" max-size="256m"/>
> <stack size="256k"/>
> ```
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1907?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1907:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1187193|https://bugzilla.redhat.com/show_bug.cgi?id=1187193] from NEW to ASSIGNED
> ENCRYPT: asymmetric encryption fails on merge
> ---------------------------------------------
>
> Key: JGRP-1907
> URL: https://issues.jboss.org/browse/JGRP-1907
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.2
>
> Attachments: encrypt.xml, EncryptKeyStore.xml
>
>
> {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption.
> To reproduce:
> * Members A and B
> * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}}
> * Form cluster {{(A,B)}}
> * Create a network split: {{(A)}} and {{(B)}}
> * Remove the network split
> * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}}
> * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works.
> * Symmetric encryption: {{EncryptKeyStore.xml}}
> * Asymmetric encryption: {{encrypt.xml}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-4386) EJB annotations ignored if classes are packaged as JBOSS modules
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/WFLY-4386?page=com.atlassian.jira.plugin.... ]
Tihomir Meščić updated WFLY-4386:
---------------------------------
Description:
I have an EJB that writes something to the DB and I have a custom checked exception that is marked as @javax.ejb.ApplicationException(rollback=true), which means that when the exception is thrown, transaction should be rollbacked.
{code:title=Test.java.java|borderStyle=solid}
@ApplicationException(rollback=true)
public class MyException extends Exception {
{code}
This exception is packaged in a separate JAR.
When this JAR is included in the lib/ folder of the EAR with my EJB, everything works as expected (when the EJB throws MyException, the transaction is rollbacked).
However, when this JAR is deployed as a JBOSS module (so, in jboss_folder/modules/... folder), and the EAR declares a dependency on this module (MANIFEST.MF -> Dependencies: ....) , then the transaction is NOT rollbacked. So the EJB container ignores the annotation.
One workaround (that I don't really like) is to specify that this is an application exception in the jboss-ejb3.xml (then, the transaction will be rollbacked).
was:
I have an EJB that writes something to the DB and I have a custom checked exception that is marked as @javax.ejb.ApplicationException(rollback=true), which means that when the exception is thrown, transaction should be rollbacked.
{code:title=Test.java.java|borderStyle=solid}
@ApplicationException(rollback=true)
public class MyException extends Exception {
{code}
This exception is packaged in a separate JAR.
When this JAR is included in the lib/ folder of the EAR with my EJB, everything works as expected (when the EJB throws MyException, the transaction is rollbacked).
However, when this JAR is deployed as a JBOSS module (so, in ${jboss}/modules/... folder), and the EAR declares a dependency on this module (MANIFEST.MF -> Dependencies: ....) , then the transaction is NOT rollbacked. So the EJB container ignores the annotation.
One workaround (that I don't really like) is to specify that this is an application exception in the jboss-ejb3.xml (then, the transaction will be rollbacked).
> EJB annotations ignored if classes are packaged as JBOSS modules
> ----------------------------------------------------------------
>
> Key: WFLY-4386
> URL: https://issues.jboss.org/browse/WFLY-4386
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, EJB
> Affects Versions: JBoss AS7 7.1.1.Final
> Reporter: Tihomir Meščić
> Assignee: David Lloyd
>
> I have an EJB that writes something to the DB and I have a custom checked exception that is marked as @javax.ejb.ApplicationException(rollback=true), which means that when the exception is thrown, transaction should be rollbacked.
> {code:title=Test.java.java|borderStyle=solid}
> @ApplicationException(rollback=true)
> public class MyException extends Exception {
> {code}
>
> This exception is packaged in a separate JAR.
>
> When this JAR is included in the lib/ folder of the EAR with my EJB, everything works as expected (when the EJB throws MyException, the transaction is rollbacked).
> However, when this JAR is deployed as a JBOSS module (so, in jboss_folder/modules/... folder), and the EAR declares a dependency on this module (MANIFEST.MF -> Dependencies: ....) , then the transaction is NOT rollbacked. So the EJB container ignores the annotation.
>
> One workaround (that I don't really like) is to specify that this is an application exception in the jboss-ejb3.xml (then, the transaction will be rollbacked).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (WFLY-4386) EJB annotations ignored if classes are packaged as JBOSS modules
by Tihomir Meščić (JIRA)
Tihomir Meščić created WFLY-4386:
------------------------------------
Summary: EJB annotations ignored if classes are packaged as JBOSS modules
Key: WFLY-4386
URL: https://issues.jboss.org/browse/WFLY-4386
Project: WildFly
Issue Type: Bug
Components: Class Loading, EJB
Affects Versions: JBoss AS7 7.1.1.Final
Reporter: Tihomir Meščić
Assignee: David Lloyd
I have an EJB that writes something to the DB and I have a custom checked exception that is marked as @javax.ejb.ApplicationException(rollback=true), which means that when the exception is thrown, transaction should be rollbacked.
{code:title=Test.java.java|borderStyle=solid}
@ApplicationException(rollback=true)
public class MyException extends Exception {
{code}
This exception is packaged in a separate JAR.
When this JAR is included in the lib/ folder of the EAR with my EJB, everything works as expected (when the EJB throws MyException, the transaction is rollbacked).
However, when this JAR is deployed as a JBOSS module (so, in ${jboss}/modules/... folder), and the EAR declares a dependency on this module (MANIFEST.MF -> Dependencies: ....) , then the transaction is NOT rollbacked. So the EJB container ignores the annotation.
One workaround (that I don't really like) is to specify that this is an application exception in the jboss-ejb3.xml (then, the transaction will be rollbacked).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months