Re: [JPP-Devel] Modified LayerManager class that fixes Bug #1487099...
Larry,
You could be right. I didn't even think about the iteration occuring in the
GUI Thread. Does this mean that the Runnable argument passed to the
LayerManager.fireCategoryChanged() method is in fact the GUI Thread? It
looked like OpenJUMP/JUMP was creating a brand new thread using an inner
class. (I must admit that I find inner classes almost as confusing as
threads.)
I'm not disagreeing with your analysis, I'm just trying to understand. :]
Here is the code for the LayerManager.fireCategoryChanged() method that I
thought created a new thread object to iterate over the layerListeners
collection:
fireLayerEvent(new Runnable()
{
public void run()
{
layerListener.categoryChanged(new CategoryEvent(
category, type, categoryIndex));
}
Thanks for your help Larry.
The Sunburned Surveyor
On 1/18/07, Larry Becker [EMAIL PROTECTED] wrote:
Sunburned,
I respectfully disagree with your analysis. I believe all of the
iteration over LayerListeners occurs within the GUI Thread. My guess is that
although addCategory took the bullet, it didn't fire the gun. Having said
that, and looking at the trace, and your fix, I don't see any harm in trying
it. I'm a belt and suspenders kind of guy 8-) and I don't have a better
answer.
This is a pretty old bug (May) and a lot of stuff has changed since then
so it may not be possible to reproduce it any more. I tried loading a task
with dozens of categories with no luck, even with OJ 1.0.1.
regards,
Larry
On 1/18/07, Sunburned Surveyor [EMAIL PROTECTED] wrote:
I have attached the Java file for the modified LayerManager class that
fixes Pedro's bug with the ConcurrentModificationException. All of the
changes were made to the LayerManager.fireCategoryChanged() method. I
implemented the solution recommended by David, which is to clone the
layerListener collection before firing the event to the listeners. The
LayerManager class was taken from the OpenJUMP CVS.
This has not been tested in an OpenJUMP build yet. I will test it with
the other bug fixes I need to make for the 01.00.02 release.
The Sunburned Surveyor
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Modified LayerManager class that fixes Bug #1487099...
Sunburned,
Well, it calls fireLayerEvent with a new inline Runnable class method run
defined to do layerListener.categoryChanged. Then fireLayerEvent invokes
GUIUtil.invokeOnEventThread which does:
if (SwingUtilities.isEventDispatchThread()) {
r.run();
} else {
SwingUtilities.invokeAndWait(r);
}
So if the current thread is an AWT event dispatching thread, it does run()
otherwise it does invokeAndWait() which blocks until all of the AWT events
have been processed.
Without getting too deep in the woods, it seems like the point is that there
is no iteration going on here. All of the iteration is going on in the
fireCategoryChanged method that you modified which should be in thread.
Also note that Jon prevents new events from firing while processing current
events with the isFiringEvents() check.
This is one of those pieces of code that the more I look at it, the more I
see I don't see. Know what I mean?
Larry
On 1/18/07, Sunburned Surveyor [EMAIL PROTECTED] wrote:
Larry,
You could be right. I didn't even think about the iteration occuring in
the GUI Thread. Does this mean that the Runnable argument passed to the
LayerManager.fireCategoryChanged() method is in fact the GUI Thread? It
looked like OpenJUMP/JUMP was creating a brand new thread using an inner
class. (I must admit that I find inner classes almost as confusing as
threads.)
I'm not disagreeing with your analysis, I'm just trying to understand. :]
Here is the code for the LayerManager.fireCategoryChanged() method that I
thought created a new thread object to iterate over the layerListeners
collection:
fireLayerEvent(new Runnable()
{
public void run()
{
layerListener.categoryChanged(new CategoryEvent(
category, type, categoryIndex));
}
Thanks for your help Larry.
The Sunburned Surveyor
On 1/18/07, Larry Becker [EMAIL PROTECTED] wrote:
Sunburned,
I respectfully disagree with your analysis. I believe all of the
iteration over LayerListeners occurs within the GUI Thread. My guess is that
although addCategory took the bullet, it didn't fire the gun. Having said
that, and looking at the trace, and your fix, I don't see any harm in trying
it. I'm a belt and suspenders kind of guy 8-) and I don't have a better
answer.
This is a pretty old bug (May) and a lot of stuff has changed since
then so it may not be possible to reproduce it any more. I tried loading a
task with dozens of categories with no luck, even with OJ 1.0.1.
regards,
Larry
On 1/18/07, Sunburned Surveyor [EMAIL PROTECTED] wrote:
I have attached the Java file for the modified LayerManager class that
fixes Pedro's bug with the ConcurrentModificationException. All of the
changes were made to the LayerManager.fireCategoryChanged () method. I
implemented the solution recommended by David, which is to clone the
layerListener collection before firing the event to the listeners. The
LayerManager class was taken from the OpenJUMP CVS.
This has not been tested in an OpenJUMP build yet. I will test it with
the other bug fixes I need to make for the 01.00.02 release.
The Sunburned Surveyor
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join
Re: [JPP-Devel] Modified LayerManager class that fixes Bug #1487099...
I know exactly what you mean! I'm sorry I ever selected this bug out of the
tracker. :]
I should have followed the method calls that result from the call to
LayerManager.fireCategoryChanged() farther down the chain than I did.
I would still like to understand how things are working. I will print out
your last e-mail and read over it very carefully. I may have a couple more
questions after that if you are willing to continue this conversation.
Thanks again for all of your help.
SS
On 1/18/07, Larry Becker [EMAIL PROTECTED] wrote:
Sunburned,
Well, it calls fireLayerEvent with a new inline Runnable class method
run defined to do layerListener.categoryChanged. Then fireLayerEvent
invokes GUIUtil.invokeOnEventThread which does:
if (SwingUtilities.isEventDispatchThread()) {
r.run();
} else {
SwingUtilities.invokeAndWait(r);
}
So if the current thread is an AWT event dispatching thread, it does run()
otherwise it does invokeAndWait() which blocks until all of the AWT events
have been processed.
Without getting too deep in the woods, it seems like the point is that
there is no iteration going on here. All of the iteration is going on in
the fireCategoryChanged method that you modified which should be in thread.
Also note that Jon prevents new events from firing while processing current
events with the isFiringEvents() check.
This is one of those pieces of code that the more I look at it, the more I
see I don't see. Know what I mean?
Larry
On 1/18/07, Sunburned Surveyor [EMAIL PROTECTED] wrote:
Larry,
You could be right. I didn't even think about the iteration occuring in
the GUI Thread. Does this mean that the Runnable argument passed to the
LayerManager.fireCategoryChanged() method is in fact the GUI Thread? It
looked like OpenJUMP/JUMP was creating a brand new thread using an inner
class. (I must admit that I find inner classes almost as confusing as
threads.)
I'm not disagreeing with your analysis, I'm just trying to understand.
:]
Here is the code for the LayerManager.fireCategoryChanged() method that
I thought created a new thread object to iterate over the layerListeners
collection:
fireLayerEvent(new Runnable()
{
public void run()
{
layerListener.categoryChanged(new CategoryEvent(
category, type, categoryIndex));
}
Thanks for your help Larry.
The Sunburned Surveyor
On 1/18/07, Larry Becker [EMAIL PROTECTED] wrote:
Sunburned,
I respectfully disagree with your analysis. I believe all of the
iteration over LayerListeners occurs within the GUI Thread. My guess is that
although addCategory took the bullet, it didn't fire the gun. Having said
that, and looking at the trace, and your fix, I don't see any harm in trying
it. I'm a belt and suspenders kind of guy 8-) and I don't have a better
answer.
This is a pretty old bug (May) and a lot of stuff has changed since
then so it may not be possible to reproduce it any more. I tried loading a
task with dozens of categories with no luck, even with OJ 1.0.1.
regards,
Larry
On 1/18/07, Sunburned Surveyor [EMAIL PROTECTED] wrote:
I have attached the Java file for the modified LayerManager class
that fixes Pedro's bug with the ConcurrentModificationException. All of
the
changes were made to the LayerManager.fireCategoryChanged () method.
I implemented the solution recommended by David, which is to clone the
layerListener collection before firing the event to the listeners. The
LayerManager class was taken from the OpenJUMP CVS.
This has not been tested in an OpenJUMP build yet. I will test it
with the other bug fixes I need to make for the 01.00.02 release.
The Sunburned Surveyor
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net 's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys - and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Modified LayerManager class that fixes Bug #1487099...
This is one of those pieces of code that the more I look at it, the more I see I don't see. Know what I mean? i dont understand that really but i know that i do not understand.. thats why i am a GIS guy and not a programmer :o) good night, stefan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
