> -----Original Message-----
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Monday, November 28, 2016 2:51 PM
> To: firstname.lastname@example.org
> Subject: RE: How should no-op setter methods be filed in Bugzilla?
> The class you mentioned uses an instance variable instead of using
> this.setProperty(...), so I thought that this might be your problem and
> wanted to ask, of the other examples you found, have the same property
> (that is, not using setProperty).
You know, I hadn't thought of that! That could be a promising lead; I'll
take a closer look and see if I can confirm/deny.
If that _is_ the case, what do you suppose would be the correct approach to
fixing the problem? IMO, the "obvious" solution is to prefer setProperty()
in setter methods. But that's both ugly to look at and not enforceable in
code, so it only exists by convention (i.e. still really easy to mess it
up). I believe it would be more robust and sensible to consider this a bug
in SaveService failing to lower user-facing properties so they can be
included in the output.
>> I've tried. XStream is kind of obtuse, and I'm still trying to figure
>> out the point where the data structure is lowered to a HashTree that
>> SaveService can work with. If I knew that, I might be able to _fix_ it.
> I would love to hear more about this, when you have something to report
I wonder if someone else here can point me in the right direction? Sebb?
Confidentiality Notice: This electronic message transmission, including any
attachment(s), may contain confidential, proprietary, or privileged information
from Chemical Abstracts Service ("CAS"), a division of the American Chemical
Society ("ACS"). If you have received this transmission in error, be advised
that any disclosure, copying, distribution, or use of the contents of this
information is strictly prohibited. Please destroy all copies of the message
and contact the sender immediately by either replying to this message or