February 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-320) ConnectionTable/ConnectionTableNIO have leftover threads after stop()

by Bela Ban (JIRA)

ConnectionTable/ConnectionTableNIO have leftover threads after stop() --------------------------------------------------------------------- Key: JGRP-320 URL: http://jira.jboss.com/jira/browse/JGRP-320 Project: JGroups Issue Type: Bug Affects Versions: 2.3 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 Unit test ConnectionTableTest shows this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-8751) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored

by Nicklas Karlsson (JIRA)

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored ----------------------------------------------------------------------- Key: JBAS-8751 URL: https://issues.jboss.org/browse/JBAS-8751 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Affects Versions: 6.0.0.CR1 Reporter: Nicklas Karlsson Assignee: Stan Silvert Given a model like @javax.enterprise.inject.Model public class Model { private String data; public String getData() { return data; } public void setData(String data) { System.out.println("set data to " + data); this.data = data; } } and a view like <h:form> <h:inputText id="field" value="#{model.data}"/> <h:commandButton value="!"/> </h:form> an empty value is submitted even with <context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param> Debugging the application shows that the emptyStringIsNull of the component is true. even with a @FacesConverter(forClass=String.class) which is correctly run and doing a setSubmittedValue(null), the model still sees a "" instead of a null Tested to work correctly on a GF 3.0.1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
3
0 / 0

[JBoss JIRA] (AS7-3919) HornetQ causing deadlock when max-size-bytes reaches its limit

by Ove Ranheim (JIRA)

Ove Ranheim created AS7-3919: -------------------------------- Summary: HornetQ causing deadlock when max-size-bytes reaches its limit Key: AS7-3919 URL: https://issues.jboss.org/browse/AS7-3919 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.0.Final Reporter: Ove Ranheim Assignee: Andy Taylor Priority: Critical Fix For: 7.1.1.Final I have journal-file-size set to 10 Mb and max-size-bytes set 10 Mb, with a address policy of BLOCK. When my sendMailQueue reaches its limit a deadlock occurs. This is further emphasized in the JBossAS Forum reference. Here's a snippet from jstack after HornetQ crashes. {noformat} Found one Java-level deadlock: ============================= "Thread-878 (HornetQ-client-global-threads-1151364488)": waiting to lock monitor 0x0000000041df8640 (object 0x00000000ea17d6e0, a java.lang.Object), which is held by "Thread-873 (HornetQ-client-global-threads-1151364488)" "Thread-873 (HornetQ-client-global-threads-1151364488)": waiting to lock monitor 0x000000004107c8b8 (object 0x00000000ea17d6d0, a java.lang.Object), which is held by "Thread-878 (HornetQ-client-global-threads-1151364488)" Java stack information for the threads listed above: =================================================== "Thread-878 (HornetQ-client-global-threads-1151364488)": at org.hornetq.core.client.impl.ClientSessionFactoryImpl.close(ClientSessionFactoryImpl.java:461) - waiting to lock <0x00000000ea17d6e0> (a java.lang.Object) - locked <0x00000000ea17d6d0> (a java.lang.Object) at org.hornetq.core.client.impl.ServerLocatorImpl.doClose(ServerLocatorImpl.java:1294) at org.hornetq.core.client.impl.ServerLocatorImpl.close(ServerLocatorImpl.java:1238) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.close(HornetQXAResourceWrapper.java:392) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connectionFailed(HornetQXAResourceWrapper.java:232) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.callFailureListeners(ClientSessionFactoryImpl.java:905) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:690) - locked <0x00000000f0222060> (a java.lang.Object) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:556) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.access$000(ClientSessionFactoryImpl.java:79) at org.hornetq.core.client.impl.ClientSessionFactoryImpl$1.run(ClientSessionFactoryImpl.java:386) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) "Thread-873 (HornetQ-client-global-threads-1151364488)": at org.hornetq.core.client.impl.ClientSessionFactoryImpl.close(ClientSessionFactoryImpl.java:458) - waiting to lock <0x00000000ea17d6d0> (a java.lang.Object) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.close(HornetQXAResourceWrapper.java:391) at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connectionFailed(HornetQXAResourceWrapper.java:232) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.callFailureListeners(ClientSessionFactoryImpl.java:905) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:690) - locked <0x00000000ea17d6e0> (a java.lang.Object) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:556) at org.hornetq.core.client.impl.ClientSessionFactoryImpl.access$000(ClientSessionFactoryImpl.java:79) at org.hornetq.core.client.impl.ClientSessionFactoryImpl$1.run(ClientSessionFactoryImpl.java:386) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Found 1 deadlock. {noformat} -- 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

13 years, 8 months

5
18
0 / 0

[JBoss JIRA] Created: (JBRULES-2213) When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on

by Geoffrey De Smet (JIRA)

When the decider doesn't pick a move, the DefaultLocalSearchSolver shouldn't terminate by exception by try again, especially with relativeSelection on ------------------------------------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-2213 URL: https://jira.jboss.org/jira/browse/JBRULES-2213 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-solver Affects Versions: 5.0.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Critical a random bad relativeSelection could select only moves that are tabu that no reason to stop, because the next relativeSelection could be great. -- 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

13 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-3033) java.lang.ClassCastException when change rule condition and declarative facts/events are used

by Federico Weisse (JIRA)

java.lang.ClassCastException when change rule condition and declarative facts/events are used --------------------------------------------------------------------------------------------- Key: JBRULES-3033 URL: https://issues.jboss.org/browse/JBRULES-3033 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Reporter: Federico Weisse Assignee: Mark Proctor We have drl files where we declare events. we use declarative events (there is no java class AlertaPosManual) (like this) declare AlertaPosManual @role (event) @expires(10s) idTerminal : java.lang.String end We use a StatefullSession for fusion cep and we need that changes in rules refresh the kBase in runtime. But when a rule condition changes this exception in throw Exception in thread "Thread-2" java.lang.ClassCastException: com.sample.ConsumoPostManual cannot be cast to com.sample.ConsumoPostManual at org.drools.base.com.sample.ConsumoPostManual17710704$getIdTerminal.getValue(Unknown Source) at org.drools.base.extractors.BaseObjectClassFieldReader.getHashCode(BaseObjectClassFieldReader.java:192) at org.drools.base.ClassFieldReader.getHashCode(ClassFieldReader.java:193) at org.drools.core.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:582) at org.drools.core.util.RightTupleIndexHashTable.getOrCreate(RightTupleIndexHashTable.java:360) at org.drools.core.util.RightTupleIndexHashTable.add(RightTupleIndexHashTable.java:243) at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:246) at org.drools.reteoo.ObjectTypeNode.updateSink(ObjectTypeNode.java:276) at org.drools.reteoo.PropagationQueuingNode.updateSink(PropagationQueuingNode.java:111) at org.drools.reteoo.BetaNode.attach(BetaNode.java:214) at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:151) at org.drools.reteoo.builder.CollectBuilder.build(CollectBuilder.java:114) at org.drools.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:111) at org.drools.reteoo.builder.PatternBuilder.build(PatternBuilder.java:72) at org.drools.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:132) at org.drools.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:78) at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:155) at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:128) at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:117) at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:428) at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:721) at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:545) at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:445) at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:452) at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:937) at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:821) at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:586) at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185) at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1106) at java.lang.Thread.run(Thread.java:619) I think that's because the statefullSession has an instance of com.sample.ConsumoPostManual (loaded with the classLoader org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1218b25) But when the kBase is regenerated and the class com.sample.ConsumoPostManual to, the classLoader org.drools.rule.JavaDialectRuntimeData is recreated so there are two versions of the class com.sample.ConsumoPostManual in differents classLoader (one in the statefullSession and the other in the kBase) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2962) Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts

by Ross Hall (JIRA)

Knowledge Agent rebuilding KnowledgeBase with scanner/notifier does not work with declared facts ------------------------------------------------------------------------------------------------ Key: JBRULES-2962 URL: https://issues.jboss.org/browse/JBRULES-2962 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M1, 5.1.1.FINAL Reporter: Ross Hall Assignee: Mark Proctor When reloading rules in a KnowledgeAgent declared facts will cause ClassCastExceptions when new-instance is set to false. When new-instance is set to true, the KnowledgeBase is rebuilt, however declared facts are not recognized and associated rules will not fire. Rules not using declared facts will fire normally. Using POJOs works fine. In both cases the KnowledgeAgent will build the rule base the first time, the issue only seems to occur when the changeset resources are modified and are detected by the resource notifier and scanner. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

8
15
0 / 0

[JBoss JIRA] Created: (AS7-1613) NPE in TranslatingSuspendableChannel.scheduleReadTask

by Ondrej Zizka (JIRA)

NPE in TranslatingSuspendableChannel.scheduleReadTask ----------------------------------------------------- Key: AS7-1613 URL: https://issues.jboss.org/browse/AS7-1613 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.0.1.Final Reporter: Ondrej Zizka Assignee: Alexey Loubyansky Happened after a while of inactivity (if that matters). [standalone@localhost:9999 interface=public] cd .. [standalone@localhost:9999 /] cd .. [standalone@localhost:9999 /] ls extension core-service path subsystem system-property deployment interface socket-binding-group [standalone@localhost:9999 /] Exception in thread "pool-1-thread-21" java.lang.NullPointerException at org.xnio.channels.TranslatingSuspendableChannel.scheduleReadTask(TranslatingSuspendableChannel.java:253) at org.xnio.channels.TranslatingSuspendableChannel.resumeReads(TranslatingSuspendableChannel.java:233) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication$2.run(ClientConnectionOpenListener.java:498) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) 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

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] (AS7-2022) TS: Coverage reports

by Ondrej Zizka (Created) (JIRA)

TS: Coverage reports -------------------- Key: AS7-2022 URL: https://issues.jboss.org/browse/AS7-2022 Project: Application Server 7 Issue Type: Sub-task Components: Test Suite Affects Versions: 7.1.0.Alpha1 Reporter: Ondrej Zizka Assignee: Ondrej Zizka There are some coverage jobs in Hudson: * Aggregated: https://hudson.qa.jboss.com/hudson//view/JBoss%20AS/job/jboss-as7-code-co... * Per module: https://hudson.qa.jboss.com/hudson/view/JBoss AS/job/JBoss-AS-7.0.x-unit-coverage/ -- 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

13 years, 8 months

9
42
0 / 0

[JBoss JIRA] Created: (JBRULES-2791) Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager

by Anatoly Polinsky (JIRA)

Spring's JpaTransactionManager should be used instead of both: DroolsSpringTransactionManager and DroolsSpringJpaManager ------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-2791 URL: https://jira.jboss.org/browse/JBRULES-2791 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL, FUTURE Environment: Spring Based Applications Reporter: Anatoly Polinsky Assignee: Mark Proctor Instead of having two different components: "DroolsSpringTransactionManager" and "DroolsSpringJpaManager" that aim to do the work of "org.springframework.orm.jpa.JpaTransactionManager", and trying to fit a JTA model into it, the Spring's "JpaTransactionManager" itself should be used. And instead of manually managing and constantly getting references to a "proper entity manager" from JpaManger within a SingleSessionCommandService, a @PersistenceContext should be injected. This will decouple SingleSessionCommandService from JpaManager interface, and will allow _any_ JPA provider to inject an entity manager. It has more benefits, such as trust in underline JPA providers ( e.g. Hibernate ) and Spring Transaction Management capabilities to manage the process that they are actually excellent at. /Anatoly -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCOMMON-114) Warning for non File URLs should also check for vfszip URLs

by Darran Lofthouse (JIRA)

Warning for non File URLs should also check for vfszip URLs ----------------------------------------------------------- Key: JBCOMMON-114 URL: https://jira.jboss.org/browse/JBCOMMON-114 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-core (2.x) Affects Versions: 2.2.17.GA Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.2.18.GA Within the resolveSystemIDasURL method the following check is performed: - if (warnOnNonFileURLs && url.getProtocol().equalsIgnoreCase("file") == false) { log.warn("Trying to resolve systemId as a non-file URL: " + systemId); } With the introduction of vfszip URLs from JBoss 5 these should also be checked and the warning skipped if it is a vfszip URL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
4
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 February 2012