January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1575) View members should be unmodifiable alwats

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1575?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1575: --------------------------- Fix Version/s: 3.3 > View members should be unmodifiable alwats > ------------------------------------------ > > Key: JGRP-1575 > URL: https://issues.jboss.org/browse/JGRP-1575 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.1, 3.2 > Reporter: Gray Watson > Assignee: Bela Ban > Priority: Minor > Fix For: 3.3 > > > Right now the members list inside of the View is mutable. Everytime someone calls getMembers() it creates another Collections.unmodifiableList. In my view in the constructor members should be a final Collections.unmodifiableList. This would save GC throughput on all of the wrapper objects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6417) Deprecate OperationContext.Stage.IMMEDIATE

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6417: ------------------------------------- Summary: Deprecate OperationContext.Stage.IMMEDIATE Key: AS7-6417 URL: https://issues.jboss.org/browse/AS7-6417 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Fix For: 7.2.0.Alpha1 Stage.IMMEDIATE is just a shorthand for the 'stage' and 'addFirst' params exposed by the various OperationContext.addStep methods, equivalent to 'the current stage' and 'true'. It produces more understandable code to use, e.g. Stage.MODEL and 'true' than to use a fictitious Stage like IMMEDIATE, so IMMEDIATE should be deprecated as API bloat. One problem with IMMEDIATE is its name leads people to think the step is executed *immediately*, i.e. as part of the addStep call. This is incorrect but is a reasonable mistake to make. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6387) Improper error handling when attempting to remove a server-config with a running server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6387?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6387: --------------------------------------- Note that something has definitely changed in the error reporting in master vs 7.1. Even when following Osamu Nogano's steps in master, I don't get the error message he reports. It fails on ServerRemoveHandler L70, but OFE message doesn't propagate out. > Improper error handling when attempting to remove a server-config with a running server > --------------------------------------------------------------------------------------- > > Key: AS7-6387 > URL: https://issues.jboss.org/browse/AS7-6387 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP) > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 7.2.0.Alpha1 > > > Trying to remove the config for server-one while it's still running produces an uninformative failure: > [domain@localhost:9999 /] /host=master/server-config=server-one:remove > { > "outcome" => "failed", > "result" => undefined, > "rolled-back" => true, > "server-groups" => undefined > } > An EAP 6 user reported a similar problem but with a different response: > [domain@localhost:9999 /] /host=xyz/server-config=as1:remove > { > "outcome" => "success", > "result" => { > "outcome" => "failed", > "failure-description" => "[core-service, path, server-config, system-property, jvm, interface]", > "rolled-back" => true > }, > "failure-description" => undefined > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6387) Improper error handling when attempting to remove a server-config with a running server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6387?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned AS7-6387: ------------------------------------- Assignee: Emanuel Muckenhuber (was: Brian Stansberry) Emanuel, assigning to you to get your comment on why the code that causes the failure Osamu Nagano reports is there: ServerRemoveHandler, L69-71 {code} if(! context.getResourceRegistration().getChildNames(PathAddress.EMPTY_ADDRESS).contains(SERVER)) { throw new OperationFailedException(new ModelNode().set(context.getResourceRegistration().getChildNames(PathAddress.EMPTY_ADDRESS).toString())); } {code} This will fail with a not very useful error message if no servers are started. I don't see why the presence of child type 'server' is required. Solving that bit isn't the entire fix though. My original problem description is a different case, where the server is still running and thus the op *should* fail but the error message isn't reported correctly. > Improper error handling when attempting to remove a server-config with a running server > --------------------------------------------------------------------------------------- > > Key: AS7-6387 > URL: https://issues.jboss.org/browse/AS7-6387 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP) > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 7.2.0.Alpha1 > > > Trying to remove the config for server-one while it's still running produces an uninformative failure: > [domain@localhost:9999 /] /host=master/server-config=server-one:remove > { > "outcome" => "failed", > "result" => undefined, > "rolled-back" => true, > "server-groups" => undefined > } > An EAP 6 user reported a similar problem but with a different response: > [domain@localhost:9999 /] /host=xyz/server-config=as1:remove > { > "outcome" => "success", > "result" => { > "outcome" => "failed", > "failure-description" => "[core-service, path, server-config, system-property, jvm, interface]", > "rolled-back" => true > }, > "failure-description" => undefined > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1575) View members should be unmodifiable alwats

by Gray Watson (JIRA)

Gray Watson created JGRP-1575: --------------------------------- Summary: View members should be unmodifiable alwats Key: JGRP-1575 URL: https://issues.jboss.org/browse/JGRP-1575 Project: JGroups Issue Type: Enhancement Affects Versions: 3.2, 3.1 Reporter: Gray Watson Assignee: Bela Ban Priority: Minor Right now the members list inside of the View is mutable. Everytime someone calls getMembers() it creates another Collections.unmodifiableList. In my view in the constructor members should be a final Collections.unmodifiableList. This would save GC throughput on all of the wrapper objects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-22) Drools index files are getting created out of control and consume all of the hard drive space

by Jyothi Alapati (JIRA)

[ https://issues.jboss.org/browse/DROOLS-22?page=com.atlassian.jira.plugin.... ] Jyothi Alapati commented on DROOLS-22: -------------------------------------- We are using Drools 5.0.1 > Drools index files are getting created out of control and consume all of the hard drive space > --------------------------------------------------------------------------------------------- > > Key: DROOLS-22 > URL: https://issues.jboss.org/browse/DROOLS-22 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Jyothi Alapati > Assignee: Mark Proctor > Attachments: repository.xml, workspace.xml > > > Drools index files are getting created out of control and consume all of the hard drive space. It used to consume 20MB for index files, but in this case, it consumed 5GB of hard disk space and stopped working. > Note: Deleting the old index files except the latest solved this problem, but we want this to be prevented, instead of deleting the index files manually. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-363) Validation errors with "jboss-web_7_0.xsd

by Wolfgang Knauf (JIRA)

Wolfgang Knauf created JBMETA-363: ------------------------------------- Summary: Validation errors with "jboss-web_7_0.xsd Key: JBMETA-363 URL: https://issues.jboss.org/browse/JBMETA-363 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Components: web Affects Versions: 7.0.5 Environment: Eclipse Reporter: Wolfgang Knauf Assignee: Jean-Frederic Clere I tried to create a "jboss-web.xml" file based on the "jboss-web_7_1.xsd" As this is not uploaded to the web up to now, I created it with a schema location pointing to my local JBoss 7.2.0Alpha1 snapshot: <?xml version="1.0" encoding="UTF-8"?> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee file:///C:/Temp/jboss-as-7.2.0.Alpha1-SNAPSHOT/docs/schema/jboss-web_7_0.xsd" version="7.0"> ... </jboss-web> Eclipse shows validation errors in the XSD file. The first on is: sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurences of 'http://java.sun.com/xml/ns/javaee,descriptionGroup' (occurs in javaee_6.xsd, line 88) And a lot more of those. The file was created as part of https://issues.jboss.org/browse/AS7-1262 - and the one who created it found the same validation error. It seems the fix is quite simple: "jboss-web_7_0.xsd" contains this import: <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="web-app_3_0.xsd"/> Change it to: <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"/> The reason seems to be: "jboss-web_7_0.xsd" imports "jboss-common_6-0.xsd", and this one imports "javaee_6.xsd" with a full schema location. The "web-app_3_0.xsd" in "jboss-web_7_0.xsd" has a local schema location, thus the "javaee_6.xsd" import in "web-app_3_0.xsd" points also to local. And this seems to cause a duplicate import of the file. (might also be an Eclipse valiation bug) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-20) Compilation exception gets eaten by MVEL

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-20?page=com.atlassian.jira.plugin.... ] Mario Fusco resolved DROOLS-20. ------------------------------- Resolution: Done fixed with mvel 2.1.4 > Compilation exception gets eaten by MVEL > ---------------------------------------- > > Key: DROOLS-20 > URL: https://issues.jboss.org/browse/DROOLS-20 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > > To reproduce: > - open planner, run the CloudBalancingApp, load a dataset and click button solve. This will work. > - Now open drools-planner-examples/src/main/resources/org/drools/planner/examples/cloudbalancing/solver/cloudBalancingScoreRules.drl > - At line 114, change > {code} > IntConstraintOccurrence(constraintType = ... > {code} > into > {code} > IntConstraintOccurrence(ConstraintType = ... > {code} > (so change only the case of the first letter of constraintType > - Run the CloudBalancingApp, load a dataset and click button solve. It will fail with this exception (which is not the real exception): > {code} > org.kie.runtime.rule.ConsequenceException: Exception executing consequence for rule "computerCost" in org.drools.planner.examples.cloudbalancing.solver: java.lang.NullPointerException > at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > ... > Caused by: java.lang.NullPointerException: null > at java.lang.String.<init>(String.java:168) ~[na:1.7.0_09] > at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:12) ~[mvel2-2.1.3.Final.jar:na] > at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:302) ~[mvel2-2.1.3.Final.jar:na] > at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62) ~[mvel2-2.1.3.Final.jar:na] > at org.mvel2.MVEL.compileExpression(MVEL.java:810) ~[mvel2-2.1.3.Final.jar:na] > at org.drools.base.mvel.MVELCompilationUnit.compile(MVELCompilationUnit.java:435) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:205) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:189) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:156) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:143) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:498) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:383) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:232) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:244) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:352) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.beliefsystem.simple.SimpleBeliefSystem.insert(SimpleBeliefSystem.java:49) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.common.TruthMaintenanceSystem.addLogicalDependency(TruthMaintenanceSystem.java:150) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.common.TruthMaintenanceSystem.addLogicalDependency(TruthMaintenanceSystem.java:121) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:227) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:822) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:255) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:220) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:215) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > at org.drools.planner.examples.cloudbalancing.solver.Rule_computerCost_eb2dbb0704b64ca3a554fbda80ff54ab.defaultConsequence(Rule_computerCost_eb2dbb0704b64ca3a554fbda80ff54ab.java:7) ~[na:na] > at org.drools.planner.examples.cloudbalancing.solver.Rule_computerCost_eb2dbb0704b64ca3a554fbda80ff54abDefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na] > at org.drools.planner.examples.cloudbalancing.solver.Rule_computerCost_eb2dbb0704b64ca3a554fbda80ff54abDefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na] > at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1421) ~[drools-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT] > ... 21 common frames omitted > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-5350) CliArgumentsTestCase.testWrongControler always fails on windows

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/AS7-5350?page=com.atlassian.jira.plugin.s... ] Alexey Loubyansky resolved AS7-5350. ------------------------------------ Fix Version/s: 7.2.0.Alpha1 Resolution: Done Fixed. > CliArgumentsTestCase.testWrongControler always fails on windows > --------------------------------------------------------------- > > Key: AS7-5350 > URL: https://issues.jboss.org/browse/AS7-5350 > Project: Application Server 7 > Issue Type: Bug > Components: CLI > Affects Versions: 7.1.2.Final (EAP), 7.2.0.Alpha1 > Environment: Windows > Reporter: Tomaz Cerar > Assignee: Alexey Loubyansky > Fix For: 7.2.0.Alpha1 > > > org.jboss.as.test.integration.management.cli.CliArgumentsTestCase.testWrongControler consistently fails on windows. > jenkins build where it can be seen > http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-windows... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6392) standalone.sh / domain.sh does not support overriding jboss.server.base.dir, log and config dir in CYGWIN

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6392?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned AS7-6392: ------------------------------------- Assignee: (was: Brian Stansberry) If you have a patch for this that you know will reliably work (i.e. doesn't require an unusual cygwin environment), please submit a pull request. > standalone.sh / domain.sh does not support overriding jboss.server.base.dir, log and config dir in CYGWIN > --------------------------------------------------------------------------------------------------------- > > Key: AS7-6392 > URL: https://issues.jboss.org/browse/AS7-6392 > Project: Application Server 7 > Issue Type: Bug > Components: Scripts > Affects Versions: 7.1.3.Final (EAP) > Reporter: Tom Fonteyne > > There is a check on linux, so a cygwin system will not execute this block: > if $linux; then > # consolidate the server and command line opts > CONSOLIDATED_OPTS="$JAVA_OPTS $SERVER_OPTS" > # process the standalone options > for var in $CONSOLIDATED_OPTS > do > case $var in > -Djboss.server.base.dir=*) > JBOSS_BASE_DIR=`readlink -m ${var#*=}` > ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
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 January 2013