Bug 1173075 - Editor shows Position 0 even when no @org.kie.api.definition.type.Position is defined
Summary: Editor shows Position 0 even when no @org.kie.api.definition.type.Position is...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Data Modeler
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ER5
: 6.1.0
Assignee: Walter Medvedeo
QA Contact: Lukáš Petrovický
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-11 12:10 UTC by Zuzana Krejčová
Modified: 2020-03-27 19:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:45:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot (34.17 KB, image/png)
2014-12-11 12:10 UTC, Zuzana Krejčová
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1173089 0 high CLOSED Default Position value doesn't take into account superclasses 2021-02-22 00:41:40 UTC

Internal Links: 1173089

Description Zuzana Krejčová 2014-12-11 12:10:23 UTC
Created attachment 967209 [details]
screenshot

Description of problem:
For a data object like this:

public class BaseFact {
    private String f1;

    public String getF1() {
        return f1;
    }

    public void setF1(String f1) {
        this.f1 = f1;
    }
}

The Data Modeler editor shows the field f1 with Position 0, even though no @org.kie.api.definition.type.Position is defined on that field in the source.

This is incorrect information and quite confusing when debugging other issues.


Version-Release number of selected component (if applicable):
6.1 ER2

Comment 1 Edson Tirelli 2015-01-12 15:51:19 UTC
Zuzana, 

This behaviour is correct. Even when no explicit @Position annotations are defined, the engine has to assign implicit positions for fields, because they are required by other features. Implicit positions take field order into account. 

For instance:

public class X {
   private Y field1;
   private Z field2;
...
}

The above class will have implicitly defined fiedl1 as position 0, and field2 as position 1.

My recommendation is to close this ticket, unless you think there is any other issue?

Thanks

Comment 2 Walter Medvedeo 2015-01-21 10:00:44 UTC
The positions usage was reviewed, and now applies the following new criteria.

It was found that the @Position is used in a low percent of drools rules/applications. So the auto-calculation of the position reported in this BZ was removed. Also, given that the position is rarely used when don't assign position by default to the fields when then are created through the UI. 
It means that when the user creates fields through the UI no position is assigned. Advanced drools users that has the need to use position, tipically in a subset of the class fields, can then manually assign the position.

The position column was also removed by the same reason, position is used by advanced drools users in a low percent of cases and confuses business users.

The following commits solves the issue:

 master URL: http://github.com/droolsjbpm/kie-wb-common/commit/e822d9333


 master URL: http://github.com/droolsjbpm/kie-wb-common/commit/d9812a09e



 push 6.2.x URL: http://github.com/droolsjbpm/kie-wb-common/commit/3a73a8c55


 push 6.2.x URL: http://github.com/droolsjbpm/kie-wb-common/commit/f3fa0582b


Note You need to log in before you can comment on or make changes to this bug.