This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 80035 - Attribute multiplicity is not propagated to Model when it was added to source
Summary: Attribute multiplicity is not propagated to Model when it was added to source
Status: VERIFIED FIXED
Alias: None
Product: uml
Classification: Unclassified
Component: Synchronization (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Craig Conover
URL:
Keywords:
: 80601 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-07-12 03:04 UTC by Craig Conover
Modified: 2006-08-31 02:29 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Conover 2006-07-12 03:04:39 UTC 
Steps to reproduce:

- Create a Java project
- Create a UML project associated with the Java project
- Create a Class diagram
- Add  Class Element on the diagram and name it 'MyClass'
- Add new 'private int a' attribute into the 'MyClass' element
- Go to source of 'MyClass' class
- Change 'private int a' to 'private int a[]'
- Go to the diagram
  'a' attribute does not have multiplicity on the 'MyClass' element
Comment 1 Craig Conover 2006-07-12 03:05:56 UTC 
Appears that it doesn't see the difference between int and int[], but it works
if you change the type from int to String[]. So somehow it is not considering
the brackets in some comparison.
Comment 2 Craig Conover 2006-07-12 03:50:21 UTC 
Has the same problem going from int[] back to int as well.
Comment 3 Craig Conover 2006-07-12 04:03:07 UTC 
As I suspected, the new and old types are being compared without the brackets
being considered, so int and int[] resolve to be the same type and no event is
fired telling the getter and setter to change their types. This comparison is
peformed in the method setType(IClassifier newClassifier) of TypedElement in
package org.netbeans.modules.uml.core.metamodel.infrastructure.coreinfrastructure.

But the fix may be to make sure the type with the brackets is passed in with the
brackets rather than changing TypeElement's code. We shall see.
Comment 4 Craig Conover 2006-07-12 20:36:24 UTC 
multiplicityChanged was not being invoked in JavaAttributeChangeHandler, because
there was no "mirror" method in JavaAttributeChangeFacility (the class that
MemberInfo has a reference to for calling typeChanged). So I added this method
and invoke it when there is an attribute type change event. There is no way of
knowing if just the multiplicty has changed because JavaModel and MDR do not
provide that information. Calling it when the type change event occurs has no
ill side effect if there indeed wasn't any change in multiplicity. (Thanks Trey
for the tip).
Comment 5 Craig Conover 2006-07-12 22:18:17 UTC 
This also address another scenario:
"Attribute type renaming through java source property is not propagated to model"
Comment 6 Craig Conover 2006-07-12 23:32:58 UTC 
Files affected:
uml/core/src/org/netbeans/modules/uml/core/roundtripframework/requestprocessors/javarpcomponent/JavaAttributeChangeFacility.java
uml/ideintegration/src/org/netbeans/modules/uml/integration/netbeans/listeners/JMIInfoUtils.java
uml/core/src/org/netbeans/modules/uml/core/roundtripframework/AttributeChangeFacility.java
uml/ideintegration/src/org/netbeans/modules/uml/integration/ide/events/MemberInfo.java
Comment 7 Craig Conover 2006-08-10 21:43:57 UTC 
*** Issue 80601 has been marked as a duplicate of this issue. ***
Comment 8 Andrew Korostelev 2006-08-11 17:00:56 UTC 
verified in nb55 beta milestone17