September 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-3218) Declare statements don't resolve types properly when imported with package imports (.*)

by Edson Tirelli (JIRA)

Declare statements don't resolve types properly when imported with package imports (.*) --------------------------------------------------------------------------------------- Key: JBRULES-3218 URL: https://issues.jboss.org/browse/JBRULES-3218 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.3.0.Beta1, 5.2.0.Final Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 5.2.1.Final, 5.3.0.CR1 Declare statements don't resolve types properly when imported with package imports (.*) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-1271) MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError

by Eric Sirianni (JIRA)

MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError ---------------------------------------------------------------------------------------------- Key: JGRP-1271 URL: https://issues.jboss.org/browse/JGRP-1271 Project: JGroups Issue Type: Bug Affects Versions: 2.11 Environment: All Reporter: Eric Sirianni Assignee: Bela Ban The presence of 'public static final' RequestOptions SYNC and ASYNC implies strongly that RequestOptions are immutable. Otherwise, clients could be changing the meaning of these shared constants. However, MuxMessageDispatcher.cast() mutates the passed-in RequestOptions to set the RspFilter. It chains the existing RspFilter in the RequestOptions to a new one: options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()) The result of this is that the following innocent looking code code will quickly lead to a stack overflow as the RspFilter chain in the RequestOptions.ASYNC object grows without bound: while (true) { muxMessageDispatcher.cast(dests, msg, RequestOptions.ASYNC, false); } The workaround is to create a new RequestOptions object per call to cast() : while (true) { muxMessageDispatcher.cast(dests, msg, new RequestOptions(...), false); } I recommend either: A. Deprecating the public static final RequestOptions ASYNC and SYNC fields and heavily JavaDoc'ing that clients must use a fresh RequestOptions for each send() or cast() invocation. -or- B. JavaDoc'ing the RequestOptions class as *immutable* and fixing MuxMessageDispatcher and other such JGroups blocks that mutate RequestOptions. You may wish to add a "copy constructor" to RequestOptions to facilitate this. The fix for MuxMessageDispatcher is fairly easy - just "clone" the passed-in RequestOptions and set the NoMuxHandlerRspFilter on the new RequestOptions object: < return super.cast(dests, msg, options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()), blockForResults); --- > RequestOptions newOptions = new RequestOptions(options.getMode(), options.getTimeout(), options.getAnycasting(), options, (filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter(), options.getFlags()); > return super.cast(dests, msg, newOptions), blockForResults); -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (AS7-1527) Arquillian should merge existing MANIFEST.MF

by Martin Kouba (JIRA)

Arquillian should merge existing MANIFEST.MF -------------------------------------------- Key: AS7-1527 URL: https://issues.jboss.org/browse/AS7-1527 Project: Application Server 7 Issue Type: Bug Reporter: Martin Kouba Priority: Minor CDI/ARQ/AS7 test - it's not possible to modify MANIFEST.MF (to activate AS7 module) when creating test archive because ARQ replaces user-defined manifest with its own version in the end. ARQ should merge existing manifest instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
5
0 / 0

[JBoss JIRA] Commented: (AS7-1485) Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory

by Marek Novotny (JIRA)

[ https://issues.jboss.org/browse/AS7-1485?page=com.atlassian.jira.plugin.s... ] Marek Novotny commented on AS7-1485: ------------------------------------ it looks like tag library loading from WEB-INF/lib is broken by patch. This is done by getting faces-config.xml from jboss-seam-ui.jar, where are custom Seam JSF components. > Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory > ------------------------------------------------------------------------- > > Key: AS7-1485 > URL: https://issues.jboss.org/browse/AS7-1485 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.0.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: Open To Community > > > Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory > ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]. (main) Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener > java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory > at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128) > at com.sun.faces.config.ConfigureListener$WebXmlProcessor.getConfiguredFactory(ConfigureListener.java:702) > at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:674) > at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:648) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:156) > at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:4389) > at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321) > at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:145) > at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) > at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2284) OutOfMemoryException at DT loading

by Sergey Vanskov (JIRA)

OutOfMemoryException at DT loading ---------------------------------- Key: JBRULES-2284 URL: https://jira.jboss.org/jira/browse/JBRULES-2284 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-decisiontables Affects Versions: 5.0.1.FINAL Environment: Core2Quad Windows XP Pro 64 Reporter: Sergey Vanskov Assignee: Mark Proctor I have created DT having 20.000 rows with 4 conditions and 1 action in CSV format and set the following parameters for JVM -Xmx3072M -XX:MaxPermSize=256M. I haveOutOfMemoryException with the following stack trace java.lang.OutOfMemoryError: Java heap space at java.lang.String.format(String.java:2558) at org.drools.lang.DroolsParserExceptionFactory.formatParserLocation(DroolsParserExceptionFactory.java:203) at org.drools.lang.DroolsParserExceptionFactory.createErrorMessage(DroolsParserExceptionFactory.java:104) at org.drools.lang.DroolsParserExceptionFactory.createDroolsException(DroolsParserExceptionFactory.java:89) at org.drools.lang.DRLParser.reportError(DRLParser.java:350) at org.antlr.runtime.BaseRecognizer.recoverFromMismatchedToken(BaseRecognizer.java:624) at org.antlr.runtime.BaseRecognizer.match(BaseRecognizer.java:115) at org.drools.lang.DRLParser.fact(DRLParser.java:9841) at org.drools.lang.DRLParser.lhs_pattern(DRLParser.java:9388) at org.drools.lang.DRLParser.pattern_source(DRLParser.java:7432) at org.drools.lang.DRLParser.lhs_unary(DRLParser.java:6582) at org.drools.lang.DRLParser.lhs_and(DRLParser.java:6229) at org.drools.lang.DRLParser.lhs_or(DRLParser.java:5877) at org.drools.lang.DRLParser.lhs(DRLParser.java:5673) at org.drools.lang.DRLParser.normal_lhs_block(DRLParser.java:5580) at org.drools.lang.DRLParser.when_part(DRLParser.java:3975) at org.drools.lang.DRLParser.rule(DRLParser.java:3769) at org.drools.lang.DRLParser.statement(DRLParser.java:993) at org.drools.lang.DRLParser.compilation_unit(DRLParser.java:484) at org.drools.compiler.DrlParser.compile(DrlParser.java:238) at org.drools.compiler.DrlParser.parse(DrlParser.java:78) at org.drools.compiler.DrlParser.parse(DrlParser.java:83) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:275) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:510) at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:31) .... Is 3Gb not enough for such a problem?! How may memory requirements be estimated? -- 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

12 years, 9 months

4
5
0 / 0

[JBoss JIRA] Assigned: (AS7-1818) CLONE - Web Management Interface does not allow to create connection factory for HornetQ

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/AS7-1818?page=com.atlassian.jira.plugin.s... ] Heiko Braun reassigned AS7-1818: -------------------------------- Assignee: Heiko Braun (was: Mike Brock) > CLONE - Web Management Interface does not allow to create connection factory for HornetQ > ---------------------------------------------------------------------------------------- > > Key: AS7-1818 > URL: https://issues.jboss.org/browse/AS7-1818 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console > Affects Versions: 7.0.1.Final > Reporter: Miroslav Novak > Assignee: Heiko Braun > Fix For: 7.1.0.CR1 > > > Connection factories cannot be created/removed using Web Management Interface. New interface which will allow to do this should be implemented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Assigned: (AS7-1817) CLONE - Web Management Interface has selector(filter) attribute for creating queue mandatory - should be optional

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/AS7-1817?page=com.atlassian.jira.plugin.s... ] Heiko Braun reassigned AS7-1817: -------------------------------- Assignee: Heiko Braun (was: Mike Brock) > CLONE - Web Management Interface has selector(filter) attribute for creating queue mandatory - should be optional > ------------------------------------------------------------------------------------------------------------------ > > Key: AS7-1817 > URL: https://issues.jboss.org/browse/AS7-1817 > Project: Application Server 7 > Issue Type: Bug > Components: Console > Affects Versions: 7.0.1.Final > Reporter: Miroslav Novak > Assignee: Heiko Braun > Fix For: 7.1.0.CR1 > > > Creating queue using Web Management Interface requires "selector" attribute. This attribute should be optional. When this field will be left empty then no filter (means store all messages to queue) should be set. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-9205) Clicking on a subsytem in web console shows a "Could not reveal xxx" message

by jaikiran pai (JIRA)

Clicking on a subsytem in web console shows a "Could not reveal xxx" message ---------------------------------------------------------------------------- Key: JBAS-9205 URL: https://issues.jboss.org/browse/JBAS-9205 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Console Environment: JBoss AS7 upstream (March 31 2011) Reporter: jaikiran pai Assignee: Heiko Braun Attachments: ejb3-subsystem.png Logging into AS7 web console and clicking on any of the subsystems under the "Subsystem" tree shows a error message like: "Could not reveal: server/ejb3". The server has been started in standalone mode. OS: Ubuntu 10.10 Browser : Firefox 3.6.3 JDK: Sun Java 1.6.0_21 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (AS7-1874) in case of empty string passed during DS add marshall/unmarshall fail

by Stefano Maestri (JIRA)

in case of empty string passed during DS add marshall/unmarshall fail --------------------------------------------------------------------- Key: AS7-1874 URL: https://issues.jboss.org/browse/AS7-1874 Project: Application Server 7 Issue Type: Bug Reporter: Stefano Maestri Assignee: Stefano Maestri Fix For: 7.1.0.Beta1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-9448) BaseWrapperManagerConnection cleanup causes IllegalMonitorStateException in unlock

by Pieter Delmee (JIRA)

BaseWrapperManagerConnection cleanup causes IllegalMonitorStateException in unlock ---------------------------------------------------------------------------------- Key: JBAS-9448 URL: https://issues.jboss.org/browse/JBAS-9448 Project: Legacy JBoss Application Server 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: 6.1.0, JBossAS-5.1.0.GA Reporter: Pieter Delmee Assignee: Jesper Pedersen The problem is described in details in JBTM-751, which also describes a fix by ignore solution. The bug is already fixed for IronJacamar by JBJCA-599, revision 111645 That solution is much nicer, but I can't judge if it's backwards compatible. I tested my "fix by ignore"-solution for a day in an environment that continuous to throw the mysql deadlock, and all processes and transactions continued to work correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2011