June 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] (AS7-5038) org.jboss.as.jpa module missing javax.servlet.api dependency

by Brad Maxwell (JIRA)

Brad Maxwell created AS7-5038: --------------------------------- Summary: org.jboss.as.jpa module missing javax.servlet.api dependency Key: AS7-5038 URL: https://issues.jboss.org/browse/AS7-5038 Project: Application Server 7 Issue Type: Bug Reporter: Brad Maxwell -- 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

4
10
0 / 0

[JBoss JIRA] (JBWEB-240) max-post-size documentation is incorrect. Min size in 1024.

by Jason Shepherd (JIRA)

13 years, 8 months

3
5
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] (AS7-4293) Support property expansion in redirect-port attribute of the web system's connector

by Sven-Jørgen Karlsen (JIRA)

Sven-Jørgen Karlsen created AS7-4293: ---------------------------------------- Summary: Support property expansion in redirect-port attribute of the web system's connector Key: AS7-4293 URL: https://issues.jboss.org/browse/AS7-4293 Project: Application Server 7 Issue Type: Bug Components: Web Affects Versions: 7.1.1.Final Environment: Standalone JBoss AS 7 on RHEL Linux and Windows 7 Enterprise x64 Reporter: Sven-Jørgen Karlsen Assignee: Remy Maucherat Priority: Optional The connector element of the web subsystem doesn't support property expansion, forcing you to hardwire the port number. E.g., writing: ... <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host"> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="${jboss.web.https.port}"/> ... causes a NumberFormatException. Runtime properties for this attribute was supported in previous versions. Another problem is that there is no predefined property with the above name. An alternative solution is to allow a reference to a socket binding groups in the attribute value, as discussed in http://community.jboss.org/thread/176339 -- 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

3
3
0 / 0

[JBoss JIRA] (AS7-4080) @Ignored tests (tracking)

by Ondrej Zizka (JIRA)

Ondrej Zizka created AS7-4080: --------------------------------- Summary: @Ignored tests (tracking) Key: AS7-4080 URL: https://issues.jboss.org/browse/AS7-4080 Project: Application Server 7 Issue Type: Tracker Components: Test Suite Affects Versions: 7.1.1.Final Reporter: Ondrej Zizka Assignee: Ondrej Zizka Fix For: 7.1.2.Final -- 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

2
10
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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2012