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 170872 - Conceptual problems of XAM/XDM
Summary: Conceptual problems of XAM/XDM
Status: NEW
Alias: None
Product: xml
Classification: Unclassified
Component: XDM (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@xml
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-25 13:43 UTC by Milos Kleint
Modified: 2012-02-20 14:04 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2009-08-25 13:43:35 UTC
I've been using XAM/XDM extensively in maven support since 6.5. It works great apart from some issue I'd like to
summarize here.

1. ModelSource get cached internally but I always have to recreate tem as the cache is not generally available. As a
consequence you cannot have both editable and non-editable ModelSource for one physical file. I've got hit by this when
I used a non-editable in navigator (which by nature doesn't edit anything), but then later in the game got errors from a
Model+ModelSource which I created to be editable. Unfortunately the cached non-editable one was used.

2. Transactions are hard to work with, rollback appears not to be working 100% for complicated stuff (it somehow breaks
the model and on new occasion the model breaks).. undo/redo seems to scare people when they see the entire document
disappear and then reappear the old version..

3. sync() and refresh(). never really understood what sync does. Is it syncing from the model to the document? I figured
I need to do a sync() *before* starting a transaction or doing any work with the model. how is that better than
refresh() (which it might call as well in the end)?
refresh() when called explicitly or implicitly by other calls inside the xam/xdm framework seems to invalidate all the
models other parts of the IDE are holding or even processing, that's rather unfortunate and source of many errors.
Together with a fact mentioned in point 1 it means the access to any interaction with the model shall be guarded by a
Write Mutex, so that threads don't step on each other toes and after each job the model shall be thrown away and
recreated via refresh(). Unfurtunately it's not the case.

related issues #165465, #166414 and possibly #168281
Comment 1 Milos Kleint 2012-02-20 14:04:22 UTC
Additionally the fact that transaction has to be started and finished on the same thread is also inconvenient.