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.
The initial feature request can be found at: http://mdr.netbeans.org/servlets/ReadMsg?msgId=339310&listName=dev Here I answer the questions formulated in the other mails in the aforementioned thread: Q: Why do you need to know about inner transactions ? A: I do not really need, but I can provide additional features when I know. What I definitely need is to know the parent of an inner transaction when I get information about the inner transaction. When MDR informs the UndoManager only about outermost transactions, nothing is wrong. But when MDR informs the UndoManager about an innermost transaction it has to provide information about its parent. Q: Why do you need the transactions be passed into events ? A: What I need to know is for each event (pre-change and post-change) the transaction it belongs to. How I get this information does not really matter. I thought my proposal would be the simplest one for MDR and provide greatest future flexibility for you. When you tell me another way to be informed about the transaction-event-relation I will be satisfied.
Thanks for your answers. I just got confused by your initial e-mail, where you requested both new events and a transaction context passed to events. This is obviously more complicated than providing just events. I propose to have events (possibly on the repository) in a similar way that there are events on other objects, receiving synchronous and asynchronous transaction begin and end, only for outermost read/write (not readonly) transactions. Does that seem reasonable to you? (I am quite busy now - I'm at the OMG Technical Meeting - so I have only small breaks during which I can reply to e-mail, but in the evening I should be able to put together a more concrete proposal of the new API).
Only outermost read/write transactions is OK. Transaction begin/end events on repositories is OK. Additionally I must get knowledge about which events belong to which transaction. That would be possible if an order of listener invocation is defined (namely for each transaction: first transaction begin event, then all change events belonging to that transaction, then transaction end event). Probably listeners are invoked in a certain order, but that order is currently not documented. So it would be enough to amend the Javadoc of the MDR event API in that point for pre-change and post-change listener invocation. Changes to that order will then count as API changes.
Ordering of pre-change listeners is implicit - because they are synchronous. Ordering of change listeners has to be the same as ordering of pre-change listeners (we have also tests that check that) and that is how it is always going to work. But you are right that I have forgotten to state it explicitly in JavaDoc, so I will fix that. (I am planning to have both pre-change and chage events also for transactions - this way the change event can confirm that the transaction that was planned to be commited was really commited, not rolled back)
Fine. This way it will work.
fixed (see also issue #25186 for more discussion on this topic)