Bug #4527

reports cannot be loaded when InstanceAuthNamespace changes

Added by Oliver Soong almost 13 years ago. Updated almost 13 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Generate a report and save the KAR. Close Kepler, clean-all, delete the configuration folder, LastObjectID, and .ptolemy-compiled (I think that's almost everything that Kepler generates). Run Kepler again, and open the KAR. The report layout should be there. Now close Kepler and delete only InstanceAuthNamespace. Run Kepler again and open the KAR. The report should not be there.

This makes it hard to transport a KAR file to another computer or even another build of Kepler.

Related issues

Blocks Kepler - Bug #4224: New LSID generated when opened from KARResolved07/06/2009


#1 Updated by Oliver Soong almost 13 years ago

It looks like a workaround is to transfer the InstanceAuthNamespace file from one computer to the other. It requires a clean-cache before loading.

#2 Updated by ben leinfelder almost 13 years ago

Transporting the InstanceAuthNamespace is unacceptable.
One of the major reasons for having KARs is for sharing them among people (and computers).
If you save a KAR and then send it to me, do I loose the report layout?

#3 Updated by Oliver Soong almost 13 years ago

svn co

There should be a KAR in there as well as an InstanceAuthNamespace for you to test.

#4 Updated by ben leinfelder almost 13 years ago

The workflow in question has an LSID of:
when I step through opening the KAR file in debug mode I can see that the report layout is correctly opened and added to the manager with the correct workflow association. The problem seems to be that the opened workflow then gets an LSID assigned to it using my AuthNamespace prefix (a new LSID) and the workflow<->report layout association does not exist.
The LSID change happens somewhere during the openModel() methods (in ptolemy?) so that by the time we hit KeplerGraphFrame we have a new LSID for the NamedObj (workflow).
I do see the old LSID in the "derivedFrom" list so my hunch is that there's a changer request that is forcing the new LSID generation.

#5 Updated by ben leinfelder almost 13 years ago

also: just opening a plain old XML workflow file from a different InstanceAuthNamespace results in a new LSDI being assigned (and the original one becoming part of the derived from list).

#6 Updated by ben leinfelder almost 13 years ago

this should work now that the LSID is not being changed when the workflow opens in a new namespace (kepler) instance

#7 Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 4527

Also available in: Atom PDF