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 40498 - [Registry] Firing of events does not work from FS.AtomiicAction
Summary: [Registry] Firing of events does not work from FS.AtomiicAction
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 4.x
Hardware: All All
: P1 blocker (vote)
Assignee: rmatous
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-26 01:23 UTC by David Strupl
Modified: 2008-12-22 19:55 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Test this patch after you fix testFromAtomicAction. (2.55 KB, patch)
2004-02-26 15:27 UTC, rmatous
Details | Diff
Modified test -but fails for merged contexts (1.21 KB, patch)
2004-02-27 10:48 UTC, rmatous
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2004-02-26 01:23:40 UTC
Sorry to have this bug in core/code, but there is
no category for registry (or did I just miss it?).

The problem is in the class ContextBindings: the
trick with lastAtomicAction does not work when the
operation is invoked from some atomic action. I
have found this problem when my code was called
from
ExplorerActions.DeleteActionsPerformer.doDestroy.
Of course I could replan the manipulation with
registry to another thread, but I suspect that I
would have to replan *all* calls to registry to
separate thread to make sure that the events are
fired from the core/registry implementation. It
would be good if the events were fired even when
invoked from atomic action since I am not able to
tell whether my code was already part of some
atomic action. I was trying to supply a test for
you but the tests for registry were not migrated
to the new xtests (they did not work at least for me).
Comment 1 _ ttran 2004-02-26 08:48:28 UTC
changed version to promo-d.  registry is not part of 3.6
Comment 2 rmatous 2004-02-26 08:51:29 UTC
#40499 was fixed. So, please provide the test.
Comment 3 David Strupl 2004-02-26 13:28:37 UTC
The test is here and it indeed fails:

Checking in EventsTest.java;
/cvs/openide/registry/test/unit/src/org/netbeans/api/registry/EventsTest.java,v
 <--  EventsTest.java
new revision: 1.9; previous revision: 1.8
done

But there are 5 more tests from openide/registry that also fail for
me. Should I file separate bug reports?
Comment 4 David Strupl 2004-02-26 13:35:52 UTC
Investigation: In ContextBindings.bindObject line 192
lastAtomicAction = null;
is performed before the FileSystemListener.fileDeleted is performed.
But this method assumes that lastAtomicAction returned on line
FileSystemListener:140 from
ctx.getContextBindings().getLastAtomicAction()
is not null and contains the value assigned there on line
ContextBinding:180.

The reason for this is that when the whole code is invoked from
another atomic action the notification to FileSystemListener is done
from that another atomic action. The test should demonstrate the problem.
Comment 5 rmatous 2004-02-26 15:27:40 UTC
Created attachment 13679 [details]
Test this patch after you fix testFromAtomicAction.
Comment 6 David Strupl 2004-02-27 10:39:17 UTC
After applying your test the behaviour in real life (called from my
module seems to be fixed). But I don't know how to fix the test. Seems
like your fix is ok - should I commit it? Any idea why the test still
fails on the first line here

testFromAtomicAction:

      junit.framework.AssertionFailedError: Number of events does not
match
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at
org.netbeans.api.registry.EventsTest.implTestEvents(EventsTest.java:127)
	at org.netbeans.api.registry.EventsTest.testEvents(EventsTest.java:57)
	at org.netbeans.api.registry.EventsTest$1.run(EventsTest.java:82)
	at
org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:89)
	at
org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:417)
	at
org.netbeans.api.registry.EventsTest.testFromAtomicAction(EventsTest.java:78)
Comment 7 rmatous 2004-02-27 10:47:12 UTC
#40498 - is a real issue . But this test testFromAtomicAction  is
completely wrong.  You can modify contexts and bindings in
AtomicAction, but you  must test events after atomic block because
events from filesystems are postponed. So, please  rewrite it to be
more correct.  Registry can't be never fixed to satisfy this test. 
Comment 8 rmatous 2004-02-27 10:48:06 UTC
Created attachment 13698 [details]
Modified test -but fails for merged contexts
Comment 9 rmatous 2004-02-27 10:50:53 UTC
Before this patch is commited there should be at least evaluated why
this test fails for merged contexts. I'm not sure if I find enough
time to evaluate it today.
Comment 10 rmatous 2004-02-27 10:55:37 UTC
Maybe there should be also documented that in current implementation
(based on filesystems) of Registry events are postponed if inside of
atomic block (similarly like events from filesystems) - you can fill it.
Comment 11 David Strupl 2004-02-27 11:21:06 UTC
Aha, as you can see I did not understand how to write such a test. But
as I mentioned before from my point of view you can commit your fix
since it solved the problem for my module at least.

Now it is clear what to do with the test.

You are attaching somehow garbled diffs - your lines are wrapped and
also using context diff (cvs diff -c) is usually more readable. I had
to manually apply your patches ;-(
Comment 12 rmatous 2004-02-27 15:52:11 UTC
Fixed. Filed new issue #40578 - REGISTRY: MergedContexts - fails test
testFromAtomicAction1
/cvs/openide/registry/test/unit/src/org/netbeans/api/registry/EventsTest.java,v
<--  EventsTest.java
new revision: 1.10; previous revision: 1.9

/cvs/core/registry/src/org/netbeans/core/registry/ContextBindings.java,v
 <--  ContextBindings.java
new revision: 1.10; previous revision: 1.9

/cvs/core/registry/src/org/netbeans/core/registry/FileSystemListener.java,v
 <--FileSystemListener.java
new revision: 1.5; previous revision: 1.4
Comment 13 Lukas Hasik 2004-03-04 13:29:30 UTC
David (any ;), could you please verify. Thanks.
Comment 14 David Strupl 2004-03-04 15:07:31 UTC
x