Created attachment 105304 [details]
test case

In the test, application2.xml is not used anywhere. Did not you mean to write this?

File updated = new File(dataDir, "application/application2.xml");

Created attachment 105307 [details]
updated test

Still fails on assertEquals(2, app.getModule().length);

Hi Denis, could you please also take a look at this one? Thanks.

Not yet investigated it deeply but at first glance this is not a bug.
I don't know exactly how the model which is used for Application is written
but f.e. XAM/XDM based models require explicit "sync" for synchronization with 
underlying content.
Such "sync" could be result of Document listener (reaction on some editor event).

I'm not sure that FileUtil.refreshFor is enough for model synchronization .

I need to investigate this deeply.

Hm , I see from implementation of DDProvider that it really should update 
model on File change event.

But described behavior is not unexpected :
real files refresh is performed in the separate thread  and 
file change event could arrive after model call is done in the main thread.
This is exactly what happens :
the second call app = DDProvider.getDefault().getDDRoot(workingObject);
is first ( in the time frame ) and model update on file event change is the 
second.

The question is : do you really need updated model right after File change ?
From the user perspective I don't see the real need in such behavior.
It could be a problem only for writing tests .
But it could be solved via own FileChangeListener implementation .

To fix the described problem explicit method "sync" could be added into the 
application api.

The resolution WORKSFORME does not seem to be ok. Either it is INVALID or WONTFIX. Obviously the test case does not work.

BTW There is real need to see an updated model, especially when you do things like deployment. The delay between the file change and the listener notification may be really long.

At least you may document in the API that it works this way. Otherwise sooner or later somebody else will hit this again.

>The resolution WORKSFORME does not seem to be ok. Either it is INVALID or
>WONTFIX. Obviously the test case does not work.
There was a resolution INCOMPLETE. Without your reaction. 
Not working test doesn't mean the problem with functionality for which test is 
written . It could mean incorrectly written test.

I have suggested to you the solution.
It does work for me. So I mark this issue respectively.

>BTW There is real need to see an updated model, especially when you do things
>like deployment. The delay between the file change and the listener
>notification may be really long.
So WHY you didn't respond with this notion when I set the resolution as INCOMLETE?

>At least you may document in the API that it works this way. Otherwise sooner
>or later somebody else will hit this again.
I'm not an owner or responsible person for this functionality .
Petr assigned this issue to me for evaluation and fix if it possible.
You are able to add javadoc in this API exactly as me.

I've suggested the solution for immediate update of the model : introduce method
"sync". 
But the module under the subject is open API and the procedure of change is too 
complected.
It could be done after 7.0 release.

Hi Denis,
I just wrote what I thought should be done, nothing more.

P.

Javadoc updated: web-main d6309af212e5.

Integrated into 'main-golden', will be available in build *201102010000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/d6309af212e5
User: Petr Hejl <phejl@netbeans.org>
Log: #194656 Old data returned on DDProvider.getDDRoot(FileObject)

Report from old NetBeans version. Due to code changes since it was reported likely not reproducible now. Feel free to reopen if happens in 8.0.2 or 8.1.