[JBoss JIRA] Created: (AS7-1059) mod_cluster throws warnings at shutdown
by Jean-Frederic Clere (JIRA)
mod_cluster throws warnings at shutdown
---------------------------------------
Key: AS7-1059
URL: https://issues.jboss.org/browse/AS7-1059
Project: Application Server 7
Issue Type: Bug
Reporter: Jean-Frederic Clere
Assignee: Jean-Frederic Clere
Priority: Minor
At shutdown you get an warning:
+++
21:37:37,537 WARN [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (MSC service thread 1-1) Failed to interrupt socket reception: java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method) [:1.6.0_22]
at java.net.DatagramSocket.send(DatagramSocket.java:629) [:1.6.0_22]
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.interruptDatagramReader(AdvertiseListenerImpl.java:240)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.stop(AdvertiseListenerImpl.java:262)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.destroy(AdvertiseListenerImpl.java:278)
at org.jboss.modcluster.ModClusterService.shutdown(ModClusterService.java:214)
at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.destroy(CatalinaEventHandlerAdapter.java:374)
at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.stop(CatalinaEventHandlerAdapter.java:144)
at org.jboss.as.modcluster.ModClusterService.stop(ModClusterService.java:236)
at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1819)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2302)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]
+++
In fact that should be a debug... And the fix should go in mod_cluster. See MODCLUSTER-243
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBAS-9445) JAXRS-EJB3-CDI bean injection failure (classloading issue?)
by Florian Beaufume (JIRA)
JAXRS-EJB3-CDI bean injection failure (classloading issue?)
-----------------------------------------------------------
Key: JBAS-9445
URL: https://issues.jboss.org/browse/JBAS-9445
Project: Legacy JBoss Application Server 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB, Web Services, Weld/CDI
Affects Versions: 6.1.0, 6.0.0.Final
Environment: Windows XP, JDK 1.6.0_u24.
Reporter: Florian Beaufume
Assignee: Carlo de Wolf
Summary :
- In a JAX-RS resource implemented as a stateless session EJB, a CDI injection fails when the several applications are deployed.
- Both JBoss 6.0.0.Final and 6.1.0.Final fail, but with different results.
Description:
- We have two webapps, "mockup1.war" and "mockup2.war".
- Each webapp contains the same "SampleResource" JAX-RS resource class implemented as a stateless session EJB ("@Stateless").
- Each webapp contains the same "ApplicationResources" JAX-RS application resource class that registers "SampleResource".
- Each webapp contains the same "ServiceInterface" business interface.
- Each webapp contains its own implementation of the business service : "ServiceBean1" for "mockup1.war" and "ServiceBean2" for "mockup2.war".
- That implementation is used by the resource class, and only logs a text message to stdout.
Test scenario with JBoss 6.0.0.Final :
- (1) Deploy both war to JBoss 6.0.0.Final => no deployment problem.
- (2) Go to http://localhost:8080/mockup2/resource/, consult the app server logs, you see the "Hello from mockup2.war" line => that's ok.
- (3) Go to http://localhost:8080/mockup1/resource/, consult the app server logs, you see the "Hello from mockup2.war" line instead of "Hello from mockup1.war" => bug!
What happened with JBoss 6.0.0.Final :
- When the resource class is executed from "mockup2.war", the business service implementation is loaded from "mockup1.war" instead of "mockup2.war"!
- When the resource class is executed from "mockup1.war", no problem.
Other information for JBoss 6.0.0.Final :
- I tracked the issue using a debugger.
- If I use a servlet filter I can see that the filter classloader always correctly refers to the current web app, that's ok.
- But inside the JAX-RS resource class I can see that the resource class loader always point to "mockup2.war". This may explain why the wrong bean gets injected.
- If the JAX-Rs resource class is @ManagedBean instead of @Stateless, there is no bug.
Test scenario with JBoss 6.1.0.Final :
- Same (1) and (2) => eveything is ok.
- (3) go to the URL => server failure, you get a stack trace :
2011-09-05 16:26:25,421 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/mockup1].[default]] (http-127.0.0.1-8080-1) "Servlet.service()" pour la servlet default a généré une exception: org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalArgumentException: object is not an instance of declaring class
at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [:6.1.0.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [:6.1.0.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [:6.1.0.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [:6.1.0.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [:6.1.0.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [:6.1.0.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:155) [:6.1.0.Final]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:212) [:6.1.0.Final]
at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:59) [:6.1.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.1.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.1.0.Final]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [:6.1.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.1.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.1.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.1.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [:6.1.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.1.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.1.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:159) [:6.1.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.1.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.1.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.1.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.1.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.1.0.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.1.0.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.1.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.1.0.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) [:6.1.0.Final]
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [:6.1.0.Final]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) [:6.1.0.Final]
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) [:6.1.0.Final]
at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:125) [:6.1.0.Final]
at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62) [:6.1.0.Final]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125) [:6.1.0.Final]
at com.beaufume.mockup.SampleResource$Proxy$_$$_Weld$Proxy$.getContent(SampleResource$Proxy$_$$_Weld$Proxy$.java) [:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [:6.1.0.Final]
at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [:6.1.0.Final]
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [:6.1.0.Final]
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [:6.1.0.Final]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [:6.1.0.Final]
... 26 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (AS7-1490) ClassNotFoundException during session replication
by Jozef Hartinger (JIRA)
ClassNotFoundException during session replication
-------------------------------------------------
Key: AS7-1490
URL: https://issues.jboss.org/browse/AS7-1490
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Environment: Latest AS7 snapshot (2011-08-09)
Reporter: Jozef Hartinger
Assignee: Paul Ferraro
Priority: Critical
Attachments: weld-translator.ear
I tested the weld translator ear with two standalone as7 instances with standalone-ha configuration and replication still does not work. I can see the following message in the server log:
{noformat}
10:19:06,933 WARN [org.jboss.as.clustering.web.infinispan.DistributedCacheManager] (http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]: java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
10:19:06,933 DEBUG [org.jboss.as.clustering.web.infinispan.DistributedCacheManager] (http--127.0.0.1-8180-1) Problem accessing session [nQ****V2mfaX]: java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX: java.lang.RuntimeException: Failed to load session attributes for session: nQ****V2mfaX
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getRuntimeException(DistributedCacheManager.java:82)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:285)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:268)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:67)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getData(DistributedCacheManager.java:294)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionData(DistributedCacheManager.java:250)
at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1410) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:701) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:68) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:60) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:36) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:17) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:154) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.ClassNotFoundException: ss.weld.examples.translator.SentenceParsernslator from [Module "deployment.weld-translator.ear.weld-translator.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
at java.lang.Class.forName0(Native Method) [:1.6.0_24]
at java.lang.Class.forName(Class.java:247) [:1.6.0_24]
at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:868)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:898)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1310)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1673)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1589)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1231)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadMapObject(RiverUnmarshaller.java:195)
at org.jboss.marshalling.river.RiverUnmarshaller.readMapData(RiverUnmarshaller.java:791)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:682)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.jboss.as.clustering.SimpleMarshalledValue.get(SimpleMarshalledValue.java:84)
at org.jboss.as.clustering.web.impl.SessionAttributeMarshallerImpl.unmarshal(SessionAttributeMarshallerImpl.java:70)
at org.jboss.as.clustering.web.infinispan.CoarseSessionAttributeStorage.load(CoarseSessionAttributeStorage.java:65)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$3.invoke(DistributedCacheManager.java:283)
... 23 more
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (AS7-1718) CLONE - mod_cluster needs consistent naming
by Radoslav Husar (JIRA)
CLONE - mod_cluster needs consistent naming
-------------------------------------------
Key: AS7-1718
URL: https://issues.jboss.org/browse/AS7-1718
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.0.0.Final, 7.0.1.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Critical
We have been running into issues with misspelt modcluster, mod_cluster and mod-cluster (and Mod-cluster) for quite some time now, making difficult time for users. Surely there are sometimes rules where we can't stick to proper naming but we should then be able to minimize to two names.
*project name = mod_cluster
*console name = "Mod_cluster Status"
*xsd schema filename = mod-cluster (./docs/schema/jboss-as-mod-cluster_1_0.xsd)
*xmlns = modcluster (eg xmlns="urn:jboss:domain:modcluster:1.0")
*xs elements = mod-cluster (eg mod-cluster-config)
*schema comments = mod_cluster (eg <!-- mod_cluster parameters ...)
*jar name = mod_cluster (ie mod_cluster-1.1.3.Final)
I am not going to name the EAP5 components where names are significantly changed too.
We need this madness to stop soon enough ;-(
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBMESSAGING-1891) Null point exception while committing a transaction
by Tom Ross (JIRA)
Null point exception while committing a transaction
---------------------------------------------------
Key: JBMESSAGING-1891
URL: https://issues.jboss.org/browse/JBMESSAGING-1891
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP1
Environment: JBoss EAP 5.1.1
Reporter: Tom Ross
Assignee: Yong Hao Gao
The following exception gets throw when committing a transaction:
12:02:53,098 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] XAResourceRecord.topLevelCommit caught: java.lang.NullPointerException
java.lang.NullPointerException
at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:375)
at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:255)
at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.commit(MessagingXAResourceWrapper.java:126)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:568)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3155)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3070)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2131)
at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:85)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:181)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:294)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:128)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBRULES-3201) Sliding windows - Rule is being fired event when LHS is false
by eyal rahamim (JIRA)
Sliding windows - Rule is being fired event when LHS is false
-------------------------------------------------------------
Key: JBRULES-3201
URL: https://issues.jboss.org/browse/JBRULES-3201
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.3.0.Beta1
Environment: Linux
Reporter: eyal rahamim
Assignee: Mark Proctor
I have a rule that accumulate fact into sliding window. When the count get to a certain threshold the rule should be activated. After the window time is over, I expect that the rule will not fired anymore. The counter of the fact is report as 0, but still the rule is being executed.
drl :
package com.sample;
import com.sample.WindowLength.FactTest;
declare FactTest
@role( event )
end
rule "A500 : test"
when
// count devices per tag id
$counter : Number( intValue >= 2 ) from accumulate (
$d : FactTest() over window:time(1m), count($d))
then
System.out.println("A500: Rule is fired, count = " + $counter + " *********");
end
scenario:
ksession.insert(new FactTest());
ksession.fireAllRules();
ksession.insert(new FactTest());
ksession.fireAllRules();
ksession.insert(new FactTest());
ksession.fireAllRules();
SessionPseudoClock clock = ksession.getSessionClock();
clock.advanceTime(1, TimeUnit.MINUTES );
ksession.fireAllRules();
Result:
A500: Rule is fired, count = 2 *********
A500: Rule is fired, count = 3 *********
A500: Rule is fired, count = 0 *********
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (JBMESSAGING-1462) Message expiration is not correctly managed
by Ivan (JIRA)
Message expiration is not correctly managed
-------------------------------------------
Key: JBMESSAGING-1462
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1462
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.1.GA
Environment: JBAS 5.0GA, JBM 1.4.1GA, persistence on Oracle 10i
Reporter: Ivan
Assignee: Tim Fox
1) A topic is created
2) A durable subscriber is created fro the topic
3) A message is sent on the topic
4) The durable subscriber pulls the message from the topic ( receive() ) but don't ack
5) The durable subscriber is closed, subscriber session.unsuscribe(name) is called but an exception is thrown and then the subsciber session is closed.
As result of this a message, expired, with DELIVERY_COUNT = 1 will remain on the database forever.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (AS7-1046) AS7 gives NPE when jboss-web.xml is missing from WAR
by Nathan Kopp (JIRA)
AS7 gives NPE when jboss-web.xml is missing from WAR
----------------------------------------------------
Key: AS7-1046
URL: https://issues.jboss.org/browse/AS7-1046
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: Open To Community
Environment: Windows XP, JDK 1.6
Reporter: Nathan Kopp
Attachments: jaxws-test.war
I'm trying to deploy a simple WAR (nearly empty, with a single JAX-WS web service) using a fairly recent snapshot of JBoss AS7. If I do not include jboss-web.xml in the WEB-INF folder, I get the following NPE when deploying to standalone\deployment
12:17:25,356 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."jaxws-test.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-test.war".INSTALL: Failed to process phase INSTALL of deployment "jaxws-test.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_10]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_10]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_10]
Caused by: java.lang.NullPointerException
at org.jboss.as.webservices.util.WebMetaDataHelper.getServlets(WebMetaDataHelper.java:130)
at org.jboss.as.webservices.tomcat.WebMetaDataCreator.createServlets(WebMetaDataCreator.java:173)
at org.jboss.as.webservices.tomcat.WebMetaDataCreator.createWebAppDescriptor(WebMetaDataCreator.java:109)
at org.jboss.as.webservices.tomcat.WebMetaDataCreator.create(WebMetaDataCreator.java:93)
at org.jboss.as.webservices.tomcat.WebMetaDataCreatingDeploymentAspect.start(WebMetaDataCreatingDeploymentAspect.java:48)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.internalDeploy(AspectDeploymentProcessor.java:78)
at org.jboss.as.webservices.deployers.TCCLDeploymentProcessor.deploy(TCCLDeploymentProcessor.java:42)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
... 4 more
When I add a very simple jboss-web.xml file (containing only the context-root tag), the deployment succeeds.
Attached is the WAR file.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (AS7-1216) NonexistentConversationException when attempting to restore a long-running conversation on AS 7 CR1 and not beta3
by Drew Stockdreher (JIRA)
NonexistentConversationException when attempting to restore a long-running conversation on AS 7 CR1 and not beta3
-----------------------------------------------------------------------------------------------------------------
Key: AS7-1216
URL: https://issues.jboss.org/browse/AS7-1216
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 7.0.0.CR1
Environment: Windows XP 32 bit, JBoss AS 7 CR1 and Firefox 5
Reporter: Drew Stockdreher
A simple web application which starts a long-running conversation via an
<f:event type="preRenderView" listener="#{bean.startConvo}"/> tag.
Selecting from a selectOneMenuList makes an ajax request which was working on the beta3 release of AS 7 is no longer working with the following stacktrace. This does however still work in IE 7 and Chrome 12 on both beta3 and CR1 releases.
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) org.jboss.weld.context.NonexistentConversationException: WELD-000321 No conversation found to restore for id 1
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1) at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1) at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1) at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1) at java.lang.Thread.run(Thread.java:662)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months