[JBoss JIRA] (DROOLS-3073) Wrong full package if you use classes from another folder
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3073?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3073:
-------------------------------------
Sprint: 2018 Week 39-41
> Wrong full package if you use classes from another folder
> ----------------------------------------------------------
>
> Key: DROOLS-3073
> URL: https://issues.jboss.org/browse/DROOLS-3073
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Major
> Attachments: Screenshot from 2018-10-05 15-32-12.png, scesim.zip
>
>
> Step to reproduce:
> - Create a Data Object "Object1" in a specific package (i.e. com.myspace.myproject)
> - Create a Test Scenario (Preview) "Test1" in a different package (i.e. com.myspace)
> - Use Data Objects tab to import "Object1" to "Test1"
> - Reload the asset and map a field of "Object1" to a column
> - Fill "Test1" with valid values
> - Run the scenario
> Result: Impossible to load class com.myspace.Object1
> Minor bug: if "Test1" has been create in default package the error that you get is "Impossible to load class *.*Object1" so it should be impossible to create the asset into default package or it should consider it to avoid "." symbol at the beginning
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3052) Implement read only mechanism for the cells in Scenario grid
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3052?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3052:
-------------------------------------
Sprint: 2018 Week 39-41
> Implement read only mechanism for the cells in Scenario grid
> ------------------------------------------------------------
>
> Key: DROOLS-3052
> URL: https://issues.jboss.org/browse/DROOLS-3052
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
>
> Update ScenarioGridColumn and ScenarioGridCell to support read only mode.
> ScenarioHeaderMetaData already has a similar mechanism so it is probably possible to define a common interface to abstract this behaviour
> *Acceptance criteria*
> - If a column is in read only mode all the contained cells have to be read only
> - If a cell/column is in read only mode, inline editing should be disabled
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3053) Warning popup of column type change in Scenario grid
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3053?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi updated DROOLS-3053:
-------------------------------------
Sprint: 2018 Week 39-41
> Warning popup of column type change in Scenario grid
> ----------------------------------------------------
>
> Key: DROOLS-3053
> URL: https://issues.jboss.org/browse/DROOLS-3053
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
> Labels: UX, UXTeam
> Attachments: Screenshot from 2018-10-04 17-44-51.png, Screenshot from 2018-10-04 17-45-21.png, warning2.png
>
>
> Implement a warning popup when the user changes the type of a column that has been already populated.
> To be done/merged *after* DROOLS-3051.
> *Acceptance criteria*
> - If the column contains no value, no confirmation is needed
> - If old and new types are the same the user has to decide if the values should be removed or not
> - If old and new types are not the same the user has to accept that old values will be removed
> - All warning popups should contains also a "Cancel" command to abort the edit
> - If the user try to update the column type with the same column type no warning should be raised and data should stay untouched
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3080) SpreadsheetCompiler generates wrong LHS order
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3080?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-3080:
--------------------------------
Fix Version/s: 7.13.0.Final
> SpreadsheetCompiler generates wrong LHS order
> ---------------------------------------------
>
> Key: DROOLS-3080
> URL: https://issues.jboss.org/browse/DROOLS-3080
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.12.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Fix For: 7.13.0.Final
>
> Attachments: LhsOrder.xls
>
>
> When a Spreadsheet (xls) has CONDITION columns like:
> - The first column doesn't have Fact (e.g. accumulate(...))
> - The second column has Fact (e.g. $p:Person(...))
> (See attached LhsOrder.xls)
> , SpreadsheetCompiler generates a DRL with inverse order in LHS.
> {noformat}
> rule "LhsOrder_11"
> when
> $p:Person(name == "John", age == $max)
> accumulate(Person(name == "John", $a : age); $max:max($a))
> then
> System.out.println("hello, " + $p.getName());
> end
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3050) Serial Version UUID on Declared Types
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3050?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-3050:
--------------------------------
Fix Version/s: 7.13.0.Final
> Serial Version UUID on Declared Types
> -------------------------------------
>
> Key: DROOLS-3050
> URL: https://issues.jboss.org/browse/DROOLS-3050
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.12.0.Final
> Reporter: Stylianos Koussouris
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.13.0.Final
>
>
> We wish to update DeclaredTypes whilst session is in use but the generated serial version ID changes when the DeclaredType pojo is recompiled resulting InvalidClassExceptions. We therefore suggest the usage of an annotation @SerialVersionUUID to set in a constant manner the UUID
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3089) ThreadSafeTrackableTimeJobFactoryManager for default
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-3089?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-3089:
--------------------------------
Fix Version/s: 7.13.0.Final
> ThreadSafeTrackableTimeJobFactoryManager for default
> ----------------------------------------------------
>
> Key: DROOLS-3089
> URL: https://issues.jboss.org/browse/DROOLS-3089
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.12.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Priority: Major
> Labels: support
> Fix For: 7.13.0.Final
>
>
> By default, TrackableTimeJobFactoryManager is set by SessionConfigurationImpl.
> https://github.com/kiegroup/drools/blob/7.11.0.Final/drools-core/src/main...
> If users access a ksession via multiple threads, it would potentially hit a HashMap concurrency issue (e.g. https://stackoverflow.com/questions/22944918/why-does-the-code-hang-with-...).
> ThreadSafeTrackableTimeJobFactoryManager is bundled for multi-thread use. You can use it by
> Drools 7:
> {noformat}
> System.setProperty("drools.timerJobFactory", "thread_safe_trackable");
> {noformat}
> Drools 6.3+:
> {noformat}
> KieSessionConfiguration kconf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> ((org.drools.core.SessionConfiguration)kconf).setTimerJobFactoryType( TimerJobFactoryType.THREAD_SAFE_TRACKABLE );
> KieSession ksession = kContainer.newKieSession("ksession-name", kconf);
> {noformat}
> However, it's better to make ThreadSafeTrackableTimeJobFactoryManager default because "Suddenly hitting an issue in production" is significant than "small overhead by ConcurrentHashMap". (Generally, users are not very conscious about "it is accessed by multi-threads or not")
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELYWEB-29) Build into clean maven repo fails
by Martin Choma (Jira)
Martin Choma created ELYWEB-29:
----------------------------------
Summary: Build into clean maven repo fails
Key: ELYWEB-29
URL: https://issues.jboss.org/browse/ELYWEB-29
Project: Elytron Web
Issue Type: Bug
Components: Undertow Servlet
Affects Versions: 1.3.0.CR2
Reporter: Martin Choma
{noformat}
mvn clean install -Dmaven.repo.local./local-maven-repo -DskipTests
...
[ERROR] Failed to execute goal on project undertow-server-servlet: Could not resolve dependencies for project org.wildfly.security.elytron-web:undertow-server-servlet:jar:1.3.0.CR3-SNAPSHOT: Could not find artifact org.jboss.metadata:jboss-metadata-common:jar:11.0.0.Final in central (https://repo.maven.apache.org/maven2) -> [Help 1]
...
{noformat}
jboss-metadata-common is really not in central repo https://repo.maven.apache.org/maven2
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months