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 134190 - project properties modification does not propagate to current debug session
Summary: project properties modification does not propagate to current debug session
Alias: None
Product: cnd
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Thomas Preisler
Depends on:
Reported: 2008-04-29 20:18 UTC by Thomas Preisler
Modified: 2008-09-15 16:51 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Preisler 2008-04-29 20:18:09 UTC
From CR 6666389:

project properties modification does not propagate to current debug session, if current debug session is created from
copied configuration.

Steps to reproduce :

- Open "Welcome" project
- bring up "Properties" dialog
- click on "Manage Configuration"
- click on "Copy", a "Copy_of_Debug" new config will be created, click "OK"
- control go back to "Properties" dialog, "Configuration" will be default to newly created config
- modify "Arguments" property of "Running" config to "arg1", click "OK"
- In toobar menu, switch configuration to "Copy_of_Debug"
- step into welcome project, make dbx console be visible
- bring up project "Properties" dialog again
- set "Arguments" property of "Running" config from "arg1" to "arg2"
- click "Apply", "arg2" should propagate to dbx console as "runargs arg2" dbx command,
  but it didn't
Comment 1 Thomas Preisler 2008-04-29 20:18:35 UTC
The malfunction of propagating options changes to dbxgui is because sometime pcs in DbxProfile is null, and the reason
for this could be the ConfigurationAuxObject in MakeConfiguration.clone(), the following codes in
MakeConfiguration.clone() will make DbxProfile's pcs as null, but I couldn't figure out why :

        ConfigurationAuxObject[] objects = getAuxObjects();
        List<ConfigurationAuxObject> clonedAuxObjects = new ArrayList<ConfigurationAuxObject>();
        for(int i = 0; i < objects.length; i++){
        return clone;
Comment 2 ivan 2008-07-03 06:06:26 UTC
Here's why.
AuxObjects belong to a Configuration and share a pcs with them.
RunProfile has two constructors, a plain one and one with a PCS parameter.
The one with the PCS parameter is called from it's provider using the whole AuxObject provider 
infrastructure. This all happens correctly when you create a Configuration.
But RunProfile.clone() uses the simple constructor so the resulting clone which
is created by MakeConfiguration.clone ends up w/o a pcs.

In cnd.makeproject cloning has two uses.
One is to create a "working copy" to be passed to editors (configuration
edit dialog). These working copies don't rely that much on property notification because
they usually just assign themselves back to the original copy which fires property
changes galore.
Another use is when a configuration is duplicated from the configuration manager UI.
Not copying the pcs in this case causes the problems described in this IZ. 

Coupl of ways this could be fixed:
- Have clone go through the AuXObj factories/providers instead of instantiating using plain
  "new RunProfile()".
  In other words cloning and factories cannot simultaneously co-exists w/o subtle problems.

- MakeConfiguration.clone() creates a new Configuration (with a pcs _and_ with all it's
  AuxObjects created (with _their_ correct pcs's)). It then goes and replaces references to
  the AuxObjs (sending them to be GC'ed) with cloned copies.
  MakeConfiguration.clone() could instead use assign to xfer info from it's AuxObjs to 
  the clones AuxObjs.

It's important to note that it's always desirable for a propertied object to have a pcs.
What's definitely is _not_ desirable is copying a pcs's registered _listeners_! If you
do that then you'll have multiple entities signalling one observer. 
I suspect in the process of enforcing this latter desire the baby (an empty pcs)
was thrown out with the bathwater (the pcs's listeners).

Was this cloning and AuxObject mgmt inherited/copied from some other place?
If so than that other place and whoever copied form it also suffers these problems.
Comment 3 Thomas Preisler 2008-07-17 04:13:18 UTC

changeset 7d449df4aec0 in main
	134190 project properties modification does not propagate to  current debug session

Instead of replacing aux objects in the copy with copies of the original ones, the values of original ones are assigned back to the copy preserving the pcs 
which is correct in the copy.
Comment 4 Thomas Preisler 2008-07-17 04:24:56 UTC
I have tested the fix with SS IDE and it seems to fix the problems described here. The SS build can be found here:
Comment 5 Alexander Pepin 2008-07-18 18:20:44 UTC
verified in build provided by Thomas on /net/danmark/export/home/thp/ceres/opt
Comment 6 rbalada 2008-07-28 17:12:51 UTC
I've transplanted the changeset;node=7d449df4aec0 into release61_fixes
repository as
Comment 7 Thomas Preisler 2008-09-15 16:51:45 UTC
delivered to SS