October 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-2148) Adding a second connection def for an resource adapter fails

by Heiko Braun (Created) (JIRA)

Adding a second connection def for an resource adapter fails ------------------------------------------------------------ Key: AS7-2148 URL: https://issues.jboss.org/browse/AS7-2148 Project: Application Server 7 Issue Type: Bug Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.1.0.Beta1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
2
0 / 0

[JBoss JIRA] (JBMESSAGING-1897) SessionState's ackMap is not cleared in Auto ack mode and therefore cause mem leak

by Yong Hao Gao (Created) (JIRA)

SessionState's ackMap is not cleared in Auto ack mode and therefore cause mem leak ---------------------------------------------------------------------------------- Key: JBMESSAGING-1897 URL: https://issues.jboss.org/browse/JBMESSAGING-1897 Project: JBoss Messaging Issue Type: Bug Components: JMS Facade Affects Versions: 1.4.8.SP3, 1.4.0.SP3.CP14 Reporter: Yong Hao Gao Assignee: Yong Hao Gao Priority: Critical Fix For: 1.4.0.SP3.CP15, 1.4.8.SP4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
2
0 / 0

[JBoss JIRA] (JASSIST-145) erroneous "bad array type for AALOAD: null" when verifying

by Shigeru Chiba (Created) (JIRA)

erroneous "bad array type for AALOAD: null" when verifying ---------------------------------------------------------- Key: JASSIST-145 URL: https://issues.jboss.org/browse/JASSIST-145 Project: Javassist Issue Type: Bug Affects Versions: 3.15.0-GA Reporter: Shigeru Chiba Assignee: Shigeru Chiba (reported by Johannes Schindelin) When verifying bytecode compiled for Java 1.6+ where we need to provide a StackMapTable attribute which we verify ourselves first, the sequence ACONST_NULL ASTORE_0 ... ALOAD_0 ICONST_0 AALOAD triggers the verifier to add NullType as an equivalent type for the ArrayType. Since that code might be unreachable after instrumenting or the local variable might have been set otherwise before jumping back to this code, we really need ArrayType's isNullType() method to report the correct result. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
2
0 / 0

[JBoss JIRA] (AS7-2120) WAR deployments fail if EE subsystem removed

by Tristan Tarrant (Created) (JIRA)

WAR deployments fail if EE subsystem removed -------------------------------------------- Key: AS7-2120 URL: https://issues.jboss.org/browse/AS7-2120 Project: Application Server 7 Issue Type: Bug Components: Web Affects Versions: 7.1.0.Alpha1, 7.0.2.Final Reporter: Tristan Tarrant Assignee: Stuart Douglas Priority: Minor If the org.jboss.as.ee extension is removed from the configuration, the deployment of WAR files doesn't work anymore. The following exception is thrown: {code} 14:49:53,938 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.web.deployment.default-host./datagrid: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./datagrid: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_23] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_23] at java.lang.Thread.run(Thread.java:679) [:1.6.0_23] Caused by: java.lang.NullPointerException at java.util.ArrayDeque.addFirst(ArrayDeque.java:226) [:1.6.0_23] at java.util.ArrayDeque.push(ArrayDeque.java:493) [:1.6.0_23] at org.jboss.as.naming.util.ThreadLocalStack.push(ThreadLocalStack.java:43) at org.jboss.as.naming.context.NamespaceContextSelector.pushCurrentSelector(NamespaceContextSelector.java:48) at org.jboss.as.web.NamingValve.beginComponentStart(NamingValve.java:65) at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:62) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] ... 3 more {code} Looking at the code, it seems like the NamespaceContextSelector should be injected only if there is a moduleDescription. Unfortunately if it isn't (like in my case), it fails. If the moduleDescription should never be null, then a better exception should be thrown, otherwise the code shouldn't break. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
1
0 / 0

[JBoss JIRA] (JBMESSAGING-1899) MessagingPostOffice's inactiveConditions field is not thread safe

by Yong Hao Gao (Created) (JIRA)

MessagingPostOffice's inactiveConditions field is not thread safe ----------------------------------------------------------------- Key: JBMESSAGING-1899 URL: https://issues.jboss.org/browse/JBMESSAGING-1899 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.8.SP3, 1.4.0.SP3.CP14 Reporter: Yong Hao Gao Assignee: Yong Hao Gao Fix For: 1.4.0.SP3.CP15, 1.4.8.SP4 Need to protect against concurrent modification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
2
0 / 0

[JBoss JIRA] (JBMESSAGING-1898) MessageProxy's log member should be static

by Yong Hao Gao (Created) (JIRA)

MessageProxy's log member should be static ------------------------------------------ Key: JBMESSAGING-1898 URL: https://issues.jboss.org/browse/JBMESSAGING-1898 Project: JBoss Messaging Issue Type: Bug Components: JMS Facade Affects Versions: 1.4.8.SP3, 1.4.0.SP3.CP14 Reporter: Yong Hao Gao Assignee: Yong Hao Gao Fix For: 1.4.0.SP3.CP15, 1.4.8.SP4 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
2
0 / 0

[JBoss JIRA] (AS7-2034) Asynchronous EJB thread pool maximum size is set to "Runtime.getRuntime().availableProcessors()"

by Stian Thorgersen (Created) (JIRA)

Asynchronous EJB thread pool maximum size is set to "Runtime.getRuntime().availableProcessors()" ------------------------------------------------------------------------------------------------ Key: AS7-2034 URL: https://issues.jboss.org/browse/AS7-2034 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.2.Final Reporter: Stian Thorgersen Attachments: agility-async_test.jar, AsyncBean.java, InvokerBean.java The thread pool service used to execute @Asynchronous EJB methods have been set to "Runtime.getRuntime().availableProcessors()". This is clearly not a sensible default as on a single core CPU (or VM) only a single @Asynchronous method is executed concurrently. I would imagine a sensible default would be at least 10. It would also be very useful if it was possible set this value in the configuration files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

5
6
0 / 0

[JBoss JIRA] Created: (JBRULES-3211) Rules fires on incorrect condition

by Tommy Odom (JIRA)

Rules fires on incorrect condition ---------------------------------- Key: JBRULES-3211 URL: https://issues.jboss.org/browse/JBRULES-3211 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.2.0.Final Reporter: Tommy Odom Assignee: Mark Proctor We are running into some issues after upgrading to Drools 5.2.0 from Drools 5.1.1. Our rules are no longer executing correctly. The wrong rule fires due to the constraints of a previous rule. I wrote a standalone test that replicates the problem and I've tested with 5.3.0-SNAPSHOT and the tests fail there as well. Forgive me if what I state is incorrect but I figured I'd try to relay some of what I observed in debugging. It appears that the difference between 5.1.1 and 5.2.0 comes from the handling of the constraints. In 5.1.1, the constraints were created as PredicateConstraints but in 5.2.0 they are being created as LiteralConstraints. As such, in 5.1.1 in the CompositeObjectSinkAdapter adds the new sinks as otherSinks but in 5.2.0 they are registered as FieldIndexes. However, the index value on all of the MVELClassFieldReader instances is 0 so both "engine.engineType.id" and "engine.id" are mapped to the same FieldIndex. I haven't had time yet to dig into the code to understand the difference between a PredicateConstraint and a LiteralConstraint so I'm not sure if there's something I could be doing differently to avoid this problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
3
0 / 0

[JBoss JIRA] (JBMESSAGING-1896) MessagingClusterHealthMBean may block when stopping a node

by Yong Hao Gao (Created) (JIRA)

MessagingClusterHealthMBean may block when stopping a node ---------------------------------------------------------- Key: JBMESSAGING-1896 URL: https://issues.jboss.org/browse/JBMESSAGING-1896 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.8.SP3, 1.4.0.SP3.CP14 Reporter: Yong Hao Gao Assignee: Yong Hao Gao Fix For: 1.4.0.SP3.CP15, 1.4.8.SP4 When a node is shunned from the node but at the same time its DB is also disconnected, the MessagingClusterHealthMBean will shut down the node in the jgroups thread. Because the shutdown happens in the process of view change, it will block on the MessagingPostOffice.stopViewUpdate() method. I will wait for the flag updateInProcess forever because it will never get a chance to update the flag. See the stack trace: "Incoming-10,192.168.1.110:55200" prio=10 tid=0x00007f619c036800 nid=0x4b2e in Object.wait() [0x00007f618a24a000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000d94c55d8> (a java.lang.Object) at java.lang.Object.wait(Object.java:502) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.stopViewUpdate(MessagingPostOffice.java:852) - locked <0x00000000d94c55d8> (a java.lang.Object) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.stop(MessagingPostOffice.java:796) at org.jboss.messaging.core.jmx.MessagingPostOfficeService.stopService(MessagingPostOfficeService.java:554) at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:405) at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:281) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.jms.server.MessagingClusterHealthMBean.stopService(MessagingClusterHealthMBean.java:140) at org.jboss.jms.server.MessagingClusterHealthMBean.stopNodeOnDBFailure(MessagingClusterHealthMBean.java:107) - locked <0x00000000d731a520> (a org.jboss.jms.server.MessagingClusterHealthMBean) at org.jboss.jms.server.ServerPeer.stopJBMNodeForRecovery(ServerPeer.java:2115) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1748) at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1568) at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:733) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776) at org.jgroups.JChannel.up(JChannel.java:1336) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:439) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:153) at org.jgroups.protocols.FRAG2.up(FRAG2.java:188) at org.jgroups.protocols.FC.up(FC.java:493) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:543) - locked <0x00000000d94b2c90> (a org.jgroups.Membership) at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:463) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:749) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) at org.jgroups.protocols.UNICAST.up(UNICAST.java:328) at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708) at org.jgroups.protocols.BARRIER.up(BARRIER.java:136) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) at org.jgroups.protocols.FD.up(FD.java:284) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:328) at org.jgroups.protocols.MERGE2.up(MERGE2.java:144) at org.jgroups.protocols.Discovery.up(Discovery.java:264) at org.jgroups.protocols.PING.up(PING.java:273) at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2319) at org.jgroups.protocols.TP.passMessageUp(TP.java:1253) at org.jgroups.protocols.TP.access$100(TP.java:50) at org.jgroups.protocols.TP$1.run(TP.java:1177) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

5
4
0 / 0

[JBoss JIRA] (JBCL-180) Classcast Exception while deploying an ear file in jboss 5.1.0

by suresh kumar (Created) (JIRA)

Classcast Exception while deploying an ear file in jboss 5.1.0 -------------------------------------------------------------- Key: JBCL-180 URL: https://issues.jboss.org/browse/JBCL-180 Project: JBoss ClassLoader Issue Type: Bug Components: ClassLoader, MetaData Reporter: suresh kumar Assignee: Ales Justin Priority: Blocker When we tried to migrate our application from jboss-3.2.7 to jboss-5.1.0, we faced this issue.Basically in our application, we have an EAR file packaged with couple of WAR files and a SAR file along with META-INF directory. While deploying the EAR file under server\default\deploy directory, we are getting the below error.Our application do not useany EJB related stuffs. Basically,this error is thrown when we have an SAR file and WAR files packaged together in an EAR file. Caused by: java.lang.ClassCastException: org.jboss.metadata.ear.jboss.ServiceModuleMetaData cannot be cast to org.jboss.metadata.ear.spec.WebModuleMetaData at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:327) at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:97) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(Abstra ctSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer .java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) ... 30 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2011