September 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1837) Upgrade to JBoss SASL 1.0.0.Beta3

by Darran Lofthouse (JIRA)

Upgrade to JBoss SASL 1.0.0.Beta3 --------------------------------- Key: AS7-1837 URL: https://issues.jboss.org/browse/AS7-1837 Project: Application Server 7 Issue Type: Task Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.0.2.Final (Also remove workaround for working with PLAIN mechanism) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBRULES-3176) Classload issue on Package Merging for MVEL dialect's

by Mark Proctor (JIRA)

Classload issue on Package Merging for MVEL dialect's ----------------------------------------------------- Key: JBRULES-3176 URL: https://issues.jboss.org/browse/JBRULES-3176 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor Packages, for MVEL, on creation have imports that reference Class instances. When you merge those Packages, like when adding to the kbase, it retains reference to those Classes. Thse classes may have been generated on a different classloader. We must instead store the String and re-resolve on merge. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-3178) Query results getIdentifier should preserve the positional ordering for query parameter declarations

by Mark Proctor (JIRA)

Query results getIdentifier should preserve the positional ordering for query parameter declarations ---------------------------------------------------------------------------------------------------- Key: JBRULES-3178 URL: https://issues.jboss.org/browse/JBRULES-3178 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor Fix For: 5.3.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-3202) named query TasksAssignedAsPotentialOwner doesn't work with MySql db

by Frank23 Knoll23 (JIRA)

named query TasksAssignedAsPotentialOwner doesn't work with MySql db --------------------------------------------------------------------- Key: JBRULES-3202 URL: https://issues.jboss.org/browse/JBRULES-3202 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Environment: MYSQL database Reporter: Frank23 Knoll23 Assignee: Mark Proctor Hi, When I add a task (having two potential owners) by calling the method addTask followed by calling the method getTasksAssignedAsPotentialOwner of org.jbpm.task.service.TaskClient I expect to receive a list of TaskSummaries containing at least the previously added task. But I actually get an empty list! Here is my setup and possible solution: I am using the trunk version of ./jbpm-human-task/src/main/resources/META-INF/orm.xml and a MYSQL database. When calling addTask the Task table will be populated with a NULL actualOwner_id. The named query TasksAssignedAsPotentialOwner "select new org.jbpm.task.query.TaskSummary(...t.taskData.actualOwner...) from ... left join t.taskData.actualOwner ..." of orm.xml generates SQL consisting of an inner join "inner join OrganizationalEntity user7_ on task0_.actualOwner_id=user7_.id" which doesn't take the NULL actualOwner_id correctly into account. When I replace the named query TasksAssignedAsPotentialOwner with "select new org.jbpm.task.query.TaskSummary(...actualOwner...) from ...left join t.taskData.actualOwner as actualOwner ...", then the generated SQL consists of an "left outer join OrganizationalEntity user2_ on task0_.actualOwner_id=user2_.id" which takes the NULL actualOwner_id correctly into account. So I get a List of TaskSummaries containing the added task. Is this a correct fix? Cheers, Frank -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-3044) Need BRMS-586/590 hotfix for Drools 5.1.1 / Salience firing order reversed or not observed on multple fact inserts post index

by Armand Welsh (JIRA)

Need BRMS-586/590 hotfix for Drools 5.1.1 / Salience firing order reversed or not observed on multple fact inserts post index ----------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-3044 URL: https://issues.jboss.org/browse/JBRULES-3044 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 5.1.1.FINAL Environment: Windows 7/64, ReHat Enterprise Linux 6, Drools 5.1.1 running Java 6 JRE/SDK (all versions currently available from Oracle), 2 GB RAM, 20+ GB Free HD Space Reporter: Armand Welsh Assignee: Mark Proctor Priority: Critical Fix For: 5.1.1.FINAL When executing fireAllRules, all pre-index rules fire adhering to the salience prioritization. If, however, during post-index execution, facts are inserted that are used in the conditions of lower salience rules in the same activation group, the rule will fire, regardless of the fact a higher salience rule has already fired. This is further complicated when defining default rules of default salience (though any salience value will suffice so long as the default rule has the lowest salience within the activation group). When no pre-indexed facts are availble for the activation group, the default rule fires. along, with other activation group rules. During execution, a new fact is inserted that provides a hit for a higher salience rule in the same activation group as the default rule which already fired, however, the rule is not fired. In effect, pre-indexed facts are processed in descending salience order. whereas post-indexed facts are processed in ascending salience order. In all scenarios described, there is not a fire once restriction assigned. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-3146) timer rule cannot work fine, if the method 'ksession.fireAllRules()' is called before we reload KnowlegeSession.

by winton xu (JIRA)

timer rule cannot work fine, if the method 'ksession.fireAllRules()' is called before we reload KnowlegeSession. ---------------------------------------------------------------------------------------------------------------- Key: JBRULES-3146 URL: https://issues.jboss.org/browse/JBRULES-3146 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.Final Reporter: winton xu Assignee: Mark Proctor Priority: Critical we can reproduce it by following steps. 1. create a knowledge session. and call the method 'fireAllRules()' 2. reload knowledge session. 3. crate and build a timer rule. 4. fire the timer rule. [Actual Result] the timer rule cannot work fine. [Expected Result] the timer rule can work fine. (please check the attachement 'TimerAndCalendarTest.java.txt') -- 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: (JBRULES-3213) DisposeCommand closes down all data structures and then persits them

by Mark Proctor (JIRA)

DisposeCommand closes down all data structures and then persits them -------------------------------------------------------------------- Key: JBRULES-3213 URL: https://issues.jboss.org/browse/JBRULES-3213 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor Disposing is only for closing down resources, not deleting state n the remote server. At the moment it's closing down things, like timer service, which has a list of state to persist. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-3207) Getting 5.2.x Working Again after various merges

by Mark Proctor (JIRA)

Getting 5.2.x Working Again after various merges ------------------------------------------------ Key: JBRULES-3207 URL: https://issues.jboss.org/browse/JBRULES-3207 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-3212) Spring is closing EntityManager early

by Mark Proctor (JIRA)

Spring is closing EntityManager early ------------------------------------- Key: JBRULES-3212 URL: https://issues.jboss.org/browse/JBRULES-3212 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBMETA-338) Fix WS ref parsing & merging process

by Richard Opalka (JIRA)

Fix WS ref parsing & merging process ------------------------------------ Key: JBMETA-338 URL: https://issues.jboss.org/browse/JBMETA-338 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Components: common Affects Versions: 7.0.0.Beta12 Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 7.0.0.Beta13 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
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