January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8536) Cannot connect to JSR160 with IPv6

by Thomas Diesler (JIRA)

Cannot connect to JSR160 with IPv6 ---------------------------------- Key: JBAS-8536 URL: https://jira.jboss.org/browse/JBAS-8536 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Management services Reporter: Thomas Diesler Assignee: Dimitris Andreadis Fix For: 7.0.0.M2 jconsole cannot connect using a connection URL when server runs with IPv6 on Fedora13 -- 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

15 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8657) Provide an installer for AS7

by Thomas Diesler (JIRA)

Provide an installer for AS7 ---------------------------- Key: JBAS-8657 URL: https://jira.jboss.org/browse/JBAS-8657 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Installer Reporter: Thomas Diesler Assignee: Amit Bhayani Brian says I don't see commented out config as a solution. First, at this point, when the file is re-written following an update, comments are lost. That may change, but in general using the file as documentation is fragile. Second, if we added commented out sections for all the various options different subsystems may want to expose, we'll soon have a 1,00 line file full of confusing stuff. I think we're going to need a mix of things to solve this: 1) Ship a few different canned configs files for the most common profiles, with the user able to select which they want via a command line switch. 2) An "examples" dir in the dist where some less common choices can be highlighted. 3) Most importantly, an installer application where users can easily tell us what subsystems they want in their profile. This is the most important part; #1 is mostly to provide a very easy out-of-the-box experience. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-8722) Deployment rollback does not log the cause of the rollback

by Thomas Diesler (JIRA)

Deployment rollback does not log the cause of the rollback ---------------------------------------------------------- Key: JBAS-8722 URL: https://jira.jboss.org/browse/JBAS-8722 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers Reporter: Thomas Diesler Assignee: Thomas Diesler -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2836) Nested conditional expression (x?y:z) does not resolve variable binding

by Wolfgang Laun (JIRA)

Nested conditional expression (x?y:z) does not resolve variable binding ----------------------------------------------------------------------- Key: JBRULES-2836 URL: https://issues.jboss.org/browse/JBRULES-2836 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler, drools-compiler (expert) Affects Versions: 5.1.1.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.0.M1 A return value restriction containing a nested conditional expression referencing two previously bound variables is flagged as erroneous. (A similar, not nested, expression referencing the same variables, is compiled and executed correctly.) The provided DRL is sufficient for producing the error: ule Compilation error : [Rule name='check sum'] appl/domain/Rule_check_sum_0.java (9:417) : $a2 cannot be resolved -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2873) Rule fires unexpectedly - not CE fails

by Wolfgang Laun (JIRA)

Rule fires unexpectedly - not CE fails -------------------------------------- Key: JBRULES-2873 URL: https://issues.jboss.org/browse/JBRULES-2873 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Priority: Critical The rule shown below fires, and then the code on the RHS prints "But cell ... matches" which is only possible when there is a Cell according to the constraints in the "not" CE. - The full Sudoku code is available. rule "column elimination" when not Setting() $i: Integer() # occurs in a Cell $c: Cell( free contains $i, $cs: cellSqr, $cc: cellCol ) # but not in another cell of the same square and a different column not Cell( this != $c, free contains $i, cellSqr == $cs, cellCol != $cc ) ## not ( $oc: Cell( this != $c ) ## and ## eval( $oc.getFree().contains( $i ) && ## $oc.getCellSqr().equals( $cs ) && ## ! $oc.getCellCol().equals( $cc ) ) ) # but there is a cell in the same column and another square containing this value $cx: Cell( freeCount > 1, free contains $i, cellCol == $cc, cellSqr != $cs ) then # remove the value from that other cell System.out.println( "column elimination due to " + $c.posAsString() + ": remove " + $i + " from " + $cx.posAsString() ); for( int iRow = 0; iRow < 9; iRow++ ){ for( int iCol = 0; iCol < 9; iCol++ ){ Cell cell = Sudoku.sudoku.cells[iRow][iCol]; if( ! cell.equals( $c ) && cell.getCellSqr().equals( $cs ) && ! cell.getCellCol().equals( $cc ) && cell.getFree().contains( $i ) ){ System.out.println( "But cell " + cell.toString() + " matches!" ); } } } for( Cell c: $cs.getCells() ){ System.out.print( c.posAsString() + ": " + c.getFree() + " cc="+c.getCellCol() + " cs="+c.getCellSqr() + "; " ); } System.out.println(); modify( $cx ){ blockValue( $i ) } end -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
8
0 / 0

[JBoss JIRA] Created: (JBRULES-2504) Maven: clean up the maven build and prepare for maven 3 (multi-issue)

by Geoffrey De Smet (JIRA)

Maven: clean up the maven build and prepare for maven 3 (multi-issue) --------------------------------------------------------------------- Key: JBRULES-2504 URL: https://jira.jboss.org/jira/browse/JBRULES-2504 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.0.M1 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Minor Fix For: FUTURE This is a list of the smaller issues: * Don't use compile dependencies for dependencies that should be purely transitive dependencies * Don't use <optional> in <dependencyManagement> ** might not already be the case * All of the generated files should be in the target directory ** guvnor: version file etc ** several modules (osgi based?): MANIFEST.MF Bigger issues are linked. -- 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

15 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2703) AllBestSolutionsRecaller: Drools Planner should support returning all the solutions with the same best score found during solving, not just the first

by Geoffrey De Smet (JIRA)

AllBestSolutionsRecaller: Drools Planner should support returning all the solutions with the same best score found during solving, not just the first ----------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2703 URL: https://jira.jboss.org/browse/JBRULES-2703 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.1.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.2.0.M1 Extra method on Solver: getBestSolutions(). Maybe rename BestSolutionRecaller to AllBestSolutionsRecaller? I wouldn't keep the first if a couple experiments should little or no performance degradation due to the hashing of each solution step (especially in sim ann). What do we do with Solver.getBestSolution()? Proposition 1: remove it Proposition 2: keep it and return getBestSolutions().get(0) -- 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2043) Log problems while building the RuleBase

by Dietmar Scheidl (JIRA)

Log problems while building the RuleBase ---------------------------------------- Key: JBRULES-2043 URL: https://jira.jboss.org/jira/browse/JBRULES-2043 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-solver Affects Versions: 5.0.0.M5 Reporter: Dietmar Scheidl Assignee: Mark Proctor I startet to experiment with the drools-solver but only got a NullPointerException: Caused by: java.lang.NullPointerException at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:429) at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:395) at org.drools.solver.config.localsearch.LocalSearchSolverConfig.buildRuleBase(LocalSearchSolverConfig.java:166) at org.drools.solver.config.localsearch.LocalSearchSolverConfig.buildSolver(LocalSearchSolverConfig.java:137) at org.drools.solver.config.XmlSolverConfigurer.buildSolver(XmlSolverConfigurer.java:73) ... After debugging into this location, I found out that it comes from an error in my scoreDrl. The buildSolver-Method should fail with a more helpful exception or the result of the PackageBuilder should be available to analyse the problems. -- 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

15 years, 2 months

4
13
0 / 0

[JBoss JIRA] Created: (JBCOMMON-117) Race-condition leads to IllegalStateException Cache list entries number (x) > than the maximum allowed (x-1)

by Rico Neubauer (JIRA)

Race-condition leads to IllegalStateException Cache list entries number (x) > than the maximum allowed (x-1) ------------------------------------------------------------------------------------------------------------ Key: JBCOMMON-117 URL: https://issues.jboss.org/browse/JBCOMMON-117 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-core (2.x) Affects Versions: 2.2.17.GA, 2.2.18.GA Reporter: Rico Neubauer Attachments: JBCOMMON-117.diff org.jboss.util.LRUCachePolicy takes care of a cache with a maxCapacity. Unfortunately the modifications of the count of entries is not thread-safe and might lead to the situation that the cache holds more than maxCapacity entries. This can only be seen rarely under heavy load on SMP machines; so far the count reached at most maxCapacity+1, but it's imaginable it could go beyond. One possibility is to fix the modifications of count, which should preferably NOT introduce synchronizations. Another simpler approach is to not throw the exception in case of the cache already having crossed the limit (which itself does not error-out), but behave nicely, since there are no real implications and the limit is not considered to be needed that strict imho. I will attach a proposed patch, showing the problem and using the latter option to fix it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2434) Emiting regexps in DSLs is unwieldy in the extreme

by Denis Robert (JIRA)

Emiting regexps in DSLs is unwieldy in the extreme -------------------------------------------------- Key: JBRULES-2434 URL: https://jira.jboss.org/jira/browse/JBRULES-2434 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler-DSL Affects Versions: 5.0.1.FINAL Environment: All Reporter: Denis Robert Assignee: Mark Proctor Priority: Minor Any regexp emitted by a DSL must be octupled in order to pass through to the DRL and actually work in the rule. Example: I have a simple rule (I should say: a rule which SHOULD be simple), to test for emails: [condition][]is not email=not matches "^[\\\\\\\\w-]+(\\\\\\\\.[\\\\\\\\w-]+)*@([a-z0-9-]+(\\\\\\\\.[a-z0-9-]+)*?\\\\\\\\.[a-z]{2,6}|(\\\\\\\\d{1,3}\\\\\\\\.){3}\\\\\\\\d{1,3})(:\\\\\\\\d{4})?$" As you can see, each backslash is there 8 times. By then time it appears in the resulting DSL, they are doubled (which contrary to docs must be the case, otherwise the regexp does not behave correctly). Regular expressions should be treated differently throughout Drools. Maybe by using raw strings as in Perl or C#? It's really annoying... -- 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

15 years, 2 months

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