[mdt-papyrus.dev] NattablePropertyEditor tries to modify its configurati

[Christian Damus <give.a.damus@xxxxxxxxx>]

Hi, Team,

I am working on rebasing an old Gerrit change (review 66384) onto Neon, which was originally implemented on the Papyrus Mars platform and has been rebased along on Neon in progressive fits and starts.  Amongst numerous other refactorings, this needs to account for refactorings in the Nattable implementation of a property-sheet widget in the Papyrus Properties framework.

On the latest (May 17) Papyrus build, I see this block of code in the NattablePropertyEditor class:

if (null != synchronizedFeature) {

TableHeaderAxisConfiguration rowHeaderAxisconfig = tableConfiguration.getRowHeaderAxisConfiguration();

for (IAxisConfiguration axisConfig : rowHeaderAxisconfig.getOwnedAxisConfigurations()) {

if (axisConfig instanceof EStructuralFeatureValueFillingConfiguration) {

((EStructuralFeatureValueFillingConfiguration) axisConfig).setListenFeature(synchronizedFeature);

}

}

}

This attempts to set the “listen feature” of an axis configuration in the table-configuration model.  But, the configuration model is loaded in a ModelSet with a transactional editing domain in a dedicated service-registry created by the NattablePropertyEditor so that would have to be done in a read/write transaction.  Of course, there is no such transaction when showing the Properties view for a model selection.  Consequently, creation of the table widget blows up with an IllegalStateException on not having a transaction, and the table doesn’t appear in the Properties view.

Are we (Papyrus-RT) doing something wrong?  It looks to me like the code snippet above could never possibly work.  Why is it even trying to replace the “listen feature” that is already set in the table-configuration?  Is anybody else using a row-header axis configuration that contains a feature-value-filling configuration?  Should this protocol-message parameters table in Papyrus-RT even be using it?

Thanks,

Christian